Monitorowanie usługi SignalR Service przy użyciu dzienników zasobów

W tym artykule opisano sposób używania funkcji usługi Azure Monitor do analizowania i rozwiązywania problemów z danymi monitorowania dzienników zasobów wygenerowanymi przez usługę Azure SignalR.

Strona Przegląd w witrynie Azure Portal dla każdej usługi Azure SignalR Service zawiera krótki widok użycia zasobów, taki jak równoczesne połączenia i liczba komunikatów. Te przydatne informacje to tylko niewielka ilość danych monitorowania dostępnych w portalu. Niektóre z tych danych są zbierane automatycznie i są dostępne do analizy zaraz po utworzeniu zasobu.

Po zakończeniu konfiguracji można włączyć inne typy zbierania danych. W tym artykule opisano konfigurowanie zbierania danych dzienników oraz analizowanie i rozwiązywanie problemów z danymi przy użyciu narzędzi usługi Azure Monitor.

• Aby uzyskać więcej informacji na temat monitorowania usługi Azure SignalR Service, zobacz Monitorowanie usługi Azure SignalR Service.
• Aby uzyskać szczegółową listę metryk i dzienników zebranych dla usługi Azure SignalR Service, zobacz Dokumentacja danych monitorowania usługi Azure SignalR Service.

Wymagania wstępne

Aby włączyć dzienniki zasobów, należy skonfigurować miejsce do przechowywania danych dziennika, takich jak Azure Storage lub Log Analytics.

• Usługa Azure Storage zachowuje dzienniki zasobów na potrzeby inspekcji zasad, analizy statycznej lub tworzenia kopii zapasowej.
• Log Analytics to elastyczne narzędzie do wyszukiwania dzienników i analizy, które umożliwia analizowanie nieprzetworzonych dzienników generowanych przez zasób platformy Azure.

Włączanie dzienników zasobów

Usługa Azure SignalR Service obsługuje dzienniki łączności, dzienniki obsługi komunikatów i dzienniki żądań HTTP. Aby uzyskać więcej informacji na temat tych typów dzienników, zobacz Kategorie dzienników zasobów. Dzienniki są przechowywane na koncie magazynu skonfigurowanym w okienku Dzienniki diagnostyczne. Aby uzyskać więcej informacji na temat formatu magazynu i pól, zobacz Magazyn danych.

Tworzenie ustawień diagnostycznych

Dzienniki zasobów są domyślnie wyłączone. Aby włączyć dzienniki zasobów przy użyciu ustawień diagnostycznych, zobacz Tworzenie ustawień diagnostycznych w usłudze Azure Monitor.

Wykonywanie zapytań dotyczących dzienników zasobów

Aby wykonać zapytanie dotyczące dzienników zasobów, wykonaj następujące kroki:

1. Wybierz pozycję Dzienniki w docelowej usłudze Log Analytics.

   

2. Wprowadź ciąg SignalRServiceDiagnosticLogs i wybierz zakres czasu. Aby uzyskać zaawansowane zapytanie, zobacz Rozpoczynanie pracy z usługą Log Analytics w usłudze Azure Monitor

   

Aby użyć przykładowych zapytań dla usługi Azure SignalR Service, wykonaj następujące kroki:

1. Wybierz pozycję Dzienniki w docelowej usłudze Log Analytics.

2. Wybierz kartę Zapytania , aby otworzyć eksploratora zapytań.

3. Wybierz pozycję Typ zasobu, aby zgrupować przykładowe zapytania w typie zasobu.

4. Wybierz pozycję Uruchom , aby uruchomić skrypt.

   

Na przykład zapytania dotyczące usługi Azure SignalR Service można znaleźć w temacie Zapytania dotyczące tabeli SignalRServiceDiagnosticLogs.

Uwaga

Nazwy pól zapytań dla miejsc docelowych magazynu różnią się nieco od nazw pól dla usługi Log Analytics. Aby uzyskać szczegółowe informacje na temat mapowań nazw pól między tabelami usługi Storage i Log Analytics, zobacz Mapowanie tabeli dziennika zasobów.

Rozwiązywanie problemów z dziennikami zasobów

