Kompleksowe rozwiązywanie problemów przy użyciu metryk i rejestrowania usługi Azure Storage, narzędzia AzCopy i narzędzia Message Analyzer

• Witryna Azure Portal

Diagnozowanie i rozwiązywanie problemów to kluczowa umiejętność tworzenia i obsługi aplikacji klienckich przy użyciu Microsoft Azure Storage. Ze względu na rozproszony charakter aplikacji platformy Azure diagnozowanie i rozwiązywanie problemów z błędami i wydajnością może być bardziej złożone niż w tradycyjnych środowiskach.

W tym samouczku pokazano, jak zidentyfikować pewne błędy, które mogą mieć wpływ na wydajność, i rozwiązać problemy z tymi błędami, korzystając z narzędzi dostarczanych przez firmę Microsoft i usługę Azure Storage, aby zoptymalizować aplikację kliencją.

Ten samouczek zawiera praktyczne omówienie kompleksowego scenariusza rozwiązywania problemów. Szczegółowy przewodnik koncepcyjny dotyczący rozwiązywania problemów z aplikacjami usługi Azure Storage można znaleźć w temacie Monitorowanie, diagnozowanie i rozwiązywanie problemów Microsoft Azure Storage.

Narzędzia do rozwiązywania problemów z aplikacjami usługi Azure Storage

Aby rozwiązać problemy z aplikacjami klienckimi przy użyciu Microsoft Azure Storage, możesz użyć kombinacji narzędzi, aby określić, kiedy wystąpił problem i jaka może być przyczyna problemu. Do tych narzędzi należą:

• Azure analityka magazynu. Usługa Azure analityka magazynu udostępnia metryki i rejestrowanie dla usługi Azure Storage.

  • Metryki magazynu śledzą metryki transakcji i metryki pojemności dla konta magazynu. Korzystając z metryk, możesz określić, jak aplikacja działa zgodnie z różnymi miarami. Aby uzyskać więcej informacji na temat typów metryk śledzonych przez analityka magazynu, zobacz analityka magazynu Metrics Schema (Schemat tabeli metryk metryk śledzonych przez analityka magazynu).
  • Rejestrowanie magazynu rejestruje każde żądanie do usług Azure Storage w dzienniku po stronie serwera. Dziennik śledzi szczegółowe dane dla każdego żądania, w tym wykonaną operację, stan operacji i informacje o opóźnieniu. Zobacz analityka magazynu Format dziennika, aby uzyskać więcej informacji na temat danych żądania i odpowiedzi zapisywanych w dziennikach przez analityka magazynu.

• Użycie witryny Azure Portal. Metryki i rejestrowanie dla konta magazynu można skonfigurować w Azure Portal. Możesz również wyświetlić wykresy i wykresy, które pokazują, jak działa aplikacja w czasie, i skonfigurować alerty w celu powiadamiania o tym, czy aplikacja działa inaczej niż oczekiwano dla określonej metryki.

  Aby uzyskać informacje na temat konfigurowania monitorowania w Azure Portal, zobacz Monitorowanie konta magazynu w Azure Portal.

• AzCopy. Dzienniki serwera dla usługi Azure Storage są przechowywane jako obiekty blob, więc możesz użyć narzędzia AzCopy do skopiowania obiektów blob dziennika do katalogu lokalnego na potrzeby analizy przy użyciu narzędzia Microsoft Message Analyzer. Aby uzyskać więcej informacji na temat narzędzia AzCopy, zobacz Transfer data with the AzCopy Command-Line Utility (Transfer danych za pomocą narzędzia AzCopy Command-Line Utility ).

• Microsoft Message Analyzer. Message Analyzer to narzędzie, które używa plików dziennika i wyświetla dane dziennika w formacie wizualnym, co ułatwia filtrowanie, wyszukiwanie i grupowanie danych dziennika w przydatnych zestawach, których można użyć do analizowania błędów i problemów z wydajnością. Aby uzyskać więcej informacji na temat analizatora komunikatów, zobacz Przewodnik operacyjny programu Microsoft Message Analyzer .

Informacje o przykładowym scenariuszu

W tym samouczku przeanalizujemy scenariusz, w którym metryki usługi Azure Storage wskazują niski procent powodzenia dla aplikacji, która wywołuje usługę Azure Storage. Metryka niskiego procentu sukcesu (wyświetlana jako PercentSuccess w Azure Portal i w tabelach metryk) śledzi operacje, które kończą się powodzeniem, ale zwracają kod stanu HTTP większy niż 299. W plikach dziennika magazynu po stronie serwera te operacje są rejestrowane ze stanem transakcji ClientOtherErrors. Aby uzyskać więcej informacji na temat metryki o niskim poziomie powodzenia, zobacz Metryki pokazujące niską wartość PercentSuccess lub wpisy dziennika analizy mają operacje ze stanem transakcji ClientOtherErrors.

Operacje usługi Azure Storage mogą zwracać kody stanu HTTP większe niż 299 w ramach normalnej funkcjonalności. Jednak te błędy w niektórych przypadkach wskazują, że możesz zoptymalizować aplikację kliencą w celu zwiększenia wydajności.

