Menggunakan log sumber daya untuk memantau SignalR Service

Artikel ini menjelaskan cara menggunakan fitur Azure Monitor untuk menganalisis dan memecahkan masalah data pemantauan log sumber daya yang dihasilkan oleh Azure SignalR.

Halaman Gambaran Umum di portal Azure untuk setiap Azure SignalR Service menyertakan tampilan singkat penggunaan sumber daya, seperti koneksi bersamaan dan jumlah pesan. Informasi bermanfaat ini hanyalah sejumlah kecil data pemantauan yang tersedia di portal. Beberapa data ini dikumpulkan secara otomatis dan tersedia untuk analisis segera setelah Anda membuat sumber daya.

Anda dapat mengaktifkan jenis pengumpulan data lain setelah beberapa konfigurasi. Artikel ini menjelaskan cara mengonfigurasi pengumpulan data log dan menganalisis dan memecahkan masalah data ini dengan menggunakan alat Azure Monitor.

• Untuk informasi selengkapnya tentang memantau Azure SignalR Service, lihat Memantau Azure SignalR Service.
• Untuk daftar terperinci metrik dan log yang dikumpulkan untuk Azure SignalR Service, lihat Referensi data pemantauan Azure SignalR Service.

Prasyarat

Untuk mengaktifkan log sumber daya, Anda perlu menyiapkan tempat untuk menyimpan data log Anda, seperti Azure Storage atau Log Analytics.

• Penyimpanan Azure mempertahankan log sumber daya untuk audit kebijakan, analisis statis, atau pencadangan.
• Log Analytics adalah alat pencarian log dan analitik fleksibel yang memungkinkan analisis log mentah yang dihasilkan oleh sumber daya Azure.

Mengaktifkan log sumber daya

Azure SignalR Service mendukung log konektivitas, log olahpesan, dan log permintaan HTTP. Untuk detail selengkapnya tentang jenis log ini, lihat Kategori log sumber daya. Log disimpan di akun Penyimpanan yang dikonfigurasi di panel Log diagnostik. Untuk detail selengkapnya tentang format dan bidang penyimpanan, lihat Penyimpanan data.

Membuat pengaturan diagnostik

Log sumber daya dinonaktifkan secara default. Untuk mengaktifkan log sumber daya dengan menggunakan pengaturan diagnostik, lihat Membuat pengaturan diagnostik di Azure Monitor.

Log sumber daya kueri

Untuk mengkueri log sumber daya, ikuti langkah-langkah berikut:

1. Pilih Log di Analitik Log target Anda.

   

2. Masukkan SignalRServiceDiagnosticLogs dan pilih rentang waktu. Untuk kueri tingkat lanjut, lihat Mulai menggunakan Log Analytics di Azure Monitor

   

Untuk menggunakan kueri sampel untuk Azure SignalR Service, ikuti langkah-langkah berikut:

1. Pilih Log di Analitik Log target Anda.

2. Pilih tab Kueri untuk membuka penjelajah kueri.

3. Pilih Jenis sumber daya untuk mengelompokkan kueri sampel dalam jenis sumber daya.

4. Pilih Jalankan untuk menjalankan skrip.

   

Misalnya kueri untuk Azure SignalR Service, lihat Kueri untuk tabel SignalRServiceDiagnosticLogs.

Pemecahan masalah dengan log sumber daya

Untuk memecahkan masalah Azure SignalR Service, Anda dapat mengaktifkan log sisi server/klien untuk menangkap kegagalan. Saat Azure SignalR Service mengekspos log sumber daya, Anda dapat memanfaatkan log sumber daya untuk memecahkan masalah log untuk layanan.

Masalah terkait koneksi

Ketika Anda mengalami koneksi yang tumbuh atau menurun secara tak terduga, Anda dapat memanfaatkan log konektivitas untuk memecahkan masalah. Masalah umum sering melibatkan perubahan kuantitas koneksi yang tidak terduga, koneksi mencapai batas koneksi, dan kegagalan otorisasi. Bagian berikut menjelaskan cara memecahkan masalah.