Aby rozwiązać problemy z usługą Azure SignalR Service, możesz włączyć dzienniki po stronie serwera/klienta w celu przechwycenia błędów. Gdy usługa Azure SignalR Service uwidacznia dzienniki zasobów, możesz skorzystać z dzienników zasobów w celu rozwiązywania problemów z dziennikami usługi.

Problemy związane z połączeniem

W przypadku nieoczekiwanego zwiększania lub upuszczania połączeń można skorzystać z dzienników łączności w celu rozwiązania problemów. Typowe problemy często obejmują nieoczekiwane zmiany liczby połączeń, połączenia osiągną limity połączeń i niepowodzenie autoryzacji. W poniższych sekcjach opisano sposób rozwiązywania problemów.

Nieoczekiwane porzucanie połączenia

Jeśli wystąpi nieoczekiwany spadek połączeń, najpierw włącz dzienniki po stronie usługi, serwera i klienta.

Jeśli połączenie zostanie rozłączone, dzienniki zasobów rejestrują to zdarzenie rozłączania i widzisz ConnectionAborted polecenie lub ConnectionEnded w operationNamepliku .

Różnica między ConnectionAborted i ConnectionEnded polega ConnectionEnded na oczekiwanym rozłączeniu, które jest wyzwalane przez klienta lub po stronie serwera. Jest ConnectionAborted to zwykle nieoczekiwane zdarzenie porzucania połączenia, a przyczyna przerwania jest podana w pliku message.

W poniższej tabeli wymieniono przyczyny przerwania.

Przyczyna	opis
Liczba połączeń osiąga limit	Liczba połączeń osiąga limit bieżącej warstwy cenowej. Rozważ skalowanie w górę jednostki usługi
Serwer aplikacji zamknął połączenie	Serwer aplikacji wyzwala aborcję. Można ją uznać za oczekiwaną aborcję
Przekroczenie limitu czasu polecenia ping połączenia	Zazwyczaj jest to spowodowane problemem z siecią. Rozważ sprawdzenie dostępności serwera aplikacji z Internetu
Ponowne ładowanie usługi, spróbuj ponownie nawiązać połączenie	Usługa Azure SignalR Service jest ładowana ponownie. Usługa Azure SignalR obsługuje automatyczne ponowne łączenie. Możesz poczekać na ponowne nawiązanie połączenia lub ręczne ponowne nawiązanie połączenia z usługą Azure SignalR Service
Wewnętrzny błąd przejściowy serwera	Błąd przejściowy występuje w usłudze Azure SignalR Service, powinien zostać automatycznie odzyskany
Przerwane połączenie serwera	Pomiń połączenie serwera z nieznanym błędem. Najpierw rozważ samodzielne rozwiązywanie problemów z dziennikiem po stronie usługi/serwera/klienta. Spróbuj wykluczyć podstawowe problemy (np. problem z siecią, problem po stronie serwera aplikacji itp.). Jeśli problem nie został rozwiązany, skontaktuj się z nami, aby uzyskać dalszą pomoc. Aby uzyskać więcej informacji, zobacz sekcję Uzyskiwanie pomocy .

Nieoczekiwane zwiększanie połączenia

Aby rozwiązać problemy z nieoczekiwanym wzrostem połączenia, najpierw należy odfiltrować dodatkowe połączenia. Możesz dodać unikatowy identyfikator użytkownika testowego do połączenia klienta testowego. Sprawdź dzienniki zasobów. Jeśli widzisz, że więcej niż jedno połączenie klienta ma ten sam identyfikator użytkownika testowego lub adres IP, prawdopodobnie po stronie klienta jest tworzonych więcej połączeń niż oczekiwano. Sprawdź stronę klienta.

Błąd autoryzacji

Jeśli otrzymasz komunikat 401 Brak autoryzacji zwrócony dla żądań klientów, sprawdź dzienniki zasobów. Jeśli napotkasz Failed to validate audience. Expected Audiences: <valid audience>. Actual Audiences: <actual audience>metodę , oznacza to, że wszystkie grupy odbiorców w tokenie dostępu są nieprawidłowe. Spróbuj użyć prawidłowych odbiorców sugerowanych w dzienniku.

Ograniczanie przepływności