W tym scenariuszu rozważymy niski procent powodzenia poniżej 100%. Można jednak wybrać inny poziom metryki zgodnie z potrzebami. Zalecamy, aby podczas testowania aplikacji ustanowić tolerancję linii bazowej dla kluczowych metryk wydajności. Można na przykład określić, na podstawie testowania, że aplikacja powinna mieć spójny procent powodzenia wynoszący 90% lub 85%. Jeśli dane metryk pokazują, że aplikacja odbiega od tej liczby, możesz zbadać, co może spowodować wzrost.

W naszym przykładowym scenariuszu po ustaleniu, że metryka procentowa współczynnika powodzenia jest poniżej 100%, przeanalizujemy dzienniki, aby znaleźć błędy, które są skorelowane z metrykami, i użyjemy ich do ustalenia, co powoduje obniżenie współczynnika powodzenia. Przyjrzymy się konkretnie błędom w zakresie 400. Następnie dokładniej zbadamy błędy 404 (nie znaleziono).

Niektóre przyczyny błędów zakresu 400

W poniższych przykładach przedstawiono próbkowanie błędów z zakresu około 400 dla żądań dotyczących Azure Blob Storage i ich możliwych przyczyn. Każdy z tych błędów, a także błędy z zakresu 300 i zakresu 500, może przyczynić się do niskiego procentu sukcesu.

Zwróć uwagę, że poniższe listy są dalekie od ukończenia. Aby uzyskać szczegółowe informacje o ogólnych błędach usługi Azure Storage i o błędach specyficznych dla poszczególnych usług magazynu, zobacz Artykuł Status and Error Codes on MSDN (Kody stanu i błędów w witrynie MSDN).

Przykłady kodu stanu 404 (nie znaleziono)

Występuje, gdy operacja odczytu względem kontenera lub obiektu blob kończy się niepowodzeniem, ponieważ nie znaleziono obiektu blob lub kontenera.

• Występuje, jeśli kontener lub obiekt blob został usunięty przez innego klienta przed tym żądaniem.
• Występuje, jeśli używasz wywołania interfejsu API, które tworzy kontener lub obiekt blob po sprawdzeniu, czy istnieje. Interfejsy API CreateIfNotExists najpierw tworzą wywołanie HEAD, aby sprawdzić istnienie kontenera lub obiektu blob; Jeśli nie istnieje, zostanie zwrócony błąd 404, a następnie zostanie wykonane drugie wywołanie PUT w celu zapisania kontenera lub obiektu blob.

Przykłady kodu stanu 409 (konflikt)

• Występuje, jeśli używasz interfejsu API tworzenia do tworzenia nowego kontenera lub obiektu blob, bez wcześniejszego sprawdzania istnienia i kontenera lub obiektu blob o tej nazwie już istnieje.
• Występuje, jeśli kontener jest usuwany i próbujesz utworzyć nowy kontener o tej samej nazwie przed ukończeniem operacji usuwania.
• Występuje, jeśli określisz dzierżawę kontenera lub obiektu blob i istnieje już dzierżawa.

Przykłady kodu stanu 412 (niepowodzenie warunku wstępnego)

• Występuje, gdy warunek określony przez nagłówek warunkowy nie został spełniony.
• Występuje, gdy określony identyfikator dzierżawy jest niezgodny z identyfikatorem dzierżawy w kontenerze lub obiekcie blob.

Generowanie plików dziennika na potrzeby analizy

W tym samouczku użyjemy analizatora komunikatów do pracy z trzema różnymi typami plików dziennika, chociaż można wybrać jedną z następujących czynności:

• Dziennik serwera, który jest tworzony podczas włączania rejestrowania usługi Azure Storage. Dziennik serwera zawiera dane dotyczące każdej operacji wywoływanej względem jednej z usług Azure Storage — obiektów blob, kolejek, tabel i plików. Dziennik serwera wskazuje, która operacja została wywołana i jaki kod stanu został zwrócony, a także inne szczegóły dotyczące żądania i odpowiedzi.
• Dziennik klienta platformy .NET tworzony podczas włączania rejestrowania po stronie klienta z poziomu aplikacji .NET. Dziennik klienta zawiera szczegółowe informacje o sposobie przygotowania żądania i odebrania i przetworzenia odpowiedzi przez klienta.
• Dziennik śledzenia sieci HTTP, który zbiera dane dotyczące żądań HTTP/HTTPS i danych odpowiedzi, łącznie z operacjami w usłudze Azure Storage. W tym samouczku wygenerujemy ślad sieci za pomocą analizatora komunikatów.

Konfigurowanie rejestrowania i metryk po stronie serwera

Najpierw musimy skonfigurować rejestrowanie i metryki usługi Azure Storage, aby umożliwić analizowanie danych po stronie usługi. Rejestrowanie i metryki można skonfigurować na różne sposoby — za pośrednictwem Azure Portal, przy użyciu programu PowerShell lub programowo. Aby uzyskać szczegółowe informacje na temat konfigurowania rejestrowania i metryk, zobacz Włączanie metryk i Włączanie rejestrowania.

