Azure SignalR Hizmeti günlüklerini izleme ve sorunlarını giderme

Bu makalede, Azure SignalR tarafından oluşturulan kaynak günlüğü izleme verilerini analiz etmek ve sorunlarını gidermek için Azure İzleyici özelliklerini nasıl kullanabileceğiniz açıklanmaktadır.

Her Azure SignalR Hizmeti için Azure portalındaki Genel Bakış sayfası, eşzamanlı bağlantılar ve ileti sayısı gibi kaynak kullanımının kısa bir görünümünü içerir. Bu yararlı bilgiler, portalda sağlanan izleme verilerinin yalnızca küçük bir miktarıdır. Bu verilerin bazıları otomatik olarak toplanır ve kaynağı oluşturur oluşturmaz analiz için kullanılabilir.

Bazı yapılandırmalardan sonra diğer veri toplama türlerini etkinleştirebilirsiniz. Bu makalede, Azure İzleyici araçlarını kullanarak günlük verileri toplamayı yapılandırma, bu verileri analiz etme ve sorunlarını giderme adımları adım adım izlenmektedir.

• İzleme Azure SignalR Hizmeti hakkında daha fazla bilgi için bkz. İzleme Azure SignalR Hizmeti.
• Azure SignalR Hizmeti için toplanan ölçümlerin ve günlüklerin ayrıntılı listesi için bkz. Azure SignalR Hizmeti izleme verileri başvurusu.

Önkoşullar

Kaynak günlüklerini etkinleştirmek için Azure Depolama veya Log Analytics gibi günlük verilerinizi depolamak için bir yer ayarlamanız gerekir.

• Azure depolama ilke denetimi, statik analiz veya yedekleme için kaynak günlüklerini korur.
• Log Analytics , bir Azure kaynağı tarafından oluşturulan ham günlüklerin analiz edilmesini sağlayan esnek bir günlük arama ve analiz aracıdır.

Kaynak günlüklerini etkinleştirme

Azure SignalR Hizmeti bağlantı günlüklerini, mesajlaşma günlüklerini ve Http istek günlüklerini destekler. Bu günlük türleri hakkında daha fazla ayrıntı için bkz . Kaynak günlüğü kategorileri.

Kaynak günlükleri varsayılan olarak devre dışı bırakılır. Tanılama ayarlarını kullanarak kaynak günlüklerini etkinleştirmek için şu adımları izleyin:

1. Azure portalında İzleme'nin altında Tanılama ayarları'nı seçin.

   

   Tanılama ayarlarının tam görünümünü elde edersiniz.

   

2. Günlük kaynağı ayarlarını yapılandırın.

   1. Günlük Kaynağı Ayarlar bölümünde, bir tablo her günlük türü için toplama davranışlarını gösterir.
   2. Tüm bağlantılar için toplamak istediğiniz günlük türünü denetleyin. Aksi takdirde günlük yalnızca tanılama istemcileri için toplanır.

3. Günlük hedefi ayarlarını yapılandırın.

   1. Günlük Hedefi Ayarlar bölümünde, tanılama ayarları tablosu mevcut tanılama ayarlarını görüntüler. Toplanan kaynak günlüklerini görüntülemek üzere günlük hedefine erişmek için tablodaki bağlantıyı seçebilirsiniz.
   2. Bu bölümde Tanılama ayarlarını eklemek, güncelleştirmek veya silmek için Günlük Hedefi Ayarlar Yapılandır düğmesini seçin.
   3. Yeni bir tanılama ayarı eklemek için Tanılama ayarı ekle'yi veya var olan bir tanılama ayarını değiştirmek için Düzenle'yi seçin.
   4. İstediğiniz arşiv hedefini ayarlayın. Şu anda Azure SignalR Hizmeti bir depolama hesabına Arşivle ve Log Analytics'e Gönder'i desteklemektedir.
   5. Arşivlemesini istediğiniz günlükleri seçin. Yalnızca AllLogs kaynak günlüğü için kullanılabilir. Yalnızca günlükleri arşivleyip arşivlemeyeceğinizi denetler. Azure SignalR Hizmeti hangi günlük türlerinin oluşturulması gerektiğini yapılandırmak için Günlük Kaynağı Ayarlar bölümünde yapılandırın.

   

   6. Yeni tanılama ayarını kaydedin. Yeni ayar yaklaşık 10 dakika içinde geçerlilik kazanır. Bundan sonra günlükler yapılandırılan arşiv hedefine gönderilir. Günlük hedef ayarlarını yapılandırma hakkında daha fazla bilgi için bkz . Azure kaynak günlüklerine genel bakış.