Jeśli okaże się, że nie możesz ustanowić połączeń klienta usługi SignalR z usługą Azure SignalR Service, sprawdź dzienniki zasobów. Jeśli napotkasz Connection count reaches limit dziennik zasobów, ustanowisz zbyt wiele połączeń z usługą SignalR Service, która osiągnie limit liczby połączeń. Rozważ skalowanie w górę usługi SignalR Service. Jeśli wystąpisz Message count reaches limit w dzienniku zasobów, oznacza to, że używasz warstwy Bezpłatna i użyto limitu przydziału komunikatów. Jeśli chcesz wysłać więcej komunikatów, rozważ zmianę usługi SignalR Service na warstwę Standardowa. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure SignalR Service.

Problemy związane z komunikatami

Podczas rozwiązywania problemów związanych z komunikatami można skorzystać z dzienników obsługi komunikatów. Najpierw włącz dzienniki zasobów w usłudze i dziennikach dla serwera i klienta.

Uwaga

Aby uzyskać ASP.NET Core, zobacz tutaj , aby włączyć rejestrowanie na serwerze i kliencie.

Aby uzyskać ASP.NET, zobacz tutaj , aby włączyć rejestrowanie na serwerze i kliencie.

Jeśli nie masz nic przeciwko potencjalnym skutkom wydajności i nie ma komunikatu typu klient-serwer, zaewidencjonuj Messaging element , Log Source Settings/Types aby włączyć zachowanie zbierania wszystkich dzienników. Aby uzyskać więcej informacji na temat tego zachowania, zobacz zbieranie wszystkich elementów .

W przeciwnym razie usuń zaznaczenie pola Messaging wyboru , aby włączyć zachowanie zbierania częściowych dzienników. To zachowanie wymaga skonfigurowania w kliencie i serwerze, aby ją włączyć. Aby uzyskać więcej informacji, zobacz zbieranie częściowe.

Utrata komunikatów

Jeśli wystąpią problemy z utratą komunikatów, kluczem jest zlokalizowanie miejsca utraty komunikatu. Zasadniczo masz trzy składniki podczas korzystania z usługi Azure SignalR Service: usługi SignalR Service, serwera i klienta. Zarówno serwer, jak i klient są połączone z usługą SignalR, ale nie łączą się ze sobą bezpośrednio po zakończeniu negocjacji. W związku z tym należy wziąć pod uwagę dwa kierunki dla komunikatów, a dla każdego kierunku należy wziąć pod uwagę dwie ścieżki:

• Z klienta na serwer za pośrednictwem usługi SignalR
  • Ścieżka 1. Klient do usługi SignalR
  • Ścieżka 2. Usługa SignalR do serwera
• Z serwera do klienta za pośrednictwem usługi SignalR
  • Ścieżka 3: Serwer do usługi SignalR
  • Ścieżka 4. Usługa SignalR do klienta

Aby zebrać wszystkie zachowania zbierania:

Usługa Azure SignalR Service śledzi komunikaty tylko w kierunku od serwera do klienta za pośrednictwem usługi SignalR Service. Identyfikator śledzenia jest generowany na serwerze. Komunikat przenosi identyfikator śledzenia do usługi SignalR.

Uwaga

Jeśli chcesz śledzić komunikaty i wysyłać komunikaty spoza centrum na serwerze aplikacji, należy włączyć zbieranie wszystkich zachowań zbierania w celu zbierania dzienników komunikatów dla komunikatów, które nie pochodzą z klientów diagnostycznych. Klienci diagnostycy pracują zarówno w przypadku zbierania wszystkich, jak i zbierania częściowo zbieranych zachowań, ale mają wyższy priorytet w celu zbierania dzienników. Aby uzyskać więcej informacji, zobacz sekcję klienta diagnostycznego.

Sprawdzając po stronie serwera logowania i usługi, możesz łatwo sprawdzić, czy komunikat jest wysyłany z serwera, dociera do usługi SignalR i opuszcza usługę SignalR. Zasadniczo, sprawdzając, czy odebrana i wysłana wiadomość jest zgodna, czy nie jest zgodna z identyfikatorem śledzenia komunikatów, możesz określić, czy problem z utratą komunikatów znajduje się na serwerze lub w usłudze SignalR w tym kierunku. Aby uzyskać więcej informacji, zobacz poniższe szczegóły .