Penurunan koneksi tak terduga

Jika Anda mengalami penurunan koneksi yang tidak terduga, pertama-tama aktifkan log di sisi layanan, server, dan klien.

Jika koneksi terputus, log sumber daya merekam peristiwa pemutusan ini, dan Anda melihat ConnectionAborted atau ConnectionEnded di operationName.

Perbedaan antara ConnectionAborted dan ConnectionEnded adalah bahwa ConnectionEnded adalah pemutusan yang diharapkan, yang dipicu oleh sisi klien atau server. ConnectionAborted biasanya merupakan peristiwa penurunan koneksi yang tidak terduga, dan alasan pembatalan disediakan dalam message.

Tabel berikut mencantumkan alasan pembatalan.

Pertumbuhan koneksi tak terduga

Untuk memecahkan masalah tentang pertumbuhan koneksi yang tidak terduga, hal pertama yang perlu Anda lakukan adalah memfilter koneksi tambahan. Anda dapat menambahkan ID pengguna uji unik ke koneksi klien pengujian Anda. Periksa log sumber daya. Jika Anda melihat lebih dari satu koneksi klien memiliki ID pengguna uji atau IP yang sama, kemungkinan sisi klien membuat lebih banyak koneksi dari yang diharapkan. Periksa sisi klien Anda.

Kegagalan otorisasi

Jika Anda mendapatkan 401 Tidak diotorisasi yang ditampilkan untuk permintaan klien, periksa log sumber daya Anda. Jika Anda menemui Failed to validate audience. Expected Audiences: <valid audience>. Actual Audiences: <actual audience>, artinya semua audiens pada token akses Anda tidak valid. Coba gunakan audiens yang valid yang disarankan di log.

Pembatasan

Jika Anda menemukan bahwa Anda tidak dapat membuat koneksi klien SignalR ke Azure SignalR Service, periksa log sumber daya Anda. Jika Anda menemukan Connection count reaches limit dalam log sumber daya, Anda membuat terlalu banyak koneksi ke SignalR Service, yang mencapai batas jumlah koneksi. Pertimbangkan untuk meningkatkan SignalR Service Anda. Jika Anda menemukan Message count reaches limit di log sumber daya, itu berarti Anda menggunakan tingkat gratis, dan Anda menggunakan kuota pesan. Jika Anda ingin mengirim lebih banyak pesan, pertimbangkan untuk mengubah SignalR Service Anda ke tingkat standar. Untuk informasi selengkapnya, lihat Harga Azure SignalR Service.

Masalah terkait pesan

Saat mengalami masalah terkait pesan, Anda dapat memanfaatkan log olahpesan untuk memecahkan masalah. Pertama, aktifkan log sumber daya dalam layanan dan log untuk server dan klien.

Jika Anda tidak keberatan dengan potensi efek performa dan tidak ada pesan arah klien-ke-server, periksa MessagingLog Source Settings/Types untuk mengaktifkan perilaku pengumpulan log collect-all . Untuk informasi selengkapnya tentang perilaku ini, lihat mengumpulkan semua .

Jika tidak, hapus centang Messaging untuk mengaktifkan perilaku pengumpulan log collect-partially . Perilaku ini memerlukan konfigurasi di klien dan server untuk mengaktifkannya. Untuk informasi selengkapnya, lihat mengumpulkan sebagian.

Kehilangan pesan

Jika Anda mengalami masalah kehilangan pesan, kuncinya adalah menemukan tempat Anda kehilangan pesan. Pada dasarnya, Anda memiliki tiga komponen saat menggunakan Azure SignalR Service: Layanan SignalR, server, dan klien. Server dan klien terhubung ke layanan SignalR tetapi tidak terhubung satu sama lain secara langsung setelah negosiasi selesai. Oleh karena itu, Anda perlu mempertimbangkan dua arah untuk pesan, dan untuk setiap arah Anda perlu mempertimbangkan dua jalur:

• Dari klien ke server melalui layanan SignalR
  • Jalur 1: Klien ke layanan SignalR
  • Jalur 2: Layanan SignalR ke server
• Dari server ke klien melalui layanan SignalR
  • Jalur 3: Server ke layanan SignalR
  • Jalur 4: Layanan SignalR ke klien

Untuk mengumpulkan semua perilaku pengumpulan:

Azure SignalR Service hanya melacak pesan ke arah dari server ke klien melalui layanan SignalR. ID pelacakan dihasilkan di server. Pesan membawa ID pelacakan ke layanan SignalR.

Dengan memeriksa server masuk dan sisi layanan, Anda dapat dengan mudah mengetahui apakah pesan dikirim dari server, tiba di layanan SignalR, dan keluar dari layanan SignalR. Pada dasarnya, dengan memeriksa apakah pesan yang diterima dan dikirim cocok atau tidak berdasarkan ID pelacakan pesan, Anda dapat mengetahui apakah masalah kehilangan pesan ada di server atau layanan SignalR ke arah ini. Untuk informasi selengkapnya, lihat detail di bawah ini.

Untuk mengumpulkan perilaku pengumpulan sebagian :

Setelah Anda menandai klien sebagai klien diagnostik, Azure SignalR Service melacak pesan di kedua arah.

Dengan memeriksa server masuk dan sisi layanan, Anda dapat dengan mudah mengetahui apakah pesan berhasil melewati server atau layanan SignalR. Pada dasarnya, dengan memeriksa apakah pesan yang diterima dan dikirim cocok atau tidak berdasarkan ID pelacakan pesan, Anda dapat mengetahui apakah masalah kehilangan pesan ada di server atau layanan SignalR. Untuk informasi selengkapnya, lihat detail berikut.

Detail alur pesan

Untuk arah dari klien ke server melalui layanan SignalR, layanan SignalR hanya mempertimbangkan pemanggilan yang berasal dari klien diagnostik, yaitu, pesan yang dihasilkan langsung di klien diagnostik, atau pesan layanan yang dihasilkan karena pemanggilan klien diagnostik secara tidak langsung.

ID pelacakan dihasilkan di layanan SignalR setelah pesan tiba di layanan SignalR di Jalur 1. Layanan SignalR menghasilkan log Received a message <MessageTracingId> from client connection <ConnectionId>. untuk setiap pesan di klien diagnostik. Setelah pesan keluar dari SignalR ke server, layanan SignalR menghasilkan pesan Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.log . Jika Anda melihat kedua log ini, Anda dapat yakin bahwa pesan berhasil melewati layanan SignalR.

Kemudian pesan membawa Server ID pelacakan di Jalur 2. Server menghasilkan log Received message <messagetracingId> from client connection <connectionId> setelah pesan tiba.

Setelah pesan memanggil metode hub di server, pesan layanan baru dihasilkan dengan ID pelacakan baru. Setelah pesan layanan dibuat, server menghasilkan templat Start to broadcast/send message <MessageTracingId> ...masuk . Log aktual didasarkan pada skenario Anda. Kemudian pesan dikirimkan ke layanan SignalR di Jalur 3. Setelah pesan layanan keluar dari server, log yang disebut Succeeded to send message <MessageTracingId> dihasilkan.

Setelah pesan layanan tiba di layanan SignalR, log yang disebut Received a <MessageType> message <MessageTracingId> from server connection <ConnectionId>. dihasilkan. Kemudian layanan SignalR memproses pesan layanan dan mengirimkan ke klien target. Setelah pesan dikirim ke klien di Jalur 4, log Sent a message <MessageTracingId> to client connection <ConnectionId> successfully. dihasilkan.

Singkatnya, log pesan dihasilkan ketika pesan masuk dan keluar dari layanan dan server SignalR. Anda dapat menggunakan log ini untuk memvalidasi apakah pesan hilang dalam komponen ini atau tidak.