Konfigurowanie rejestrowania po stronie klienta platformy .NET

Aby skonfigurować rejestrowanie po stronie klienta dla aplikacji .NET, włącz diagnostykę platformy .NET w pliku konfiguracji aplikacji (web.config lub app.config). Aby uzyskać szczegółowe informacje, zobacz Rejestrowanie po stronie klienta przy użyciu biblioteki klienta usługi Storage platformy .NET i rejestrowania po stronie klienta przy użyciu zestawu SDK Microsoft Azure Storage dla języka Java w witrynie MSDN.

Dziennik po stronie klienta zawiera szczegółowe informacje o sposobie przygotowania żądania i odebrania i przetworzenia odpowiedzi przez klienta.

Biblioteka klienta magazynu przechowuje dane dziennika po stronie klienta w lokalizacji określonej w pliku konfiguracji aplikacji (web.config lub app.config).

Zbieranie danych śledzenia sieci

Analizator komunikatów służy do zbierania danych śledzenia sieci HTTP/HTTPS, gdy aplikacja kliencka jest uruchomiona. Analizator komunikatów używa narzędzia Fiddler na zapleczu. Przed zebraniem śledzenia sieci zalecamy skonfigurowanie programu Fiddler do rejestrowania niezaszyfrowanego ruchu HTTPS:

1. Zainstaluj program Fiddler.
2. Uruchom program Fiddler.
3. Wybieranie narzędzi | Opcje programu Fiddler.
4. W oknie dialogowym Opcje upewnij się, że wybrano opcję Przechwyć połączenia HTTPS CONNECTs i Odszyfruj ruch HTTPS , jak pokazano poniżej.

Na potrzeby tego samouczka najpierw zbierz i zapisz ślad sieciowy w analizatorze komunikatów, a następnie utwórz sesję analizy w celu przeanalizowania śladu i dzienników. Aby zebrać ślad sieciowy w analizatorze komunikatów:

1. W analizatorze komunikatów wybierz pozycję Plik | Szybkie śledzenie | Niezaszyfrowany protokół HTTPS.

2. Ślad rozpocznie się natychmiast. Wybierz pozycję Zatrzymaj , aby zatrzymać śledzenie śledzenia ruchu.

3. Wybierz pozycję Edytuj , aby edytować sesję śledzenia.

4. Wybierz link Konfiguruj po prawej stronie dostawcy MICROSOFT-Pef-WebProxy ETW.

5. W oknie dialogowym Ustawienia zaawansowane kliknij kartę Dostawca .

6. W polu Filtr nazwy hosta określ punkty końcowe magazynu oddzielone spacjami. Możesz na przykład określić punkty końcowe w następujący sposób; zmień storagesample nazwę konta magazynu:

   storagesample.blob.core.windows.net storagesample.queue.core.windows.net storagesample.table.core.windows.net

7. Zamknij okno dialogowe, a następnie kliknij przycisk Uruchom ponownie , aby rozpocząć zbieranie śladu z zastosowanym filtrem nazwy hosta, aby uwzględnić tylko ruch sieciowy usługi Azure Storage w śladzie.

Uwaga

Po zakończeniu zbierania danych śledzenia sieci zdecydowanie zalecamy przywrócenie ustawień, które mogły zostać zmienione w programie Fiddler w celu odszyfrowania ruchu HTTPS. W oknie dialogowym Opcje programu Fiddler usuń zaznaczenie pól wyboru Przechwyć połączenia HTTPS CONNECTs i Odszyfruj ruch HTTPS .

Aby uzyskać więcej informacji, zobacz Korzystanie z funkcji śledzenia sieci w witrynie Technet.

Przeglądanie danych metryk w Azure Portal

Po uruchomieniu aplikacji przez pewien czas możesz przejrzeć wykresy metryk wyświetlane w Azure Portal, aby zobaczyć, jak działa twoja usługa.

Najpierw przejdź do konta magazynu w Azure Portal. Domyślnie w bloku konta jest wyświetlany wykres monitorowania z metryką Procent powodzenia . Jeśli wcześniej zmodyfikowano wykres w celu wyświetlenia różnych metryk, dodaj metrykę Procent powodzenia .

Na wykresie monitorowania zobaczysz procent powodzenia wraz z innymi metrykami, które mogły zostać dodane. W scenariuszu zbadamy następnie, analizując dzienniki w analizatorze komunikatów, procent powodzenia wynosi nieco poniżej 100%.

Aby uzyskać więcej informacji na temat dodawania i dostosowywania wykresów metryk, zobacz Dostosowywanie wykresów metryk.

Uwaga