W przypadku zbierania częściowo zbieranych zachowań:

Po oznaczeniu klienta jako klienta diagnostycznego usługa Azure SignalR Service śledzi komunikaty w obu kierunkach.

Sprawdzając stronę serwera logowania i usługi, możesz łatwo sprawdzić, czy komunikat jest przekazywany pomyślnie przez serwer, czy usługę SignalR. Zasadniczo, sprawdzając, czy odebrana i wysłana wiadomość jest zgodna, czy nie jest zgodna z identyfikatorem śledzenia komunikatów, możesz określić, czy problem z utratą komunikatów znajduje się na serwerze, czy w usłudze SignalR. Aby uzyskać więcej informacji, zobacz następujące szczegóły.

Szczegóły przepływu komunikatów

W przypadku kierunku od klienta do serwera za pośrednictwem usługi SignalR service usługa SignalR uwzględnia wywołanie pochodzące tylko z klienta diagnostycznego, czyli komunikat wygenerowany bezpośrednio w kliencie diagnostycznym lub komunikat usługi wygenerowany pośrednio z powodu wywołania klienta diagnostycznego.

Identyfikator śledzenia jest generowany w usłudze SignalR po nadejściu komunikatu do usługi SignalR w ścieżce 1. Usługa SignalR generuje dziennik Received a message <MessageTracingId> from client connection <ConnectionId>. dla każdego komunikatu w kliencie diagnostycznym. Po opuszczeniu komunikatu z usługi SignalR do serwera usługa SignalR generuje komunikat Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.dziennika . Jeśli widzisz te dwa dzienniki, możesz mieć pewność, że komunikat przechodzi przez usługę SignalR service pomyślnie.

Uwaga

Ze względu na ograniczenie ASP.NET Core SignalR komunikat pochodzi z klienta nie zawiera żadnego identyfikatora poziomu komunikatu, ale ASP.NET SignalR generuje identyfikator wywołania dla każdego komunikatu. Można go użyć do mapowania za pomocą identyfikatora śledzenia.

Następnie komunikat zawiera serwer identyfikatora śledzenia w ścieżce 2. Serwer generuje dziennik Received message <messagetracingId> from client connection <connectionId> po nadejściu komunikatu.

Po wywołaniu metody centrum na serwerze zostanie wygenerowany nowy komunikat usługi z nowym identyfikatorem śledzenia. Po wygenerowaniu komunikatu usługi serwer generuje szablon Start to broadcast/send message <MessageTracingId> ...logowania . Rzeczywisty dziennik jest oparty na twoim scenariuszu. Następnie komunikat jest dostarczany do usługi SignalR w ścieżce 3. Po opuszczeniu komunikatu usługi z serwera zostanie wygenerowany dziennik o nazwie Succeeded to send message <MessageTracingId> .

Uwaga

Identyfikator śledzenia komunikatu od klienta nie może mapować na identyfikator śledzenia komunikatu usługi, który ma zostać wysłany do usługi SignalR.

Po nadejściu komunikatu usługi do usługi SignalR jest generowany dziennik o nazwie Received a <MessageType> message <MessageTracingId> from server connection <ConnectionId>. . Następnie usługa SignalR przetwarza komunikat usługi i dostarcza do klientów docelowych. Po wysłaniu komunikatu do klientów w ścieżce 4 jest generowany dziennik Sent a message <MessageTracingId> to client connection <ConnectionId> successfully. .

Podsumowując, dziennik komunikatów jest generowany, gdy komunikat przechodzi do i z usługi SignalR i serwera. Za pomocą tych dzienników można sprawdzić, czy komunikat zostanie utracony w tych składnikach, czy nie.

Poniższy przykład to typowy problem z utratą komunikatów.

Klient nie może odbierać komunikatów w grupie

Typowy scenariusz w tym problemie polega na tym, że klient dołącza do grupy po wysłaniu komunikatu grupy.

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
    }
}

