Udostępnij za pośrednictwem

Jak rozwiązywać problemy z łącznością i dostarczaniem komunikatów

  • Artykuł

W tych wskazówkach przedstawiono kilka sposobów samodzielnej diagnostyki, aby znaleźć główną przyczynę bezpośrednio lub zawęzić problem. Wynik samodzielnej diagnostyki jest również przydatny podczas zgłaszania go do nas w celu dalszego zbadania.

Najpierw należy sprawdzić w witrynie Azure Portal, do której parametr ServiceMode jest usługą Azure SignalR Service (znaną również jako ASRS).

ServiceMode

Po drugie, należy przechwycić ślady usługi, aby rozwiązać problemy. Aby uzyskać informacje na temat przechwytywania śladów, zobacz Jak przechwytywać ślady usługi.

Masz problemy lub opinie dotyczące rozwiązywania problemów? Daj nam znać.

Jak przechwytywać ślady usługi

Aby uprościć proces rozwiązywania problemów, usługa Azure SignalR service udostępnia narzędzie do śledzenia na żywo w celu uwidaczniania śladów usługi w kategoriach łączności i obsługi komunikatów. Ślady obejmują, ale nie są ograniczone do zdarzeń połączenia połączonych/rozłączonych i odebranych/pozostawionych komunikatów. Za pomocą narzędzia do śledzenia na żywo można przechwytywać, wyświetlać, sortować, filtrować i eksportować ślady na żywo. Aby uzyskać więcej informacji, zobacz Jak używać narzędzia do śledzenia na żywo.

Masz problemy lub opinie dotyczące rozwiązywania problemów? Daj nam znać.

Rozwiązywanie problemów z trybem domyślnym

Gdy usługa ASRS jest w trybie domyślnym , istnieją trzy role: Klient, Serwer i Usługa:

  • Klient: Klient oznacza klientów połączonych z usługą ASRS. Połączenia trwałe łączące klienta i usługi ASRS są nazywane Połączenie klienta w tych wskazówkach.

  • Serwer: serwer to serwer obsługujący negocjacje klienta i hostujący logikę usługi SignalRHub. A trwałe połączenia między serwerem a usługą ASRS są nazywane Połączenie serwera w tych wskazówkach.

  • Usługa: usługa jest krótką nazwą usługi ASRS w tych wskazówkach.

Zapoznaj się z tematem Internals of Azure SignalR Service (Wewnętrzne elementy usługi Azure SignalR Service ), aby zapoznać się ze szczegółowym wprowadzeniem całej architektury i przepływu pracy.

Istnieje kilka sposobów, które mogą pomóc w zawężaniu problemu.

  • Jeśli problem występuje w taki sposób lub jest w stanie odtworzyć, prosta droga polega na wyświetlaniu ruchu przychodzącego.

  • Jeśli problem jest trudny do odtworzenia, ślady i dzienniki mogą pomóc.

Jak wyświetlić ruch i zawęzić problem

Przechwytywanie ruchu przychodzącego jest najprostszym sposobem zawężenia problemu. Ślady sieci można przechwycić, korzystając z opcji opisanych poniżej:

Żądania klientów

W przypadku połączenia trwałego usługi SignalR najpierw /negotiate do serwera hostowanej aplikacji, a następnie przekierowania do usługi Azure SignalR, a następnie ustanawia rzeczywiste trwałe połączenie z usługą Azure SignalR. Szczegółowe instrukcje można znaleźć w artykule Internals of Azure SignalR Service (Wewnętrzne elementy usługi Azure SignalR Service ).

Korzystając z danych śledzenia sieci po stronie klienta, sprawdź, które żądanie kończy się niepowodzeniem z kodem stanu i odpowiedzią, i poszukaj rozwiązań w przewodniku rozwiązywania problemów.

Żądania serwera

Serwer SignalR obsługuje Połączenie serwera między serwerem a usługą. Po uruchomieniu serwera aplikacji zostanie uruchomione połączenie protokołu WebSocket z usługą Azure SignalR. Cały ruch klienta jest kierowany przez usługę Azure SignalR do tych serwerów Połączenie ions, a następnie wysyłany do usługi Hub. Gdy serwer Połączenie ion spadnie, będą mieć wpływ na klientów kierowanych do tego serwera Połączenie ion. Nasz zestaw SDK usługi Azure SignalR ma logikę "Zawsze ponów próbę", aby ponownie połączyć Połączenie serwera z maksymalnie 1-minutowym opóźnieniem, aby zminimalizować skutki.

Serwer Połączenie ionmoże spaść z powodu niestabilności sieci lub regularnej konserwacji usługi Azure SignalR Service lub aktualizacji/konserwacji serwera hostowanej aplikacji. Tak długo, jak po stronie klienta ma mechanizm rozłączania/ponownego nawiązywania połączenia, efekt jest minimalny, jak każdy klient po stronie klienta spowodował rozłączanie ponownie.

Wyświetl ślad sieci po stronie serwera, aby znaleźć kod stanu i szczegóły błędu, dlaczego serwer Połączenie ion spada lub jest odrzucany przez usługę. Poszukaj głównej przyczyny w przewodniku rozwiązywania problemów.

Masz problemy lub opinie dotyczące rozwiązywania problemów? Daj nam znać.

How to add logs (Jak dodawać dzienniki)

Dzienniki mogą być przydatne do diagnozowania problemów i monitorowania stanu działania.

Jak włączyć dziennik po stronie klienta

Środowisko rejestrowania po stronie klienta jest dokładnie takie samo jak w przypadku korzystania z własnego usługi SignalR.