Wyświetlenie danych metryk w Azure Portal po włączeniu metryk może zająć trochę czasu. Wynika to z tego, że metryki godzinowe dla poprzedniej godziny nie są wyświetlane w Azure Portal do czasu upłynięcia bieżącej godziny. Ponadto metryki minut nie są obecnie wyświetlane w Azure Portal. Dlatego w zależności od tego, kiedy włączysz metryki, wyświetlanie danych metryk może potrwać do dwóch godzin.

Kopiowanie dzienników serwera do katalogu lokalnego za pomocą narzędzia AzCopy

Usługa Azure Storage zapisuje dane dziennika serwera w obiektach blob, podczas gdy metryki są zapisywane w tabelach. Obiekty blob dziennika są dostępne w dobrze znanym $logs kontenerze dla konta magazynu. Obiekty blob dziennika są określane hierarchicznie według roku, miesiąca, dnia i godziny, dzięki czemu można łatwo zlokalizować zakres czasu, który chcesz zbadać. Na przykład na storagesample koncie kontener obiektów blob dziennika dla 01.02.2015, od 8 do 9:00, to https://storagesample.blob.core.windows.net/$logs/blob/2015/01/08/0800. Poszczególne obiekty blob w tym kontenerze są nazywane sekwencyjnie, począwszy od 000000.log.

Możesz użyć narzędzia wiersza polecenia AzCopy, aby pobrać te pliki dziennika po stronie serwera do wybranej lokalizacji na komputerze lokalnym. Na przykład można użyć następującego polecenia, aby pobrać pliki dziennika dla operacji obiektów blob, które miały miejsce 2 stycznia 2015 r. w folderze C:\Temp\Logs\Server; zastąp <storageaccountname> ciąg nazwą konta magazynu:

azcopy copy 'http://<storageaccountname>.blob.core.windows.net/$logs/blob/2015/01/02' 'C:\Temp\Logs\Server'  --recursive

Narzędzie AzCopy jest dostępne do pobrania na stronie plików do pobrania platformy Azure . Aby uzyskać szczegółowe informacje na temat korzystania z narzędzia AzCopy, zobacz Transfer danych za pomocą narzędzia AzCopy Command-Line.

Aby uzyskać dodatkowe informacje na temat pobierania dzienników po stronie serwera, zobacz Pobieranie danych dziennika rejestrowania magazynu.

Analizowanie danych dziennika za pomocą narzędzia Microsoft Message Analyzer

Microsoft Message Analyzer to narzędzie do przechwytywania, wyświetlania i analizowania ruchu komunikatów protokołu, zdarzeń i innych komunikatów systemowych lub aplikacji w scenariuszach rozwiązywania problemów i diagnostyki. Analizator komunikatów umożliwia również ładowanie, agregowanie i analizowanie danych z dzienników i zapisanych plików śledzenia. Aby uzyskać więcej informacji na temat analizatora komunikatów, zobacz Przewodnik operacyjny programu Microsoft Message Analyzer.

Usługa Message Analyzer zawiera zasoby usługi Azure Storage, które ułatwiają analizowanie dzienników serwera, klienta i sieci. W tej sekcji omówimy sposób użycia tych narzędzi w celu rozwiązania problemu niskiego procentu sukcesu w dziennikach magazynu.

Pobieranie i instalowanie analizatora komunikatów oraz zasobów usługi Azure Storage

1. Pobierz analizator komunikatów.
2. Uruchom analizator komunikatów.
3. Z menu Narzędzia wybierz pozycję Asset Manager. W oknie dialogowym Menedżer zasobów wybierz pozycję Pliki do pobrania, a następnie odfiltruj usługę Azure Storage. Zostaną wyświetlone zasoby usługi Azure Storage, jak pokazano na poniższej ilustracji.
4. Kliknij pozycję Synchronizuj wszystkie wyświetlane elementy , aby zainstalować zasoby usługi Azure Storage. Dostępne zasoby obejmują:
   • Reguły kolorów usługi Azure Storage: Reguły kolorów usługi Azure Storage umożliwiają definiowanie specjalnych filtrów korzystających ze stylów kolorów, tekstu i czcionek w celu wyróżnienia komunikatów zawierających określone informacje w śledzeniu.
   • Wykresy usługi Azure Storage: Wykresy usługi Azure Storage to wstępnie zdefiniowane wykresy, które grafowe dane dziennika serwera. Należy pamiętać, że aby w tej chwili używać wykresów usługi Azure Storage, możesz załadować tylko dziennik serwera do usługi Analysis Grid.
   • Analizatory usługi Azure Storage: Analizatory usługi Azure Storage analizują dzienniki klienta, serwera i protokołu HTTP usługi Azure Storage w celu wyświetlenia ich w siatce analiz.
   • Filtry usługi Azure Storage: Filtry usługi Azure Storage są wstępnie zdefiniowanymi kryteriami, których można użyć do wykonywania zapytań dotyczących danych w siatce analiz.
   • Układy widoku usługi Azure Storage: Układy widoku usługi Azure Storage są wstępnie zdefiniowanymi układami kolumn i grupami w siatce analiz.
5. Uruchom ponownie analizator komunikatów po zainstalowaniu zasobów.

Uwaga