Na przykład ktoś może wywołać grupę sprzężenia i wysłać komunikat grupy w tej samej metodzie centrum. Problem polega na AddToGroupAsync metodzie async . Ponieważ nie await ma potrzeby oczekiwania na AddToGroupAsync zakończenie, wiadomość grupy jest wysyłana przed zakończeniem AddToGroupAsync . Ze względu na opóźnienie sieci i opóźnienie procesu dołączania klienta do niektórych grup akcja grupy dołączania może zakończyć się później niż dostarczanie komunikatów grupy grupowej. Jeśli tak, pierwszy komunikat grupy nie ma żadnego klienta jako odbiornika, ponieważ żaden klient nie dołączył do grupy, więc staje się komunikatem utraconym problemem.

Bez dzienników zasobów nie można dowiedzieć się, kiedy klient dołącza do grupy i kiedy jest wysyłany komunikat grupy. Po włączeniu dzienników obsługi komunikatów możesz porównać czas przybycia komunikatu w usłudze SignalR. Wykonaj następujące kroki, aby rozwiązać problemy:

1. Znajdź dzienniki komunikatów na serwerze, aby znaleźć, kiedy klient dołączył do grupy i kiedy jest wysyłany komunikat grupy.
2. Pobierz identyfikator śledzenia komunikatów A dołączania do grupy i identyfikator śledzenia komunikatów B komunikatu grupy z dzienników komunikatów.
3. Przefiltruj te identyfikatory śledzenia komunikatów między dziennikami w docelowym obiekcie docelowym archiwum dziennika, a następnie porównaj ich przychodzące znaczniki czasu. Okaże się, który komunikat dotarł najpierw do usługi SignalR.
4. Jeśli identyfikator śledzenia komunikatów Godzina przybycia jest późniejsza niż godzina przybycia B, musisz wysłać komunikat grupy przed dołączeniem klienta do grupy. Przed wysłaniem komunikatów grupy należy upewnić się, że klient znajduje się w grupie.

Jeśli komunikat zostanie utracony w usłudze SignalR lub serwerze, spróbuj pobrać dzienniki ostrzegawcze na podstawie identyfikatora śledzenia komunikatów, aby uzyskać przyczynę. Jeśli potrzebujesz dalszej pomocy, zapoznaj się z sekcją Uzyskiwanie pomocy.

Zbieranie zachowań dzienników zasobów

Istnieją dwa typowe scenariusze używania dzienników zasobów, szczególnie w przypadku dzienników obsługi komunikatów.

Ktoś może dbać o jakość każdej wiadomości. Na przykład są one wrażliwe na to, czy wiadomość została wysłana/odebrana pomyślnie, czy chce zarejestrować każdy komunikat dostarczany za pośrednictwem usługi SignalR Service.

W międzyczasie inni mogą dbać o wydajność. Są one wrażliwe na opóźnienie komunikatu, a czasami muszą śledzić komunikat w kilku połączeniach zamiast wszystkich połączeń z jakiegoś powodu.

W związku z tym usługa SignalR udostępnia dwa rodzaje zachowań zbierania

• zbieranie wszystkich: zbieranie dzienników we wszystkich połączeniach
• zbieranie częściowe: zbieranie dzienników w niektórych określonych połączeniach

Uwaga

Aby odróżnić połączenia między tymi dziennikami zbierania i nie zbierają dzienników, usługa SignalR traktuje klienta jako klienta diagnostycznego na podstawie konfiguracji klienta diagnostycznego serwera i klienta, w którym dzienniki zasobów są zawsze zbierane, podczas gdy inne nie. Aby uzyskać więcej informacji, zobacz zbieranie częściowej sekcji.

Zbierz wszystkie

Dzienniki zasobów są zbierane przez wszystkie połączenia. Weź na przykład dzienniki obsługi komunikatów. Po włączeniu tego zachowania usługa SignalR wysyła powiadomienie do serwera, aby rozpocząć generowanie identyfikatora śledzenia dla każdego komunikatu. Identyfikator śledzenia jest przenoszony w komunikacie do usługi. Usługa rejestruje również komunikat z identyfikatorem śledzenia.

Uwaga

Należy pamiętać, że aby zapewnić wydajność usługi SignalR, usługa SignalR nie oczekuje i analizuje cały komunikat wysłany z klienta. W związku z tym komunikaty klienta nie są rejestrowane. Jeśli klient jest oznaczony jako klient diagnostyczny, komunikat klienta jest rejestrowany w usłudze SignalR Service.