Contoh berikut adalah masalah kehilangan pesan umum.

Klien gagal menerima pesan dalam grup

Cerita umum dalam masalah ini adalah bahwa klien bergabung dengan grup setelah mengirim pesan grup.

Class Chat : Hub
{
    public void JoinAndSendGroup(string name, string groupName)
    {
        Groups.AddToGroupAsync(Context.ConnectionId, groupName); // join group
        Clients.Group(groupName).SendAsync("ReceiveGroupMessage", name, "I'm in group"); // send group message
    }
}

Misalnya, seseorang dapat membuat pemanggilan grup gabungan dan mengirim pesan grup dalam metode hub yang sama. Masalahnya AddToGroupAsync di sini adalah async metode . Karena tidak await ada untuk AddToGroupAsync menunggu sampai selesai, pesan grup akan dikirim sebelum AddToGroupAsync selesai. Karena keterlambatan jaringan, dan penundaan proses bergabung dengan klien ke beberapa grup, tindakan grup gabungan dapat selesai lebih lambat daripada pengiriman pesan grup. Jika demikian, pesan grup pertama tidak memiliki klien sebagai penerima, karena tidak ada klien yang bergabung dengan grup, sehingga menjadi masalah kehilangan pesan.

Tanpa log sumber daya, Anda tidak dapat mengetahui kapan klien bergabung dengan grup dan kapan pesan grup dikirim. Setelah mengaktifkan log olahpesan, Anda dapat membandingkan waktu tiba pesan di layanan SignalR. Lakukan langkah-langkah berikut untuk memecahkan masalah:

1. Temukan log pesan di server untuk ditemukan saat klien bergabung dengan grup dan kapan pesan grup dikirim.
2. Dapatkan ID pelacakan pesan A dari bergabung dengan grup dan ID pelacakan pesan B pesan grup dari log pesan.
3. Filter ID pelacakan pesan ini di antara log olahpesan di target arsip log Anda, lalu bandingkan tanda waktu yang tiba. Anda menemukan pesan mana yang tiba terlebih dahulu di layanan SignalR.
4. Jika ID pelacakan pesan Waktu kedatangan lebih lambat dari waktu kedatangan B, Anda harus mengirim pesan grup sebelum klien bergabung dengan grup. Anda perlu memastikan klien berada dalam grup sebelum mengirim pesan grup.

Jika pesan hilang di SignalR atau server, coba dapatkan log peringatan berdasarkan ID pelacakan pesan untuk mendapatkan alasannya. Jika Anda memerlukan bantuan lebih lanjut, lihat bagian dapatkan bantuan.

Log sumber daya yang mengumpulkan perilaku

Ada dua skenario umum untuk menggunakan log sumber daya, terutama untuk log olahpesan.

Seseorang mungkin peduli dengan kualitas setiap pesan. Misalnya, mereka sensitif pada apakah pesan berhasil dikirim/diterima, atau mereka ingin merekam setiap pesan yang dikirimkan melalui layanan SignalR.

Sementara itu, orang lain mungkin peduli tentang performa. Mereka sensitif pada latensi pesan, dan terkadang mereka perlu melacak pesan dalam beberapa koneksi alih-alih semua koneksi karena alasan tertentu.

Oleh karena itu, layanan SignalR menyediakan dua jenis perilaku pengumpulan

• kumpulkan semua: kumpulkan log di semua koneksi
• mengumpulkan sebagian: mengumpulkan log dalam beberapa koneksi tertentu

Kumpulkan semua

Log sumber daya dikumpulkan oleh semua koneksi. Ambil log olahpesan misalnya. Ketika perilaku ini diaktifkan, layanan SignalR mengirimkan pemberitahuan ke server untuk mulai menghasilkan ID pelacakan untuk setiap pesan. ID pelacakan dibawa dalam pesan ke layanan. Layanan ini juga mencatat pesan dengan ID pelacakan.