Günlükler Tanılama günlükleri bölmesinde yapılandırılan Depolama hesabında depolanır. Depolama biçimi ve alanları hakkında daha fazla bilgi için bkz . Veri depolama.

Kaynak günlüklerini sorgulama

Kaynak günlüklerini sorgulamak için şu adımları izleyin:

1. Hedef Log Analytics'inizde Günlükler'i seçin.

   

2. SignalRServiceDiagnosticLogs girin ve zaman aralığını seçin. Gelişmiş sorgu için bkz . Azure İzleyici'de Log Analytics'i kullanmaya başlama

   

Azure SignalR Hizmeti için örnek sorguları kullanmak için şu adımları izleyin:

1. Hedef Log Analytics'inizde Günlükler'i seçin.

2. Sorgu gezginini açmak için Sorgular sekmesini seçin.

3. Kaynak türündeki örnek sorguları gruplandırmak için Kaynak türü'nü seçin.

4. Betiği çalıştırmak için Çalıştır'ı seçin.

   

Azure SignalR Hizmeti için sorgular için bkz. SignalRServiceDiagnosticLogs tablosu için sorgular.

Not

Depolama hedefleri için sorgu alanı adları Log Analytics'in alan adlarından biraz farklıdır. Depolama ile Log Analytics tabloları arasındaki alan adı eşlemeleri hakkında ayrıntılı bilgi için bkz. Kaynak Günlüğü tablo eşlemesi.

Kaynak günlükleriyle ilgili sorunları giderme

Azure SignalR Hizmeti sorunlarını gidermek için, hataları yakalamak için sunucu/istemci tarafı günlüklerini etkinleştirebilirsiniz. Azure SignalR Hizmeti kaynak günlüklerini kullanıma sunarken, hizmet günlükleriyle ilgili sorunları gidermek için kaynak günlüklerinden yararlanabilirsiniz.

Bağlantıyla ilgili sorunlar

Beklenmedik şekilde büyüyen veya azalan bağlantılarla karşılaştığınızda, sorun gidermek için bağlantı günlüklerinden yararlanabilirsiniz. Tipik sorunlar genellikle beklenmeyen bağlantı miktarı değişikliklerini, bağlantıların bağlantı sınırlarına ulaşmasını ve yetkilendirme hatasını içerir. Aşağıdaki bölümlerde sorun giderme adımları açıklanmaktadır.

Beklenmeyen bağlantı bırakma

Beklenmeyen bağlantı bırakma işlemiyle karşılaşırsanız, önce hizmet, sunucu ve istemci tarafında günlükleri etkinleştirin.

Bağlantı kesilirse, kaynak günlükleri bu bağlantı kesme olayını kaydeder ve veya ConnectionEnded ifadesini operationNamegörürsünüzConnectionAborted.

ile ConnectionEnded arasındaki ConnectionAborted fark, ConnectionEnded istemci veya sunucu tarafı tarafından tetiklenen beklenen bir bağlantı kesilmesidir. ConnectionAborted genellikle beklenmeyen bir bağlantı bırakma olayıdır ve durdurma nedeni içinde messagesağlanır.

Aşağıdaki tabloda iptal nedenlerini listeledik.