Zainstaluj wszystkie zasoby usługi Azure Storage pokazane na potrzeby tego samouczka.

Importowanie plików dziennika do analizatora komunikatów

Możesz zaimportować wszystkie zapisane pliki dziennika (po stronie serwera, po stronie klienta i sieci) do jednej sesji w narzędziu Microsoft Message Analyzer na potrzeby analizy.

1. W menu Plik w narzędziu Microsoft Message Analyzer kliknij pozycję Nowa sesja, a następnie kliknij pozycję Pusta sesja. W oknie dialogowym Nowa sesja wprowadź nazwę sesji analizy. W panelu Szczegóły sesji kliknij przycisk Pliki .
2. Aby załadować dane śledzenia sieci wygenerowane przez analizator komunikatów, kliknij pozycję Dodaj pliki, przejdź do lokalizacji, w której zapisano plik matp z sesji śledzenia sieci Web, wybierz plik matp, a następnie kliknij przycisk Otwórz.
3. Aby załadować dane dziennika po stronie serwera, kliknij pozycję Dodaj pliki, przejdź do lokalizacji, w której pobrano dzienniki po stronie serwera, wybierz pliki dziennika dla zakresu czasu, który chcesz przeanalizować, a następnie kliknij przycisk Otwórz. Następnie w panelu Szczegóły sesji ustaw listę rozwijaną Konfiguracja dziennika tekstu dla każdego pliku dziennika po stronie serwera na wartość AzureStorageLog , aby upewnić się, że program Microsoft Message Analyzer może poprawnie przeanalizować plik dziennika.
4. Aby załadować dane dziennika po stronie klienta, kliknij pozycję Dodaj pliki, przejdź do lokalizacji, w której zapisano dzienniki po stronie klienta, wybierz pliki dziennika, które chcesz przeanalizować, a następnie kliknij przycisk Otwórz. Następnie w panelu Szczegóły sesji ustaw listę rozwijaną Konfiguracja dziennika tekstu dla każdego pliku dziennika po stronie klienta na wartość AzureStorageClientDotNetV4 , aby upewnić się, że program Microsoft Message Analyzer może poprawnie przeanalizować plik dziennika.
5. Kliknij przycisk Start w oknie dialogowym Nowa sesja , aby załadować i przeanalizować dane dziennika. Dane dziennika są wyświetlane w siatce analizy analizatora komunikatów.

Na poniższej ilustracji przedstawiono przykładową sesję skonfigurowaną z plikami dziennika śledzenia serwera, klienta i sieci.

Należy pamiętać, że Analizator komunikatów ładuje pliki dziennika do pamięci. Jeśli masz duży zestaw danych dziennika, należy je filtrować, aby uzyskać najlepszą wydajność z analizatora komunikatów.

Najpierw określ przedział czasu, który cię interesuje, i zachowaj ten przedział czasu tak mały, jak to możliwe. W wielu przypadkach warto przejrzeć najwyżej kilka minut lub godzin. Zaimportuj najmniejszy zestaw dzienników, które mogą spełniać Twoje potrzeby.

Jeśli nadal masz dużą ilość danych dziennika, możesz określić filtr sesji, aby filtrować dane dziennika przed ich załadowaniem. W filtrze sesji wybierz przycisk Biblioteka , aby wybrać wstępnie zdefiniowany filtr; na przykład wybierz pozycję Globalny filtr czasu I z filtrów usługi Azure Storage, aby filtrować według interwału czasu. Następnie można edytować kryteria filtrowania, aby określić znacznik czasu rozpoczęcia i zakończenia dla interwału, który chcesz zobaczyć. Można również filtrować według określonego kodu stanu; Można na przykład załadować tylko wpisy dziennika, w których kod stanu to 404.

Aby uzyskać więcej informacji na temat importowania danych dziennika do programu Microsoft Message Analyzer, zobacz Pobieranie danych komunikatów w witrynie TechNet.

Używanie identyfikatora żądania klienta do korelowania danych pliku dziennika

Biblioteka klienta usługi Azure Storage automatycznie generuje unikatowy identyfikator żądania klienta dla każdego żądania. Ta wartość jest zapisywana w dzienniku klienta, dzienniku serwera i śledzenia sieci, dzięki czemu można jej użyć do korelowania danych we wszystkich trzech dziennikach w analizatorze komunikatów. Aby uzyskać dodatkowe informacje o identyfikatorze żądania klienta, zobacz Identyfikator żądania klienta.

W poniższych sekcjach opisano sposób używania wstępnie skonfigurowanych i niestandardowych widoków układu do korelowania i grupowania danych na podstawie identyfikatora żądania klienta.

Wybieranie układu widoku do wyświetlenia w siatce analiz

Zasoby magazynu dla analizatora komunikatów obejmują układy widoku usługi Azure Storage, które są wstępnie skonfigurowanymi widokami, których można użyć do wyświetlania danych z przydatnymi grupami i kolumnami dla różnych scenariuszy. Można również tworzyć niestandardowe układy widoków i zapisywać je do ponownego użycia.