Przewodnik po konfiguracji

Aby włączyć to zachowanie, zaznacz pole wyboru w sekcji Typy w ustawieniach źródła dziennika.

To zachowanie nie wymaga aktualizacji konfiguracji po stronie serwera. Ta zmiana konfiguracji jest zawsze wysyłana automatycznie do serwera.

Zbieranie częściowe

Dzienniki zasobów są zbierane tylko przez klientów diagnostycznych. Wszystkie komunikaty są rejestrowane, w tym komunikaty klienta i zdarzenia łączności w klientach diagnostycznych.

Uwaga

Limit liczby klientów diagnostycznych wynosi 100. Jeśli liczba klientów diagnostycznych przekroczy 100, liczba klientów diagnostycznych przekracza liczbę klientów diagnostycznych ograniczana przez usługę SignalR. Nowi, ale przewyższający liczbę klientów nie mogą nawiązać połączenia z usługą SignalR i zgłaszają System.Net.Http.HttpRequestExceptionkomunikat z komunikatem Response status code does not indicate success: 429 (Too Many Requests). Już połączeni klienci działają bez wpływu na zasady ograniczania przepustowości.

Klient diagnostyczny

Klient diagnostyczny to pojęcie logiczne. Każdy klient może być klientem diagnostycznym. Serwer kontroluje, który klient może być klientem diagnostycznym. Po oznaczeniu klienta jako klienta diagnostycznego wszystkie dzienniki zasobów są włączone w tym kliencie. Aby ustawić klienta jako klienta diagnostycznego, zobacz przewodnik konfiguracji.

Przewodnik po konfiguracji

Aby włączyć to zachowanie, należy skonfigurować usługę, serwer i stronę klienta.

Strona usługi

Aby włączyć to zachowanie, usuń zaznaczenie pola wyboru dla określonego typu dziennika w sekcji Typy w ustawieniach źródła dziennika.

Strona serwera

Skonfiguruj również w ServiceOptions.DiagnosticClientFilter celu zdefiniowania filtru klientów diagnostycznych na podstawie kontekstu http pochodzącego z klientów. Na przykład utwórz klienta przy użyciu adresu URL <HUB_URL>?diag=yescentrum, a następnie skonfiguruj go ServiceOptions.DiagnosticClientFilter do filtrowania klienta diagnostycznego. Jeśli zwróci truewartość , klient zostanie oznaczony jako klient diagnostyczny. W przeciwnym razie pozostaje on tak normalnym klientem. Element ServiceOptions.DiagnosticClientFilter można ustawić w klasie uruchamiania w następujący sposób:

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

Strona klienta

Oznacz klienta jako klienta diagnostycznego, konfigurując kontekst http. Na przykład klient jest oznaczony jako klient diagnostyczny przez dodanie ciągu diag=yeszapytania .

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

Uzyskaj pomoc

Zalecamy samodzielne rozwiązywanie problemów. Większość problemów jest spowodowana problemami z serwerem aplikacji lub siecią. Postępuj zgodnie z przewodnikiem rozwiązywania problemów z dziennikiem zasobów i podstawowym przewodnikiem rozwiązywania problemów, aby znaleźć główną przyczynę. Jeśli problem nadal nie może zostać rozwiązany, rozważ otwarcie problemu w usłudze GitHub lub utworzenie biletu w witrynie Azure Portal. Dostarczać:

1. Zakres czasu około 30 minut, gdy wystąpi problem
2. Identyfikator zasobu usługi Azure SignalR Service
3. Szczegóły problemu, jak to możliwe: na przykład serwer aplikacji nie wysyła komunikatów, przerywa połączenia klienta itd.
4. Dzienniki zebrane po stronie serwera/klienta i inne materiały, które mogą być przydatne
5. [Opcjonalnie] Kod odtworzenia

Uwaga

Jeśli otworzysz problem w usłudze GitHub, zachowaj prywatne informacje poufne (na przykład identyfikator zasobu, dzienniki serwera/klienta). Wysyłaj tylko do członków w organizacji firmy Microsoft prywatnie.