Neden	Açıklama
Bağlan sayısı sınıra ulaştı	Bağlan sayısı geçerli fiyat katmanınızın sınırına ulaşır. Hizmet biriminin ölçeğini artırmayı göz önünde bulundurun
Uygulama sunucusu bağlantıyı kapattı	Uygulama sunucusu kürtajı tetikler. Beklenen bir kürtaj olarak değerlendirilebilir
Bağlan ion ping zaman aşımı	Genellikle bunun nedeni ağ sorunudur. Uygulama sunucunuzun İnternet'ten kullanılabilirliğini denetlemeyi göz önünde bulundurun
Hizmet yeniden yükleniyor, yeniden bağlanmayı deneyin	Azure SignalR Hizmeti yeniden yükleniyor. Azure SignalR otomatik yeniden bağlanmayı destekler; yeniden bağlanana kadar bekleyebilir veya Azure SignalR Hizmeti
İç sunucu geçici hatası	geçici hata Azure SignalR Hizmeti oluşur, otomatik kurtarılmalıdır
Sunucu bağlantısı bırakıldı	Sunucu bağlantısı bilinmeyen bir hatayla bırakıldığında, önce hizmet/sunucu/istemci tarafı günlüğü ile kendi kendine sorun gidermeyi göz önünde bulundurun. Temel sorunları (ör. Ağ sorunu, uygulama sunucusu tarafı sorunu vb.) dışlamaya çalışın. Sorun çözülmezse daha fazla yardım için bizimle iletişime geçin. Daha fazla bilgi için Yardım alma bölümüne bakın.

Beklenmeyen bağlantı büyüyor

Beklenmeyen bağlantının büyümesiyle ilgili sorunları gidermek için yapmanız gereken ilk şey ek bağlantıları filtrelemektir. Test istemcisi bağlantınıza benzersiz bir test kullanıcı kimliği ekleyebilirsiniz. Kaynak günlüklerini denetleyin. Aynı test kullanıcı kimliğine veya IP'ye sahip birden fazla istemci bağlantısı görüyorsanız, istemci tarafı beklenenden daha fazla bağlantı oluşturuyor olabilir. İstemci tarafınızı kontrol edin.

Yetkilendirme hatası

İstemci istekleri için 401 Yetkisiz döndürülürse kaynak günlüklerinizi denetleyin. ile karşılaşırsanız Failed to validate audience. Expected Audiences: <valid audience>. Actual Audiences: <actual audience>, erişim belirtecindeki tüm hedef kitlelerin geçersiz olduğu anlamına gelir. Günlükte önerilen geçerli izleyicileri kullanmayı deneyin.

Azaltma

Azure SignalR Hizmeti için SignalR istemci bağlantıları kuramazsınız, kaynak günlüklerinizi denetleyin. Kaynak günlüğünde karşılaşırsanızConnection count reaches limit, bağlantı sayısı sınırına ulaşan SignalR Hizmeti çok fazla bağlantı kurarsınız. SignalR Hizmeti ölçeğini artırmayı göz önünde bulundurun. Kaynak günlüğünde karşılaşırsanız Message count reaches limit , bu ücretsiz katmanı kullandığınız ve ileti kotasını kullandığınız anlamına gelir. Daha fazla ileti göndermek istiyorsanız, SignalR Hizmeti standart katmana değiştirmeyi göz önünde bulundurun. Daha fazla bilgi için bkz. fiyatlandırma Azure SignalR Hizmeti.

İletiyle ilgili sorunlar

İletiyle ilgili sorunlarla karşılaştığınızda, sorun gidermek için mesajlaşma günlüklerinden yararlanabilirsiniz. İlk olarak, sunucu ve istemci için hizmet ve günlüklerde kaynak günlüklerini etkinleştirin.

Not

ASP.NET Core için sunucu ve istemcide günlüğe kaydetmeyi etkinleştirmek için buraya bakın.