Panduan konfigurasi

Untuk mengaktifkan perilaku ini, centang kotak di bagian Jenis di Pengaturan Sumber Log.

Perilaku ini tidak mengharuskan Anda memperbarui konfigurasi sisi server. Perubahan konfigurasi ini selalu dikirim ke server secara otomatis.

Kumpulkan sebagian

Log sumber daya hanya dikumpulkan oleh klien diagnostik. Semua pesan dicatat termasuk pesan klien dan peristiwa konektivitas di klien diagnostik.

Klien diagnostik

Klien diagnostik adalah konsep logis. Setiap klien dapat menjadi klien diagnostik. Server mengontrol klien mana yang dapat menjadi klien diagnostik. Setelah klien ditandai sebagai klien diagnostik, semua log sumber daya diaktifkan di klien ini. Untuk mengatur klien menjadi klien diagnostik, lihat panduan konfigurasi.

Panduan konfigurasi

Untuk mengaktifkan perilaku ini, Anda perlu mengonfigurasi layanan, server, dan sisi klien.

Sisi layanan

Untuk mengaktifkan perilaku ini, hapus centang pada kotak centang untuk jenis log tertentu di bagian Jenis di Pengaturan Sumber Log.

Sisi peladen

Siapkan ServiceOptions.DiagnosticClientFilter juga untuk menentukan filter klien diagnostik berdasarkan konteks http berasal dari klien. Misalnya, buat klien dengan URL <HUB_URL>?diag=yeshub , lalu siapkan ServiceOptions.DiagnosticClientFilter untuk memfilter klien diagnostik. Jika mengembalikan true, klien ditandai sebagai klien diagnostik. Jika tidak, itu tetap sebagai klien normal. Contoh berikut menunjukkan cara menggunakan di ServiceOptions.DiagnosticClientFilter kelas startup Anda.

String koneksi mentah muncul dalam artikel ini hanya untuk tujuan demonstrasi. Di lingkungan produksi, selalu lindungi kunci akses Anda. Gunakan Azure Key Vault untuk mengelola dan memutar kunci Anda dengan aman dan mengamankan string koneksi Anda menggunakan ID Microsoft Entra dan mengotorisasi akses dengan ID Microsoft Entra.

// sample: mark a client as diagnostic client when it has query string "?diag=yes" in hub URL
public IServiceProvider ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    services
        .AddSignalR()
        .AddAzureSignalR(o =>
        {
            o.ConnectionString = "<YOUR_ASRS_CONNECTION_STRING>";
            o.DiagnosticClientFilter = context => context.Request.Query["diag"] == "yes";
        });

    return services.BuildServiceProvider();
}

Sisi klien

Tandai klien sebagai klien diagnostik dengan mengonfigurasi konteks http. Misalnya, klien ditandai sebagai klien diagnostik dengan menambahkan string diag=yeskueri .

var connection = new HubConnectionBuilder()
    .WithUrl("<HUB_URL>?diag=yes")
    .Build();

Dapatkan bantuan

Kami sarankan Anda memecahkan masalah sendiri terlebih dahulu. Sebagian besar masalah disebabkan oleh server aplikasi atau masalah jaringan. Ikuti panduan pemecahan masalah dengan log sumber daya dan panduan pemecahan masalah dasar untuk menemukan akar penyebabnya. Jika masalah masih tidak dapat diselesaikan, pertimbangkan untuk membuka masalah di GitHub atau membuat tiket di portal Azure. Berikan:

1. Rentang waktu sekitar 30 menit saat masalah terjadi
2. ID sumber daya Azure SignalR Service
3. Detail masalah, sesering mungkin: Misalnya, appserver tidak mengirim pesan, koneksi klien terputus, dan sebagainya
4. Log yang dikumpulkan dari sisi server/klien, dan materi lain yang mungkin berguna
5. [Opsional] Kode repro