Na poniższej ilustracji przedstawiono menu Układ widoku , dostępne po wybraniu pozycji Układ widoku na wstążce paska narzędzi. Układy widoku dla usługi Azure Storage są pogrupowane w węźle Usługi Azure Storage w menu. Możesz wyszukać Azure Storage w polu wyszukiwania, aby filtrować tylko układy widoku usługi Azure Storage. Możesz również wybrać star obok układu widoku, aby ustawić go jako ulubiony i wyświetlić go w górnej części menu.

Na początek wybierz pozycję Pogrupowane według identyfikatora ClientRequestID i modułu. Ten widok układ grupuje dane dziennika ze wszystkich trzech dzienników najpierw według identyfikatora żądania klienta, a następnie według źródłowego pliku dziennika (lub modułu w analizatorze komunikatów). W tym widoku można przejść do szczegółów określonego identyfikatora żądania klienta i wyświetlić dane ze wszystkich trzech plików dziennika dla tego identyfikatora żądania klienta.

Na poniższym obrazie przedstawiono ten widok układu zastosowany do przykładowych danych dziennika z wyświetlonym podzbiorem kolumn. Widać, że dla określonego identyfikatora żądania klienta usługa Analysis Grid wyświetla dane z dziennika klienta, dziennika serwera i śledzenia sieci.

Uwaga

Różne pliki dziennika mają różne kolumny, więc gdy dane z wielu plików dziennika są wyświetlane w siatce analiz, niektóre kolumny mogą nie zawierać żadnych danych dla danego wiersza. Na przykład na powyższej ilustracji wiersze dziennika klienta nie pokazują żadnych danych dla kolumn Timestamp, TimeElapsed, Source i Destination , ponieważ te kolumny nie istnieją w dzienniku klienta, ale istnieją w śladzie sieci. Podobnie kolumna Sygnatura czasowa wyświetla dane sygnatury czasowej z dziennika serwera, ale żadne dane nie są wyświetlane dla kolumn TimeElapsed, Source i Destination , które nie są częścią dziennika serwera.

Oprócz korzystania z układów widoku usługi Azure Storage można również definiować i zapisywać własne układy widoku. Możesz również wybrać inne żądane pola do grupowania danych i zapisać grupowanie w ramach układu niestandardowego.

Stosowanie reguł kolorów do siatki analizy

Zasoby magazynu zawierają również reguły kolorów, które oferują wizualizację, aby zidentyfikować różne typy błędów w siatce analiz. Wstępnie zdefiniowane reguły kolorów dotyczą błędów HTTP, dlatego są one wyświetlane tylko dla dziennika serwera i śledzenia sieci.

Aby zastosować reguły kolorów, wybierz pozycję Reguły kolorów na wstążce paska narzędzi. Reguły kolorów usługi Azure Storage zostaną wyświetlone w menu. Na potrzeby samouczka wybierz pozycję Błędy klienta (StatusCode od 400 do 499), jak pokazano na poniższej ilustracji.

Oprócz używania reguł kolorów usługi Azure Storage można również definiować i zapisywać własne reguły kolorów.

Grupowanie i filtrowanie danych dziennika w celu znalezienia błędów zakresu 400

Następnie pogrupujemy i przefiltrujemy dane dziennika, aby znaleźć wszystkie błędy w zakresie 400.

1. Znajdź kolumnę StatusCode w siatce analizy, kliknij prawym przyciskiem myszy nagłówek kolumny i wybierz pozycję Grupa.

2. Następnie pogrupuj grupę w kolumnie ClientRequestId . Zobaczysz, że dane w siatce analiz są teraz zorganizowane według kodu stanu i identyfikatora żądania klienta.

3. Wyświetl okno narzędzia Filtr widoku, jeśli nie jest jeszcze wyświetlane. Na wstążce paska narzędzi wybierz pozycję Okna narzędzi, a następnie pozycję Wyświetl filtr.

4. Aby przefiltrować dane dziennika w celu wyświetlenia tylko błędów zakresu 400, dodaj następujące kryteria filtru do okna Wyświetl filtr i kliknij przycisk Zastosuj:

   (AzureStorageLog.StatusCode >= 400 && AzureStorageLog.StatusCode <=499) || (HTTP.StatusCode >= 400 && HTTP.StatusCode <= 499)

Na poniższym obrazie przedstawiono wyniki tego grupowania i filtrowania. Rozwinięcie pola ClientRequestID pod grupowaniem dla kodu stanu 409 spowoduje na przykład wyświetlenie operacji, która spowodowała ten kod stanu.

Po zastosowaniu tego filtru zobaczysz, że wiersze z dziennika klienta są wykluczone, ponieważ dziennik klienta nie zawiera kolumny StatusCode . Na początek przejrzymy dzienniki śledzenia serwera i sieci, aby zlokalizować błędy 404, a następnie wrócimy do dziennika klienta, aby zbadać operacje klienta, które doprowadziły do nich.

Uwaga