ASP.NET için sunucu ve istemcide günlüğe kaydetmeyi etkinleştirmek için buraya bakın.

Olası performans etkilerine aldırmıyorsanız ve istemciden sunucuya yön iletisi yoksa tümünü toplama günlük toplama davranışını etkinleştirmek için giriş bölümüne bakın MessagingLog Source Settings/Types. Bu davranış hakkında daha fazla bilgi için bkz. tümünü toplama.

Aksi takdirde, toplama-kısmen günlük toplama davranışını etkinleştirmek için öğesinin işaretini kaldırınMessaging. Bu davranış, etkinleştirmek için istemci ve sunucuda yapılandırma gerektirir. Daha fazla bilgi için bkz . kısmen toplama.

İleti kaybı

İleti kaybı sorunlarıyla karşılaşırsanız, anahtar iletiyi kaybettiğiniz yeri bulmaktır. Temel olarak, Azure SignalR Hizmeti kullanırken üç bileşeniniz vardır: SignalR hizmeti, sunucu ve istemci. Hem sunucu hem de istemci SignalR hizmetine bağlanır, ancak anlaşma tamamlandıktan sonra doğrudan birbirine bağlanmaz. Bu nedenle, iletiler için iki yönü göz önünde bulundurmanız ve her yön için iki yolu göz önünde bulundurmanız gerekir:

• SignalR hizmeti aracılığıyla istemciden sunucuya
  • Yol 1: İstemciden SignalR hizmetine
  • Yol 2: SignalR hizmetinden sunucuya
• SignalR hizmeti aracılığıyla sunucudan istemciye
  • Yol 3: Sunucudan SignalR hizmetine
  • Yol 4: İstemciye SignalR hizmeti

Tüm toplama davranışlarını toplamak için:

Azure SignalR Hizmeti yalnızca SignalR hizmeti aracılığıyla sunucudan istemciye giden yöndeki iletileri izler. İzleme kimliği sunucuda oluşturulur. İleti, izleme kimliğini SignalR hizmetine taşır.

Not

uygulama sunucunuzdaki bir hub'ın dışından ileti izlemek ve ileti göndermek istiyorsanız, tanılama istemcilerinden kaynaklanmamış iletilerin ileti günlüklerini toplamak için tüm toplama davranışlarını toplamayı etkinleştirmeniz gerekir. Tanılama istemcileri hem tümünü toplar hem de kısmen toplama davranışları için çalışır, ancak günlükleri toplamak için daha yüksek önceliğe sahiptir. Daha fazla bilgi için tanılama istemcisi bölümüne bakın.

Oturum açma sunucusu ve hizmet tarafını denetleyerek, iletinin sunucudan gönderilip gönderilmediğini, SignalR hizmetine ulaşıp ulaşmadığını ve SignalR hizmetinden ayrılıp ayrılmadığını kolayca öğrenebilirsiniz. Temel olarak, alınan ve gönderilen iletinin eşleşip eşleşmediğini veya ileti izleme kimliğine göre eşleşmediğini denetleyerek, ileti kaybı sorununun sunucuda mı yoksa SignalR hizmetinde mi olduğunu bu yönde anlayabilirsiniz. Daha fazla bilgi için aşağıdaki ayrıntılara bakın.

Kısmen toplama davranışı için:

İstemciyi tanılama istemcisi olarak işaretledikten sonra, Azure SignalR Hizmeti iletileri her iki yönde de izler.

Oturum açma sunucusu ve hizmet tarafını denetleyerek, iletinin sunucuyu mu yoksa SignalR hizmetini başarıyla mı geçirdiğini kolayca öğrenebilirsiniz. Temel olarak, alınan ve gönderilen iletinin eşleşip eşleşmediğini denetleyerek veya ileti izleme kimliğine göre eşleşmediğini denetleyerek, ileti kaybı sorununun sunucuda mı yoksa SignalR hizmetinde mi olduğunu anlayabilirsiniz. Daha fazla bilgi için aşağıdaki ayrıntılara bakın.

