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

• Portal Azure

Diagnozowanie i rozwiązywanie problemów to kluczowa umiejętność tworzenia i obsługi aplikacji klienckich w usłudze 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 demonstrujemy, jak identyfikować pewne błędy, które mogą wpływać na wydajność, oraz rozwiązywać problemy z tymi błędami w pełni, korzystając z narzędzi oferowanych przez Microsoft i Azure Storage, aby zoptymalizować aplikację kliencką.

Ten samouczek zawiera praktyczne eksplorowanie 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 z usługą 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 usługi 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żą:

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

  • Metryki magazynu monitorują metryki transakcji i pojemności dla Twojego konta magazynowego. Korzystając z metryk, możesz określić, jak aplikacja działa zgodnie z różnymi miarami. Zobacz Schemat tabeli metryk Storage Analytics, aby uzyskać więcej informacji na temat typów metryk śledzonych przez Storage Analytics.
  • Rejestrowanie w magazynie 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 Format dziennika usługi Storage Analytics , aby uzyskać więcej informacji na temat danych żądania i odpowiedzi zapisywanych w dziennikach przez usługę Storage Analytics.

• Portal Azure. Metryki i rejestrowanie dla konta magazynu można skonfigurować w portalu Azure. Możesz również wyświetlić wykresy i diagramy, które pokazują, jak Twoja aplikacja działa w czasie, i skonfigurować alerty, aby powiadamiać, jeśli 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 portalu Azure.