Możesz filtrować według kolumny StatusCode i nadal wyświetlać dane ze wszystkich trzech dzienników, w tym dziennika klienta, jeśli dodasz wyrażenie do filtru zawierającego wpisy dziennika, w których kod stanu ma wartość null. Aby utworzyć to wyrażenie filtru, użyj:

*StatusCode >= 400 or !*StatusCode

Ten filtr zwraca wszystkie wiersze z dziennika klienta i tylko wiersze z dziennika serwera i dziennika HTTP, gdzie kod stanu jest większy niż 400. Jeśli zastosujesz go do układu widoku pogrupowanego według identyfikatora żądania klienta i modułu, możesz wyszukać lub przewinąć wpisy dziennika, aby znaleźć te, w których są reprezentowane wszystkie trzy dzienniki.

Filtrowanie danych dziennika w celu znalezienia błędów 404

Zasoby magazynu zawierają wstępnie zdefiniowane filtry, których można użyć do zawężenia danych dziennika w celu znalezienia błędów lub trendów, których szukasz. Następnie zastosujemy dwa wstępnie zdefiniowane filtry: jeden, który filtruje dzienniki śledzenia serwera i sieci pod kątem błędów 404 i jeden, który filtruje dane w określonym zakresie czasu.

1. Wyświetl okno narzędzia Filtr widoku, jeśli nie jest jeszcze wyświetlane. Na wstążce paska narzędzi wybierz pozycję Okna narzędzi, a następnie pozycję Wyświetl filtr.

2. W oknie Widok filtru wybierz pozycję Biblioteka i wyszukaj Azure Storage , aby znaleźć filtry usługi Azure Storage. Wybierz filtr komunikatów 404 (nie znaleziono) we wszystkich dziennikach.

3. Ponownie wyświetl menu Biblioteka i znajdź i wybierz globalny filtr czasu.

4. Edytuj znaczniki czasu wyświetlane w filtrze do zakresu, który chcesz wyświetlić. Pomoże to zawęzić zakres danych do analizy.