İleti akışının ayrıntıları

SignalR hizmeti aracılığıyla istemciden sunucuya yönlendirme için SignalR hizmeti yalnızca tanılama istemcisinden kaynaklanan çağrıyı, yani tanılama istemcisinde doğrudan oluşturulan iletiyi veya tanılama istemcisinin dolaylı olarak çağrılması nedeniyle oluşturulan hizmet iletisini dikkate alır.

İzleme kimliği, ileti Yol 1'de SignalR hizmetine ulaştığında SignalR hizmetinde oluşturulur. SignalR hizmeti, tanılama istemcisindeki her ileti için bir günlük Received a message <MessageTracingId> from client connection <ConnectionId>. oluşturur. İleti SignalR'den sunucuya ayrıldıktan sonra SignalR hizmeti bir günlük iletisi Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.oluşturur. Bu iki günlük görürseniz iletinin SignalR hizmetinden başarıyla geçtiğinden emin olabilirsiniz.

Not

ASP.NET Core SignalR sınırlaması nedeniyle, istemciden gelen ileti herhangi bir ileti düzeyi kimliği içermez, ancak ASP.NET SignalR her ileti için çağırma kimliği oluşturur. İzleme kimliğiyle eşlemek için bunu kullanabilirsiniz.

Ardından ileti, Yol 2'de izleme kimliği sunucusunu taşır. sunucu, ileti geldikten sonra bir günlük Received message <messagetracingId> from client connection <connectionId> oluşturur.

İleti sunucuda hub yöntemini çağırdıktan sonra, yeni bir izleme kimliğiyle yeni bir hizmet iletisi oluşturulur. Hizmet iletisi oluşturulduktan sonra sunucu bir oturum açma şablonu Start to broadcast/send message <MessageTracingId> ...oluşturur. Gerçek günlük senaryonuzu temel alır. Ardından ileti Yol 3'teki SignalR hizmetine teslim edilir. Hizmet iletisi sunucudan çıktıktan sonra adlı Succeeded to send message <MessageTracingId> bir günlük oluşturulur.

Not

İstemciden gelen iletinin izleme kimliği SignalR hizmetine gönderilecek hizmet iletisinin izleme kimliğiyle eşlenemez.

Hizmet iletisi SignalR hizmetine ulaştığında adlı Received a <MessageType> message <MessageTracingId> from server connection <ConnectionId>. bir günlük oluşturulur. Ardından SignalR hizmeti hizmet iletisini işler ve hedef istemcilere teslim eder. İleti Yol 4'teki istemcilere gönderildikten sonra günlük Sent a message <MessageTracingId> to client connection <ConnectionId> successfully. oluşturulur.

Özetle, ileti SignalR hizmeti ve sunucusuna girip çıktığında ileti günlüğü oluşturulur. İletinin bu bileşenlerde kaybolup kaybolmadığını doğrulamak için bu günlükleri kullanabilirsiniz.

Aşağıdaki örnek tipik bir ileti kaybı sorunudur.

İstemci bir grupta ileti alamıyor

Bu sorunun tipik hikayesi, istemcinin bir grup iletisi gönderdikten sonra bir gruba katılmasıdır.

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

Örneğin, birisi birleştirme grubu çağrıları yapabilir ve aynı hub yönteminde grup iletisi gönderebilir. Buradaki AddToGroupAsync sorun bir async yöntemdir. tamamlanana awaitAddToGroupAsync kadar beklenemiyor olduğundan, grup iletisi tamamlanmadan önce AddToGroupAsync gönderir. Ağ gecikmesi ve istemciyi bir gruba ekleme işleminin gecikmesi nedeniyle, gruba katılma eylemi grup iletisi tesliminden sonra tamamlanabilir. Öyleyse, ilk grup iletisinde alıcı olarak istemci yoktur, çünkü hiçbir istemci gruba katılmamıştır, bu nedenle ileti kaybı sorununa dönüşür.