Włączanie rejestrowania po stronie klienta dla programu ASP.NET Core SignalR
Włączanie rejestrowania po stronie klienta dla programu ASP.NET SignalR

Jak włączyć dziennik po stronie serwera

Włączanie rejestrowania po stronie serwera dla programu ASP.NET Core SignalR

Rejestrowanie po stronie serwera dla ASP.NET Core SignalR integracji z ILogger rejestrowaniem opartym na platformieASP.NET Core. Rejestrowanie po stronie serwera można włączyć przy użyciu metody ConfigureLogging, przykładowe użycie w następujący sposób:

.ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddConsole();
            logging.AddDebug();
        })

Kategorie rejestratora dla usługi Azure SignalR zawsze zaczynają się od Microsoft.Azure.SignalR. Aby włączyć szczegółowe dzienniki z usługi Azure SignalR, skonfiguruj poprzednie prefiksy na Information poziom w pliku appsettings.json , jak pokazano poniżej:

{
    "Logging": {
        "LogLevel": {
            ...
            "Microsoft.Azure.SignalR": "Information",
            ...
        }
    }
}

Sprawdź, czy nie zarejestrowano żadnych nietypowych dzienników ostrzeżeń/błędów.

Włączanie śladów po stronie serwera dla ASP.NET SignalR

W przypadku korzystania z wersji >zestawu SDK = 1.0.0można włączyć śledzenie, dodając następujące informacje do web.config: (Szczegóły)

<system.diagnostics>
    <sources>
      <source name="Microsoft.Azure.SignalR" switchName="SignalRSwitch">
        <listeners>
          <add name="ASRS" />
        </listeners>
      </source>
    </sources>
    <!-- Sets the trace verbosity level -->
    <switches>
      <add name="SignalRSwitch" value="Information" />
    </switches>
    <!-- Specifies the trace writer for output -->
    <sharedListeners>
      <add name="ASRS" type="System.Diagnostics.TextWriterTraceListener" initializeData="asrs.log.txt" />
    </sharedListeners>
    <trace autoflush="true" />
  </system.diagnostics>

Sprawdź, czy nie zarejestrowano żadnych nietypowych dzienników ostrzeżeń/błędów.

Jak włączyć dzienniki w usłudze Azure SignalR Service

Możesz również włączyć dzienniki diagnostyczne dla usługi Azure SignalR. Te dzienniki zawierają szczegółowe informacje o każdym połączeniu połączonym z usługą Azure SignalR.

Masz problemy lub opinie dotyczące rozwiązywania problemów? Daj nam znać.

Rozwiązywanie problemów z trybem bezserwerowy

Gdy usługa ASRS jest w trybie bezserwerowym, obsługuje Serverless tylko tryb ASP.NET Core SignalR, a usługa SignalR ASP.NET nie obsługuje tego trybu.

Aby zdiagnozować problemy z łącznością w Serverless trybie, najprostszym sposobem jest wyświetlenie ruchu po stronie klienta. Włączanie dzienników po stronie klienta i dzienników po stronie usługi może być również przydatne.

Masz problemy lub opinie dotyczące rozwiązywania problemów? Daj nam znać.

Rozwiązywanie problemów z trybem klasycznym

Classic tryb jest przestarzały i nie jest zachęcany do użycia. W trybie klasycznym usługa Azure SignalR używa połączonych Połączenie serwera w celu określenia, czy bieżąca usługa jest w default trybie lub serverless trybie. Tryb klasyczny może prowadzić do problemów z łącznością klienta pośredniego, ponieważ w przypadku nagłego spadku wszystkich połączonych Połączenie serwera, na przykład z powodu niestabilności sieci, usługa Azure SignalR uważa, że jest teraz przełączona do serverless trybu, a klienci połączeni w tym okresie nigdy nie będą kierowani do serwera hostowanej aplikacji. Włącz dzienniki po stronie usługi i sprawdź, czy istnieją jakieś klientów zarejestrowanych tak, jakby ServerlessModeEntered był hostowany serwer aplikacji, jednak niektórzy klienci nigdy nie docierają po stronie serwera aplikacji. Jeśli widzisz dowolnego z tych klientów, przerwij połączenia klienta, a następnie pozwól klientom na ponowne uruchomienie.

classic Rozwiązywanie problemów z łącznością w trybie i dostarczaniem komunikatów jest podobne do rozwiązywania problemów z trybem domyślnym.

Masz problemy lub opinie dotyczące rozwiązywania problemów? Daj nam znać.

Kondycja usługi

Możesz sprawdzić interfejs API kondycji pod kątem kondycji usługi.

  • Żądanie: GET https://{instance_name}.service.signalr.net/api/v1/health

  • Kod stanu odpowiedzi:

    • 200: zdrowy.
    • 503: Twoja usługa jest w złej kondycji. Można:
      • Poczekaj kilka minut na autorecover.
      • Sprawdź, czy adres IP jest taki sam jak adres IP z portalu.
      • Lub uruchom ponownie wystąpienie.
      • Jeśli wszystkie powyższe opcje nie działają, skontaktuj się z nami, dodając nowe żądanie pomocy technicznej w witrynie Azure Portal.

Więcej informacji o odzyskiwaniu po awarii.

Masz problemy lub opinie dotyczące rozwiązywania problemów? Daj nam znać.

Następne kroki

W tym przewodniku przedstawiono sposób rozwiązywania problemów z łącznością i dostarczaniem komunikatów. Możesz również dowiedzieć się, jak rozwiązywać typowe problemy.

Przewodnik rozwiązywania problemów