• AzCopy. Dzienniki serwera dla usługi Azure Storage są przechowywane jako obiekty blob, dzięki czemu można 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 (Transferowanie 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, który 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 o niskim współczynniku powodzenia (wyświetlana jako PercentSuccess w witrynie 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 szczegółowych 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 za niski procentowy współczynnik sukcesu uznamy wartość mniejszą niż 100%. Możesz jednak wybrać inny poziom metryki zgodnie z potrzebami. Zalecamy, aby podczas testowania aplikacji ustanowić tolerancję punktu odniesienia dla kluczowych metryk wydajności. Można na przykład określić, na podstawie testowania, że aplikacja powinna mieć spójny procentowy współczynnik 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 współczynnika powodzenia procentowego jest niższa niż 100%, przeanalizujemy dzienniki, aby znaleźć błędy skorelowane z metrykami i użyjemy ich, aby ustalić, co powoduje niższy współczynnik powodzenia procentu. Przyjrzymy się konkretnie błędom w zakresie 400. Następnie dokładniej zbadamy błędy 404 (nie znaleziono).

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

W poniższych przykładach przedstawiono próbkowanie około 400 błędów zakresu żądań względem usługi Azure Blob Storage oraz ich możliwe przyczyny. Każdy z tych błędów, a także błędy z zakresu 300 i zakresu 500, może przyczynić się do niskiego współczynnika powodzenia procentowego.

Zwróć uwagę, że poniższe listy nie są pełne. Zobacz Kody stanu i błędów w witrynie MSDN, 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.

Przykłady kodu stanu 404 (nie znaleziono)

Występuje, gdy operacja odczytu względem kontenera lub obiektu blob kończy się niepowodzeniem, ponieważ nie można odnaleźć obiektu blob lub kontenera.

• Występuje, jeśli kontener lub obiekt blob został usunięty przez innego klienta przed tym żądaniem.
• Występuje, gdy korzystasz z wywołania interfejsu API tworzącego 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, a kontener lub obiekt blob o tej nazwie już istnieje.
• Występuje, jeśli kontener jest usuwany i próbujesz utworzyć nowy kontener o tej samej nazwie przed zakończeniem operacji usuwania.
• Występuje, jeśli przydzielisz dzierżawę na kontener lub obiekt danych, a dzierżawa jest już obecna.

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 nie jest zgodny 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ć pracę z jednym z następujących elementów:

• 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, w tym operacji w usłudze Azure Storage. W tym samouczku wygenerujemy ślad sieciowy za pomocą analizatora komunikatów.

Konfigurowanie rejestrowania i metryk po stronie serwera

Najpierw musimy skonfigurować rejestrowanie i metryki usługi Azure Storage, aby dane z boku usługi zostały przeanalizowane. Rejestrowanie i metryki można skonfigurować na różne sposoby — za pośrednictwem witryny Azure Portal, przy użyciu programu PowerShell lub programowo. Zobacz Włączanie metryk i Włączanie rejestrowania, aby uzyskać szczegółowe informacje na temat konfigurowania rejestrowania i metryk.

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 .NET Storage i rejestrowania po stronie klienta przy użyciu zestawu SDK usługi 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 pamięci masowej przechowuje dane logów po stronie klienta w lokalizacji określonej w pliku konfiguracyjnym aplikacji (web.config lub app.config).

Zbierz ślad sieci

Analizator komunikatów umożliwia zbieranie śledzenia sieci HTTP/HTTPS podczas działania aplikacji klienckiej. Narzędzie Message Analyzer używa Fiddler w tle. 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 samouczka najpierw zbierz i zapisz ślad sieciowy w analizatorze komunikatów, a następnie utwórz sesję analizy, aby przeanalizować ślad i dzienniki. Aby zebrać ślad sieci w Analizatorze Wiadomości:

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

2. Śledzenie rozpocznie się natychmiast. Wybierz Zatrzymaj, aby zatrzymać ślad i skonfigurować go do śledzenia tylko ruchu w magazynie.

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

4. Wybierz link Konfiguruj z prawej strony 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 usługi magazynowania oddzielone spacjami. Możesz na przykład określić punkty końcowe w następujący sposób, zmieniając nazwę storagesample na nazwę swojego konta przechowywania.

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

7. Zamknij okno dialogowe i kliknij przycisk Uruchom ponownie, aby rozpocząć zbieranie śladu z zastosowaniem filtru nazwy hosta, dzięki czemu w śladzie uwzględniony zostanie tylko ruch sieciowy usługi Azure Storage.

Uwaga / Notatka

Po zakończeniu zbierania ś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 witrynie Azure Portal

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

Najpierw przejdź do konta przechowywania w Azure Portal. Domyślnie na okienku konta wyświetlany jest 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 dodanymi metrykami. W scenariuszu, który przeanalizujemy dalej, analizując dzienniki za pomocą Message Analyzer, wskaźnik powodzenia procentowego wynosi nieco poniżej 100%.

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

Uwaga / Notatka

Po włączeniu metryk przechowywania może upłynąć trochę czasu, zanim dane metryk pojawią się w portalu Azure. Dzieje się tak, ponieważ metryki godzinowe dla poprzedniej godziny nie są wyświetlane w witrynie Azure Portal do czasu upływu bieżącej godziny. Ponadto metryki minutowe nie są obecnie wyświetlane w Azure portal. 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 Twojego konta magazynowego. 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 koncie storagesample kontener dla obiektów blob dziennika z dnia 01.02.2015, od 8 do 9 rano, to https://storagesample.blob.core.windows.net/$logs/blob/2015/01/08/0800. Poszczególnym blobom w tym kontenerze są nadawane nazwy 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żesz użyć następującego polecenia, aby pobrać pliki dziennika dla operacji blob, które odbywały się 2 stycznia 2015 roku do folderu C:\Temp\Logs\Server; zastąp <storageaccountname> nazwą swojego 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 Pliki do pobrania platformy Azure . Aby uzyskać szczegółowe informacje na temat korzystania z narzędzia AzCopy, zobacz Transferowanie danych za pomocą narzędzia Command-Line AzCopy.

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.

Analizator komunikatów zawiera zasoby dla 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 systemowych.

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ę Menedżer zasobów. W oknie dialogowym Menedżer zasobów wybierz pozycję Pobrane pliki, a następnie filtruj wedł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, które używają kolorów, tekstu i stylów czcionek w celu wyróżniania 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 przedstawiają dane z dzienników 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 usłudze Analysis Grid.
   • 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 / Notatka

Zainstaluj wszystkie zasoby usługi Azure Storage wyświetlane 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 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 analitycznej 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ć okres kilku minut lub godzin. Zaimportuj najmniejszy zestaw logów spełniający 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 polu Filtr 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 analizy

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, wybierając pozycję Układ widoku na wstążce paska narzędzi. Układy widoku dla usługi Azure Storage są grupowane w węźle 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ć gwiazdkę obok układu widoku, aby ustawić go jako ulubiony i wyświetlić go w górnej części menu.

Aby rozpocząć, wybierz opcję Pogrupowane według identyfikatora ClientRequestID oraz modułu. Ten widok rozmieszczenia grupuje dane dziennika ze wszystkich trzech dzienników najpierw według ID żą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 widoczny jest widok układu zastosowany do przykładowych danych dziennika, z wyświetlanym 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 / Notatka

Różne pliki dziennika mają różne kolumny, więc gdy dane z wielu plików dziennika są wyświetlane w siatce analizy, 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 Sygnatura czasowa, 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 magazynowe zawierają również reguły kolorów, które zapewniają wizualne środki identyfikacji różnych typów błędów w siatce analiz. Wstępnie zdefiniowane reguły kolorów dotyczą błędów HTTP, dlatego są 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. W menu zostaną wyświetlone reguły kolorów usługi Azure Storage. Na potrzeby samouczka wybierz pozycję Błędy klienta (StatusCode z zakresu 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 logów w celu znalezienia błędów z 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 grupuj 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 już wyświetlone. 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ższej ilustracji przedstawiono wyniki tego grupowania i filtrowania. Rozszerzenie pola ClientRequestID pod grupowaniem dla kodu stanu 409, na przykład pokazuje operację, 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 / Notatka

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, w których 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 pamięci zawierają z góry określone filtry, których można użyć do zawężenia danych dziennika, aby znaleźć błędy lub odnaleźć trendy, jakich 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. Pokaż 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 dla 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

Teraz, gdy dane zostały pogrupowane i przefiltrowane, możesz sprawdzić szczegóły poszczególnych żądań, które wygenerowały błędy 404. W bieżącym układzie widoku dane są grupowane 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 zakończyła się błędem 404, ponieważ blob nie istniał. 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 klient podejmował, kiedy wystąpił błąd. 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, a następnie wybierając polecenie Kopiuj '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 on sortowany 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 widoku 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 przeszukasz wpisy dziennika dla pozostałych komunikatów skojarzonych z operacjami na tym samym blobie, możesz sprawdzić, czy klient wcześniej usunął jednostkę.

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

Teraz, gdy znasz już 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 filtra...	Wyrażenie dotyczy logu (Klient, Serwer, Sieć, Wszystko)
Nieoczekiwane opóźnienia dostarczania komunikatów w kolejce	AzureStorageClientDotNetV4.Description zawiera "Ponawianie nieudanej operacji".	Klient
Zwiększenie liczby błędów ograniczania procentowego HTTP	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 w 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 (SAS)	AzureStorageLog.RequestStatus == "SASAuthorizationError"	Sieć
Komunikaty HTTP 409 (konflikt)	HTTP. Response.StatusCode == 409	Sieć
409 (wszystkie)	*StatusCode == 409	Wszystko
Wpisy w dzienniku o niskim procencie sukcesu lub analityczne mają operacje ze stanem transakcji "ClientOtherErrors"	AzureStorageLog.RequestStatus == "ClientOtherError"	Server
Nagłe ostrzeżenie	((AzureStorageLog.EndToEndLatencyMS - AzureStorageLog.ServerLatencyMS) > (AzureStorageLog.ServerLatencyMS * 1.5)) i (AzureStorageLog.RequestPacketSize <1460) i (AzureStorageLog.EndToEndLatencyMS - AzureStorageLog.ServerLatencyMS >= 200)	Server
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	Server

Dalsze kroki

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

• Monitor, diagnose, and troubleshoot Microsoft Azure Storage (Monitorowanie, diagnozowanie i rozwiązywanie problemów z usługą Microsoft Azure Storage)
• Analityka magazynu
• Monitoruj konto magazynowe w portalu Azure
• Transfer danych za pomocą narzędzia wiersza polecenia AzCopy
• Przewodnik operacyjny programu Microsoft Message Analyzer