Kaynak günlükleri olmadan istemcinin gruba ne zaman katılacağını ve grup iletisinin ne zaman gönderildiğini öğrenemezsiniz. Mesajlaşma günlüklerini etkinleştirdikten sonra SignalR hizmetinde gelen iletiyi karşılaştırabilirsiniz. Sorun gidermek için aşağıdaki adımları uygulayın:

1. İstemcinin gruba ne zaman katıldığını ve grup iletisinin ne zaman gönderildiğini bulmak için sunucuda ileti günlüklerini bulun.
2. Gruba katılmanın A ileti izleme kimliğini ve ileti günlüklerinden grup iletisinin ileti izleme kimliği B'yi alın.
3. Bu ileti izleme kimliğini günlük arşiv hedefinizdeki mesajlaşma günlükleri arasında filtreleyin, ardından gelen zaman damgalarını karşılaştırın. SignalR hizmetine ilk gelen iletiyi bulursunuz.
4. İleti izleme kimliği Gelen saat B gelen saatinden sonraysa, istemci gruba katılmadan önce grup iletisi gönderiyor olmanız gerekir. Grup iletileri göndermeden önce istemcinin grupta olduğundan emin olmanız gerekir.

SignalR veya sunucuda bir ileti kaybolursa, nedeni almak için ileti izleme kimliğine göre uyarı günlüklerini almayı deneyin. Daha fazla yardıma ihtiyacınız varsa yardım alma bölümüne bakın.

Davranış toplayan kaynak günlükleri

Özellikle mesajlaşma günlükleri için kaynak günlüklerini kullanmaya yönelik iki tipik senaryo vardır.

Birisi her iletinin kalitesine önem verebilir. Örneğin, iletinin başarıyla gönderilip gönderilmediği/alındığı konusunda hassastırlar veya SignalR hizmeti aracılığıyla teslim edilen her iletiyi kaydetmek isterler.

Bu arada, diğerleri performansı önemser. İletinin gecikme süresi konusunda hassastırlar ve bazen herhangi bir nedenle tüm bağlantılar yerine birkaç bağlantıda iletiyi izlemeleri gerekir.

Bu nedenle SignalR hizmeti iki tür toplama davranışı sağlar

• tümünü topla: Tüm bağlantılarda günlükleri toplama
• kısmen toplama: bazı belirli bağlantılarda günlükleri toplama

Not

SignalR hizmeti, günlükleri toplayanlar ile günlükleri toplamayanlar arasındaki bağlantıları ayırt etmek için bazı istemcilere, kaynak günlüklerinin her zaman toplandığı, diğerleri ise toplanmayan sunucu ve istemcinin tanılama istemci yapılandırmalarına göre tanılama istemcisi olarak davranır. Daha fazla bilgi için kısmi olarak toplama bölümüne bakın.

Tümünü topla

Kaynak günlükleri tüm bağlantılar tarafından toplanır. Örneğin mesajlaşma günlüklerini alın. Bu davranış etkinleştirildiğinde SignalR hizmeti, her ileti için izleme kimliği oluşturmaya başlamak için sunucuya bir bildirim gönderir. İzleme kimliği iletide hizmete taşınır. Hizmet ayrıca iletiyi izleme kimliğiyle günlüğe kaydeder.

Not

SignalR hizmetinin performansını sağlamak için SignalR hizmetinin istemciden gönderilen iletinin tamamını beklemediğini ve ayrıştırmadığını unutmayın. Bu nedenle, istemci iletileri günlüğe kaydedilmez. İstemci bir tanılama istemcisi olarak işaretlenmişse, istemci iletisi SignalR hizmetinde günlüğe kaydedilir.

Yapılandırma kılavuzu

Bu davranışı etkinleştirmek için Günlük Kaynağı Ayarlar Türler bölümündeki onay kutusunu işaretleyin.