5. Filtr powinien wyglądać podobnie do poniższego przykładu. Kliknij przycisk Zastosuj , aby zastosować filtr do siatki analizy.

   ((AzureStorageLog.StatusCode == 404 || HTTP.StatusCode == 404)) And (#Timestamp >= 2014-10-20T16:36:38 and #Timestamp <= 2014-10-20T16:36:39)

   

Analizowanie danych dziennika

Po zgrupowaniu i przefiltrowania danych możesz sprawdzić szczegóły poszczególnych żądań, które wygenerowały błędy 404. W bieżącym układzie widoku dane są pogrupowane według identyfikatora żądania klienta, a następnie według źródła dziennika. Ponieważ filtrujemy żądania, w których pole StatusCode zawiera wartość 404, zobaczymy tylko dane śledzenia serwera i sieci, a nie dane dziennika klienta.

Na poniższej ilustracji przedstawiono konkretne żądanie, w którym operacja Get Blob zwróciła błąd 404, ponieważ obiekt blob nie istnieje. Należy pamiętać, że niektóre kolumny zostały usunięte z widoku standardowego w celu wyświetlenia odpowiednich danych.

Następnie skorelujemy ten identyfikator żądania klienta z danymi dziennika klienta, aby zobaczyć, jakie akcje wykonywane przez klienta podczas wystąpienia błędu. Możesz wyświetlić nowy widok siatki analizy dla tej sesji, aby wyświetlić dane dziennika klienta, które zostanie otwarte na drugiej karcie:

1. Najpierw skopiuj wartość pola ClientRequestId do schowka. Możesz to zrobić, wybierając dowolny wiersz, lokalizując pole ClientRequestId, klikając prawym przyciskiem myszy wartość danych i wybierając polecenie Kopiuj wartość "ClientRequestId".

2. Na wstążce paska narzędzi wybierz pozycję Nowa przeglądarka, a następnie wybierz pozycję Siatka analizy , aby otworzyć nową kartę. Nowa karta zawiera wszystkie dane w plikach dziennika bez grupowania, filtrowania ani reguł kolorów.

3. Na wstążce paska narzędzi wybierz pozycję Układ widoku, a następnie wybierz pozycję Wszystkie kolumny klienta platformy .NET w sekcji Azure Storage . Ten układ widoku zawiera dane z dziennika klienta, a także dzienniki śledzenia serwera i sieci. Domyślnie jest ona sortowana w kolumnie MessageNumber .

4. Następnie przeszukaj dziennik klienta pod kątem identyfikatora żądania klienta. Na wstążce paska narzędzi wybierz pozycję Znajdź komunikaty, a następnie określ niestandardowy filtr identyfikatora żądania klienta w polu Znajdź . Użyj tej składni dla filtru, określając własny identyfikator żądania klienta:

   *ClientRequestId == "398bac41-7725-484b-8a69-2a9e48fc669a"

Analizator komunikatów lokalizuje i wybiera pierwszy wpis dziennika, w którym kryteria wyszukiwania są zgodne z identyfikatorem żądania klienta. W dzienniku klienta istnieje kilka wpisów dla każdego identyfikatora żądania klienta, więc możesz pogrupować je w polu ClientRequestId , aby ułatwić ich wyświetlanie razem. Na poniższej ilustracji przedstawiono wszystkie komunikaty w dzienniku klienta dla określonego identyfikatora żądania klienta.

Korzystając z danych wyświetlanych w układach widoków na tych dwóch kartach, możesz przeanalizować dane żądania, aby określić, co mogło spowodować błąd. Możesz również przyjrzeć się żądaniom poprzedzającym to zdarzenie, aby sprawdzić, czy poprzednie zdarzenie mogło spowodować błąd 404. Możesz na przykład przejrzeć wpisy dziennika klienta poprzedzające ten identyfikator żądania klienta, aby określić, czy obiekt blob mógł zostać usunięty, czy też wystąpił błąd spowodowany przez aplikację kliencką wywołującą interfejs API CreateIfNotExists w kontenerze lub obiekcie blob. W dzienniku klienta adres obiektu blob można znaleźć w polu Opis ; w dziennikach śledzenia serwera i sieci te informacje są wyświetlane w polu Podsumowanie .

Gdy znasz adres obiektu blob, który przyniósł błąd 404, możesz dokładniej zbadać ten problem. Jeśli przeszukujesz wpisy dziennika dla innych komunikatów skojarzonych z operacjami na tym samym obiekcie blob, możesz sprawdzić, czy klient wcześniej usunął jednostkę.

Analizowanie innych typów błędów magazynu

Teraz, gdy znasz narzędzie Message Analyzer do analizowania danych dziennika, możesz analizować inne typy błędów przy użyciu układów widoków, reguł kolorów i wyszukiwania/filtrowania. W poniższych tabelach wymieniono niektóre problemy, które mogą wystąpić, oraz kryteria filtrowania, których można użyć do ich zlokalizowania. Aby uzyskać więcej informacji na temat konstruowania filtrów i języka filtrowania analizatora komunikatów, zobacz Filtrowanie danych komunikatów.

Aby zbadać...	Użyj wyrażenia filtru...	Wyrażenie dotyczy dziennika (klient, serwer, sieć, wszystko)
Nieoczekiwane opóźnienia w dostarczaniu komunikatów w kolejce	AzureStorageClientDotNetV4.Description zawiera komunikat "Ponów próbę nieudanej operacji".	Klient
Wzrost HTTP w percentThrottlingError	HTTP. Response.StatusCode == 500 || HTTP. Response.StatusCode == 503	Sieć
Wzrost wartości PercentTimeoutError	HTTP. Response.StatusCode == 500	Sieć
Wzrost wartości PercentTimeoutError (wszystkie)	*StatusCode == 500	Wszystko
Wzrost liczby percentNetworkError	AzureStorageClientDotNetV4.EventLogEntry.Level < 2	Klient
Komunikaty HTTP 403 (Zabronione)	HTTP. Response.StatusCode == 403	Sieć
Komunikaty HTTP 404 (Nie znaleziono)	HTTP. Response.StatusCode == 404	Sieć
404 (wszystkie)	*StatusCode == 404	Wszystko
Problem z autoryzacją sygnatury dostępu współdzielonego	AzureStorageLog.RequestStatus == "SASAuthorizationError"	Sieć
Komunikaty HTTP 409 (Konflikt)	HTTP. Response.StatusCode == 409	Sieć
409 (wszystkie)	*StatusCode == 409	Wszystko
Wpisy dziennika low PercentSuccess lub analizy mają operacje ze stanem transakcji ClientOtherErrors	AzureStorageLog.RequestStatus == "ClientOtherError"	Serwer
Ostrzeżenie nagle	((AzureStorageLog.EndToEndLatencyMS — AzureStorageLog.ServerLatencyMS) > (AzureStorageLog.ServerLatencyMS * 1.5)) and (AzureStorageLog.RequestPacketSize <1460) i (AzureStorageLog.EndToEndLatencyMS — AzureStorageLog.ServerLatencyMS >= 200)	Serwer
Zakres czasu w dziennikach serwera i sieci	>#Timestamp = 2014-10-20T16:36:38 i #Timestamp <= 2014-10-20T16:36:39	Serwer, sieć
Zakres czasu w dziennikach serwera	AzureStorageLog.Timestamp = 2014-10-20T16:36:38 i AzureStorageLog.Timestamp ><= 2014-10-20T16:36:39	Serwer

Następne kroki

Aby uzyskać więcej informacji na temat rozwiązywania problemów ze scenariuszami kompleksowego rozwiązywania problemów w usłudze Azure Storage, zobacz następujące zasoby:

• Monitorowanie, diagnozowanie i rozwiązywanie problemów z usługą Microsoft Azure Storage
• Analityka magazynu
• Monitorowanie konta magazynu w witrynie Azure Portal
• Transfer danych za pomocą narzędzia wiersza polecenia AzCopy
• Instrukcja obsługi narzędzia Microsoft Message Analyzer