Bu davranış, sunucu tarafı yapılandırmalarını güncelleştirmenizi gerektirmez. Bu yapılandırma değişikliği her zaman otomatik olarak sunucuya gönderilir.

Kısmen toplama

Kaynak günlükleri yalnızca tanılama istemcileri tarafından toplanır. Tanılama istemcilerindeki istemci iletileri ve bağlantı olayları da dahil olmak üzere tüm iletiler günlüğe kaydedilir.

Not

Tanılama istemcilerinin sayısının sınırı 100'dür. Tanılama istemcilerinin sayısı 100'ü aşarsa, sayıca az olan tanılama istemcileri SignalR hizmeti tarafından kısıtlanır. Yeni ancak sayıca fazla olan istemciler SignalR hizmetine bağlanamaz ve iletisine Response status code does not indicate success: 429 (Too Many Requests)sahip olan değerini oluştururSystem.Net.Http.HttpRequestException. Zaten bağlı olan istemciler azaltma ilkesinden etkilenmeden çalışır.

Tanılama istemcisi

Tanılama istemcisi mantıksal bir kavramdır. Herhangi bir istemci bir tanılama istemcisi olabilir. Sunucu, hangi istemcinin tanılama istemcisi olabileceğini denetler. bir istemci tanılama istemcisi olarak işaretlendikten sonra, bu istemcide tüm kaynak günlükleri etkinleştirilir. İstemciyi tanılama istemcisi olarak ayarlamak için yapılandırma kılavuzuna bakın.

Yapılandırma kılavuzu

Bu davranışı etkinleştirmek için hizmet, sunucu ve istemci tarafı yapılandırmanız gerekir.

Hizmet tarafı

Bu davranışı etkinleştirmek için, Günlük Kaynağı Ayarlar Türler bölümünde belirli bir günlük türünün onay kutusunun işaretini kaldırın.

Sunucu tarafı

Ayrıca http bağlamını temel alan tanılama istemcilerinin filtresini tanımlamak için de ayarlayın ServiceOptions.DiagnosticClientFilter . Örneğin, hub URL'si <HUB_URL>?diag=yesile istemci yapın, ardından tanılama istemcisini filtrelemek için ayarlayın ServiceOptions.DiagnosticClientFilter . döndürürse true, istemci tanılama istemcisi olarak işaretlenir. Aksi takdirde normal istemci olarak kalır. ServiceOptions.DiagnosticClientFilter başlangıç sınıfınızda şu şekilde ayarlanabilir:

// 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();
}

İstemci tarafı

http bağlamını yapılandırarak istemciyi tanılama istemcisi olarak işaretleyin. Örneğin, istemci sorgu dizesi diag=yeseklenerek tanılama istemcisi olarak işaretlenir.

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

Yardım alın

Önce kendi başınıza sorun gidermenizi öneririz. Sorunların çoğu uygulama sunucusu veya ağ sorunlarında kaynaklanıyor. Kök nedeni bulmak için kaynak günlüğü ve temel sorun giderme kılavuzu ile sorun giderme kılavuzunu izleyin. Sorun hala çözülemiyorsa GitHub'da bir sorun açmayı veya Azure portalında bilet oluşturmayı göz önünde bulundurun. Sağlamak:

1. Sorunun oluştuğu zaman aralığı yaklaşık 30 dakikadır
2. Azure SignalR Hizmeti kaynak kimliği
3. Sorun ayrıntıları, mümkün olduğunca ayrıntılı: Örneğin, appserver ileti göndermez, istemci bağlantısı düşer vb.
4. Sunucu/istemci tarafından toplanan günlükler ve yararlı olabilecek diğer malzemeler
5. [İsteğe bağlı] Yeniden oluşturma kodu

Not

GitHub'da bir sorun açarsanız hassas bilgilerinizi (örneğin, kaynak kimliği, sunucu/istemci günlükleri) gizli tutun. Yalnızca Microsoft kuruluşundaki üyelere özel olarak gönderin.