Monitorowanie, diagnozowanie i rozwiązywanie problemów Microsoft Azure Storage (wersja klasyczna)

  • Artykuł

W tym przewodniku pokazano, jak używać funkcji, takich jak usługa Azure analityka magazynu, rejestrowanie po stronie klienta w bibliotece klienta usługi Azure Storage i narzędzia innych firm do identyfikowania, diagnozowania i rozwiązywania problemów związanych z usługą Azure Storage.

Diagram przedstawiający przepływ informacji między aplikacjami klienckimi a usługami azure storage.

Ten przewodnik ma być odczytywany głównie przez deweloperów Usługi online korzystających z usług Azure Storage i specjalistów IT odpowiedzialnych za zarządzanie takimi Usługi online. Cele tego przewodnika to:

  • Aby ułatwić utrzymanie kondycji i wydajności kont usługi Azure Storage.
  • Aby zapewnić niezbędne procesy i narzędzia, które pomogą Ci zdecydować, czy problem lub problem w aplikacji dotyczy usługi Azure Storage.
  • Aby udostępnić praktyczne wskazówki dotyczące rozwiązywania problemów związanych z usługą Azure Storage.

Uwaga

Ten artykuł jest oparty na użyciu analityka magazynu metryk i dzienników nazywanych klasycznymi metrykami i dziennikami. Zalecamy używanie metryk i dzienników usługi Azure Storage w usłudze Azure Monitor zamiast dzienników analityka magazynu. Aby dowiedzieć się więcej, zobacz dowolny z następujących artykułów:

Omówienie

Diagnozowanie i rozwiązywanie problemów w aplikacji rozproszonej hostowanej w środowisku chmury może być bardziej skomplikowane niż w tradycyjnych środowiskach. Aplikacje można wdrażać w infrastrukturze PaaS lub IaaS, lokalnie, na urządzeniu przenośnym lub w niektórych kombinacjach tych środowisk. Zazwyczaj ruch sieciowy aplikacji może przechodzić przez sieci publiczne i prywatne, a aplikacja może korzystać z wielu technologii magazynowania, takich jak tabele Microsoft Azure Storage, obiekty blob, kolejki lub pliki oprócz innych magazynów danych, takich jak relacyjne i dokumentowe bazy danych.

Aby pomyślnie zarządzać takimi aplikacjami, należy monitorować je proaktywnie i rozumieć, jak diagnozować i rozwiązywać problemy ze wszystkimi aspektami i ich technologiami zależnymi. Jako użytkownik usług Azure Storage należy stale monitorować usługi Storage używane przez aplikację pod kątem wszelkich nieoczekiwanych zmian w zachowaniu (takich jak wolniejsze niż zwykle czasy odpowiedzi) i używać rejestrowania do zbierania bardziej szczegółowych danych i szczegółowego analizowania problemu. Informacje diagnostyczne uzyskiwane z monitorowania i rejestrowania pomogą Ci określić główną przyczynę problemu napotkanego przez aplikację. Następnie możesz rozwiązać ten problem i określić odpowiednie kroki, aby go rozwiązać. Usługa Azure Storage jest podstawową usługą platformy Azure i stanowi ważną część większości rozwiązań wdrażanych przez klientów w infrastrukturze platformy Azure. Usługa Azure Storage oferuje możliwości upraszczania monitorowania, diagnozowania i rozwiązywania problemów z magazynem w aplikacjach opartych na chmurze.

Sposób organizowania tego przewodnika

W sekcji Monitorowanie usługi magazynu opisano sposób monitorowania kondycji i wydajności usług Azure Storage przy użyciu metryk usługi Azure analityka magazynu (Metryki magazynu).

W sekcji Diagnozowanie problemów z magazynem opisano sposób diagnozowania problemów przy użyciu rejestrowania usługi Azure analityka magazynu (rejestrowanie magazynu). Opisano w nim również sposób włączania rejestrowania po stronie klienta przy użyciu obiektów w jednej z bibliotek klienckich, takich jak Biblioteka klienta magazynu dla platformy .NET lub zestaw Azure SDK dla języka Java.

W kompleksowej sekcji śledzenia opisano sposób korelowania informacji zawartych w różnych plikach dziennika i danych metryk.

Sekcja Wskazówki dotyczące rozwiązywania problemów zawiera wskazówki dotyczące rozwiązywania niektórych typowych problemów związanych z magazynem, które mogą wystąpić.

Sekcja Dołączania zawiera informacje o używaniu innych narzędzi, takich jak Wireshark i Netmon do analizowania danych pakietów sieciowych, oraz fiddler do analizowania komunikatów HTTP/HTTPS.

Monitorowanie usługi magazynu

Jeśli znasz monitorowanie wydajności systemu Windows, możesz traktować metryki magazynu jako odpowiednik usługi Azure Storage dla liczników monitor wydajności systemu Windows. W obszarze Metryki magazynu znajdziesz kompleksowy zestaw metryk (liczników w terminologii systemu Windows monitor wydajności), takich jak dostępność usługi, łączna liczba żądań do obsługi lub procent pomyślnych żądań do obsługi. Aby uzyskać pełną listę dostępnych metryk, zobacz analityka magazynu Schemat tabeli metryk. Możesz określić, czy usługa magazynu ma zbierać i agregować metryki co godzinę, czy co minutę. Aby uzyskać więcej informacji na temat włączania metryk i monitorowania kont magazynu, zobacz Włączanie metryk magazynu i wyświetlanie danych metryk.

Możesz wybrać metryki godzinowe, które mają być wyświetlane w Azure Portal i skonfigurować reguły powiadamiania administratorów pocztą e-mail za każdym razem, gdy metryka godzinowa przekroczy określony próg. Aby uzyskać więcej informacji, zobacz Otrzymywanie powiadomień o alertach.

Zalecamy zapoznanie się z usługą Azure Monitor for Storage (wersja zapoznawcza). Jest to funkcja usługi Azure Monitor, która oferuje kompleksowe monitorowanie kont usługi Azure Storage przez zapewnienie ujednoliconego widoku wydajności, pojemności i dostępności usług Azure Storage. Nie wymaga włączania ani konfigurowania żadnych elementów i możesz natychmiast wyświetlać te metryki ze wstępnie zdefiniowanych interaktywnych wykresów i innych uwzględnionych wizualizacji.

Usługa magazynu stara się jak najlepiej zbierać metryki, ale nie może rejestrować każdej operacji magazynu.

W Azure Portal można wyświetlić metryki, takie jak dostępność, łączna liczba żądań i średnie liczby opóźnień dla konta magazynu. Skonfigurowano również regułę powiadomień w celu powiadamiania administratora, jeśli dostępność spadnie poniżej określonego poziomu. W przypadku wyświetlania tych danych jednym z możliwych obszarów badania jest wartość procentowa powodzenia usługi tabeli poniżej 100% (aby uzyskać więcej informacji, zobacz sekcję Metryki pokazujące niskie wartości procentowe lub wpisy dziennika analizy mają operacje ze stanem transakcji w sekcji ClientOtherErrors ).

Należy stale monitorować aplikacje platformy Azure, aby upewnić się, że są w dobrej kondycji i działają zgodnie z oczekiwaniami:

  • Ustanowienie niektórych metryk punktu odniesienia dla aplikacji, które umożliwią porównanie bieżących danych i zidentyfikowanie wszelkich istotnych zmian w zachowaniu usługi Azure Storage i aplikacji. Wartości metryk punktu odniesienia będą w wielu przypadkach specyficzne dla aplikacji i należy je ustanowić podczas testowania wydajności aplikacji.
  • Rejestrowanie metryk minut i używanie ich do aktywnego monitorowania pod kątem nieoczekiwanych błędów i anomalii, takich jak skoki liczby błędów lub liczby żądań.
  • Rejestrowanie metryk godzinowych i używanie ich do monitorowania średnich wartości, takich jak średnia liczba błędów i współczynniki żądań.
  • Badanie potencjalnych problemów przy użyciu narzędzi diagnostycznych omówionych w dalszej części sekcji Diagnozowanie problemów z magazynem .

Wykresy na poniższej ilustracji ilustrują, w jaki sposób uśrednianie metryk godzinowych może ukryć skoki aktywności. Metryki godzinowe wydają się pokazywać stały współczynnik żądań, podczas gdy metryki minut ujawniają wahania, które naprawdę mają miejsce.

Wykresy pokazujące, jak uśrednianie metryk godzinowych może ukrywać skoki aktywności.

W pozostałej części tej sekcji opisano metryki, które należy monitorować i dlaczego.

Monitorowanie kondycji usługi

Za pomocą Azure Portal można wyświetlić kondycję usługi Storage (i innych usług platformy Azure) we wszystkich regionach świadczenia usługi Azure na całym świecie. Monitorowanie umożliwia natychmiastowe sprawdzenie, czy problem poza kontrolą ma wpływ na usługę Storage w regionie używanym dla aplikacji.

Azure Portal może również udostępniać powiadomienia o zdarzeniach wpływających na różne usługi platformy Azure.

Uwaga

Te informacje były wcześniej dostępne wraz z danymi historycznymi na pulpicie nawigacyjnym usługi platformy Azure. Aby uzyskać więcej informacji na temat usługi Application Insights dla usługi Azure DevOps, zobacz Dodatek 5: Monitorowanie za pomocą usługi Application Insights dla usługi Azure DevOps.

Pojemność monitorowania

Metryki magazynu przechowują tylko metryki pojemności dla usługi obiektów blob, ponieważ obiekty blob zwykle stanowią największą część przechowywanych danych (w momencie pisania tego tekstu nie można używać metryk magazynu do monitorowania pojemności tabel i kolejek). Te dane można znaleźć w $MetricsCapacityBlob tabeli, jeśli włączono monitorowanie usługi Blob Service. Metryki magazynu rejestrują te dane raz dziennie i można użyć wartości parametru RowKey , aby określić, czy wiersz zawiera jednostkę powiązaną z danymi użytkownika (wartość data) lub dane analityczne (wartość analytics). Każda przechowywana jednostka zawiera informacje o ilości używanego magazynu (Capacity mierzonej w bajtach) oraz bieżącej liczbie kontenerów (ContainerCount) i obiektów blob (ObjectCount) używanych na koncie magazynu. Aby uzyskać więcej informacji na temat metryk pojemności przechowywanych w $MetricsCapacityBlob tabeli, zobacz analityka magazynu Schemat tabeli metryk.

Uwaga

Należy monitorować te wartości pod kątem wczesnego ostrzeżenia, że zbliżasz się do limitów pojemności konta magazynu. W Azure Portal można dodać reguły alertów w celu powiadomienia o przekroczeniu lub spadku łącznego użycia magazynu poniżej określonych progów.

Aby oszacować rozmiar różnych obiektów magazynu, takich jak obiekty blob, zobacz wpis w blogu Opis rozliczeń usługi Azure Storage — przepustowość, transakcje i pojemność.

Monitorowanie dostępności

Dostępność usług magazynu na koncie magazynu należy monitorować, monitorując wartość w Availability kolumnie w tabelach metryk godzinowych lub minut — $MetricsHourPrimaryTransactionsBlob, $MetricsHourPrimaryTransactionsTable, $MetricsHourPrimaryTransactionsQueue, $MetricsMinutePrimaryTransactionsBlob, $MetricsMinutePrimaryTransactionsTable, , $MetricsMinutePrimaryTransactionsQueue, . $MetricsCapacityBlob Kolumna Availability zawiera wartość procentową, która wskazuje dostępność usługi lub operację interfejsu API reprezentowaną przez wiersz (pokazuje RowKey , czy wiersz zawiera metryki dla usługi jako całości, czy dla określonej operacji interfejsu API).

Każda wartość mniejsza niż 100% wskazuje, że niektóre żądania magazynu kończą się niepowodzeniem. Możesz zobaczyć, dlaczego kończą się niepowodzeniem, sprawdzając inne kolumny w danych metryk, które pokazują liczbę żądań o różnych typach błędów, takich jak ServerTimeoutError. Należy spodziewać Availability się tymczasowego spadku poniżej 100% z przyczyn takich jak przekroczenia limitu czasu serwera przejściowego, podczas gdy usługa przenosi partycje do lepszych żądań równoważenia obciążenia; logika ponawiania prób w aplikacji klienckiej powinna obsługiwać takie sporadyczne warunki. Artykuł analityka magazynu Zarejestrowane operacje i komunikaty o stanie zawiera listę typów transakcji, które metryki magazynu uwzględniają w obliczeniachAvailability.

W Azure Portal można dodać reguły alertów, aby powiadomić Użytkownika, jeśli Availability dla usługi spadnie poniżej określonego progu.

W sekcji Wskazówki dotyczące rozwiązywania problemów w tym przewodniku opisano niektóre typowe problemy z usługą magazynu związane z dostępnością.

Monitorowanie wydajności

Aby monitorować wydajność usług magazynu, można użyć następujących metryk z tabel metryk godzinowych i minutowych.

  • Wartości w AverageE2ELatency kolumnach i AverageServerLatency pokazują średni czas przetwarzania żądań przez usługę magazynu lub typ operacji interfejsu API. AverageE2ELatency to miara całkowitego opóźnienia, która obejmuje czas potrzebny na odczyt żądania i wysłanie odpowiedzi oprócz czasu potrzebnego na przetworzenie żądania (w związku z tym obejmuje opóźnienie sieci po dotarciu żądania do usługi magazynu); AverageServerLatency jest miarą tylko czasu przetwarzania i w związku z tym wyklucza wszelkie opóźnienia sieci związane z komunikacją z klientem. Zobacz sekcję Metryki pokazującą wysoką wartość AverageE2ELatency i niską wartość AverageServerLatency w dalszej części tego przewodnika, aby zapoznać się z opisem, dlaczego między tymi dwiema wartościami może występować znacząca różnica.
  • Wartości w TotalIngress kolumnach i TotalEgress pokazują całkowitą ilość danych w bajtach, przechodząc do i wychodząc z usługi magazynu lub za pośrednictwem określonego typu operacji interfejsu API.
  • Wartości w kolumnie TotalRequests pokazują całkowitą liczbę żądań odbieranych przez usługę magazynu operacji interfejsu API. TotalRequests to całkowita liczba żądań odbieranych przez usługę magazynu.

Zazwyczaj będziesz monitorować nieoczekiwane zmiany w dowolnej z tych wartości, ponieważ oznacza to, że występuje problem, który wymaga zbadania.

W Azure Portal można dodać reguły alertów, aby powiadomić Cię, jeśli jakiekolwiek metryki wydajności dla tej usługi spadną poniżej określonego progu lub przekroczą go.

W sekcji Wskazówki dotyczące rozwiązywania problemów w tym przewodniku opisano niektóre typowe problemy z usługą magazynu związane z wydajnością.

Diagnozowanie problemów z magazynem

Istnieje wiele sposobów, na które możesz się zapoznać z problemem lub problemem w aplikacji, w tym:

  • Poważna awaria powodująca awarię aplikacji lub zatrzymanie działania.
  • Istotne zmiany wartości punktu odniesienia w monitorowanych metrykach zgodnie z opisem w poprzedniej sekcji Monitorowanie usługi magazynu.
  • Raportuje od użytkowników aplikacji, że jakaś konkretna operacja nie została ukończona zgodnie z oczekiwaniami lub że niektóre funkcje nie działają.
  • Błędy generowane w aplikacji, które są wyświetlane w plikach dziennika lub za pomocą innej metody powiadomień.

Zazwyczaj problemy związane z usługami Azure Storage należą do jednej z czterech szerokich kategorii:

  • Aplikacja ma problem z wydajnością zgłaszany przez użytkowników lub ujawniany przez zmiany metryk wydajności.
  • Wystąpił problem z infrastrukturą usługi Azure Storage w co najmniej jednym regionie.
  • Aplikacja napotyka błąd zgłoszony przez użytkowników lub ujawniony przez wzrost jednej z monitorowanych metryk liczby błędów.
  • Podczas opracowywania i testowania możesz używać lokalnego emulatora magazynu. Mogą wystąpić problemy związane w szczególności z użyciem emulatora magazynu.

W poniższych sekcjach opisano kroki, które należy wykonać, aby zdiagnozować i rozwiązać problemy w każdej z tych czterech kategorii. Sekcja Wskazówki dotyczące rozwiązywania problemów w dalszej części tego przewodnika zawiera bardziej szczegółowe informacje dotyczące niektórych typowych problemów, które mogą wystąpić.

problemy z Kondycja usługi

Kondycja usługi problemy są zwykle poza kontrolą. Azure Portal zawiera informacje o wszelkich bieżących problemach z usługami platformy Azure, w tym usługami magazynu. Jeśli wybrano opcję Read-Access Geo-Redundant Storage podczas tworzenia konta magazynu, dane staną się niedostępne w lokalizacji podstawowej, aplikacja może tymczasowo przełączyć się na kopię tylko do odczytu w lokalizacji dodatkowej. Aby można było odczytywać dane z pomocniczej aplikacji, aplikacja musi mieć możliwość przełączania się między użyciem podstawowych i pomocniczych lokalizacji magazynu i pracować w trybie ograniczonej funkcjonalności z danymi tylko do odczytu. Biblioteki klienta usługi Azure Storage umożliwiają zdefiniowanie zasad ponawiania, które mogą być odczytywane z magazynu pomocniczego w przypadku awarii odczytu z magazynu podstawowego. Aplikacja musi również mieć świadomość, że dane w lokalizacji dodatkowej są ostatecznie spójne. Aby uzyskać więcej informacji, zobacz wpis w blogu Opcje nadmiarowości usługi Azure Storage i Dostęp do odczytu magazynu geograficznie nadmiarowego.

Problemy z wydajnością

Wydajność aplikacji może być subiektywna, szczególnie z perspektywy użytkownika. Dlatego ważne jest, aby mieć dostępne metryki punktu odniesienia, aby ułatwić określenie, gdzie może wystąpić problem z wydajnością. Wiele czynników może mieć wpływ na wydajność usługi Azure Storage z perspektywy aplikacji klienckiej. Te czynniki mogą działać w usłudze magazynu, kliencie lub infrastrukturze sieciowej; Dlatego ważne jest, aby mieć strategię identyfikowania źródła problemu z wydajnością.

Po zidentyfikowaniu prawdopodobnej lokalizacji przyczyny problemu z wydajnością z metryk możesz użyć plików dziennika, aby znaleźć szczegółowe informacje w celu dalszego diagnozowania i rozwiązywania problemu.

Sekcja Wskazówki dotyczące rozwiązywania problemów w dalszej części tego przewodnika zawiera więcej informacji na temat niektórych typowych problemów związanych z wydajnością, które mogą wystąpić.

Diagnozowanie błędów

Użytkownicy aplikacji mogą powiadamiać o błędach zgłaszanych przez aplikację kliencką. Metryki magazynu rejestrują również liczby różnych typów błędów z usług magazynu, takich jak NetworkError, ClientTimeoutError lub AuthorizationError. Metryki magazynu rejestrują tylko różne typy błędów, ale można uzyskać więcej szczegółów na temat poszczególnych żądań, sprawdzając dzienniki po stronie serwera, po stronie klienta i dzienniki sieci. Zazwyczaj kod stanu HTTP zwracany przez usługę magazynu wskazuje, dlaczego żądanie nie powiodło się.

Uwaga

Należy pamiętać, że należy spodziewać się sporadycznych błędów: na przykład błędów z powodu przejściowych warunków sieciowych lub błędów aplikacji.

Następujące zasoby są przydatne do zrozumienia stanu i kodów błędów związanych z magazynem:

Problemy z emulatorem magazynu

Zestaw Azure SDK zawiera emulator magazynu, który można uruchomić na programistycznej stacji roboczej. Ten emulator symuluje większość zachowań usług Azure Storage i jest przydatny podczas opracowywania i testowania, umożliwiając uruchamianie aplikacji korzystających z usług Azure Storage bez konieczności korzystania z subskrypcji platformy Azure i konta usługi Azure Storage.

W sekcji Wskazówki dotyczące rozwiązywania problemów w tym przewodniku opisano niektóre typowe problemy występujące przy użyciu emulatora magazynu.

Narzędzia do rejestrowania magazynu

Rejestrowanie magazynu umożliwia rejestrowanie żądań magazynu po stronie serwera na koncie usługi Azure Storage. Aby uzyskać więcej informacji na temat włączania rejestrowania po stronie serwera i uzyskiwania dostępu do danych dziennika, zobacz Włączanie rejestrowania magazynu i uzyskiwania dostępu do danych dziennika.

Biblioteka klienta magazynu dla platformy .NET umożliwia zbieranie danych dziennika po stronie klienta, które odnoszą się do operacji magazynu wykonywanych przez aplikację. Aby uzyskać więcej informacji, zobacz Rejestrowanie po stronie klienta przy użyciu biblioteki klienta magazynu platformy .NET.

Uwaga

W pewnych okolicznościach (takich jak błędy autoryzacji sygnatury dostępu współdzielonego) użytkownik może zgłosić błąd, dla którego nie można znaleźć żadnych danych żądania w dziennikach magazynu po stronie serwera. Możesz użyć funkcji rejestrowania biblioteki klienta magazynu, aby zbadać, czy przyczyna problemu znajduje się na kliencie, lub użyć narzędzi do monitorowania sieci w celu zbadania sieci.

Korzystanie z narzędzi do rejestrowania sieci

Możesz przechwycić ruch między klientem a serwerem, aby podać szczegółowe informacje o danych wymienianych przez klienta i serwer oraz podstawowych warunkach sieciowych. Przydatne narzędzia do rejestrowania sieci obejmują:

W wielu przypadkach dane dziennika z rejestrowania magazynu i biblioteki klienta magazynu będą wystarczające do zdiagnozowania problemu, ale w niektórych scenariuszach mogą być potrzebne bardziej szczegółowe informacje, które te narzędzia do rejestrowania sieci mogą dostarczyć. Na przykład użycie programu Fiddler do wyświetlania komunikatów HTTP i HTTPS umożliwia wyświetlanie danych nagłówka i ładunku wysyłanych do i z usług magazynu, co umożliwia sprawdzenie, w jaki sposób aplikacja kliencka ponawia operacje magazynu. Analizatory protokołów, takie jak Wireshark, działają na poziomie pakietu, umożliwiając wyświetlanie danych TCP, co umożliwi rozwiązywanie problemów z utraconymi pakietami i łącznością.

Kompleksowe śledzenie

Kompleksowe śledzenie przy użyciu różnych plików dziennika jest przydatną techniką badania potencjalnych problemów. Możesz użyć informacji o dacie/godzinie z danych metryk, aby wskazać, gdzie rozpocząć wyszukiwanie w plikach dziennika, aby uzyskać szczegółowe informacje ułatwiające rozwiązanie problemu.

Korelowanie danych dziennika

Podczas wyświetlania dzienników z aplikacji klienckich, śledzenia sieci i rejestrowania magazynu po stronie serwera ważne jest, aby móc skorelować żądania między różnymi plikami dziennika. Pliki dziennika zawierają wiele różnych pól, które są przydatne jako identyfikatory korelacji. Identyfikator żądania klienta jest najbardziej użytecznym polem do skorelowania wpisów w różnych dziennikach. Jednak czasami może być przydatne użycie identyfikatora żądania serwera lub sygnatur czasowych. Poniższe sekcje zawierają więcej szczegółów na temat tych opcji.

Identyfikator żądania klienta

Biblioteka klienta magazynu automatycznie generuje unikatowy identyfikator żądania klienta dla każdego żądania.

  • W dzienniku po stronie klienta tworzonym przez bibliotekę klienta magazynu identyfikator żądania klienta jest wyświetlany w Client Request ID polu każdego wpisu dziennika związanego z żądaniem.
  • W śledzeniu sieci, takim jak przechwycony przez program Fiddler, identyfikator żądania klienta jest widoczny w komunikatach żądań jako wartość nagłówka x-ms-client-request-id HTTP.
  • W dzienniku rejestrowania magazynu po stronie serwera identyfikator żądania klienta jest wyświetlany w kolumnie Identyfikator żądania klienta.

Uwaga

Wiele żądań może współużytkować ten sam identyfikator żądania klienta, ponieważ klient może przypisać tę wartość (chociaż biblioteka klienta magazynu automatycznie przypisuje nową wartość). Gdy klient ponawia próbę, wszystkie próby mają ten sam identyfikator żądania klienta. W przypadku partii wysłanej z klienta partia ma identyfikator pojedynczego żądania klienta.

Identyfikator żądania serwera

Usługa magazynu automatycznie generuje identyfikatory żądań serwera.

  • W dzienniku rejestrowania magazynu po stronie serwera identyfikator żądania serwera jest wyświetlany w kolumnie Request ID header .
  • W śledzeniu sieci, takim jak przechwycony przez program Fiddler, identyfikator żądania serwera jest wyświetlany w komunikatach odpowiedzi jako wartość nagłówka x-ms-request-id HTTP.
  • W dzienniku po stronie klienta tworzonym przez bibliotekę klienta magazynu identyfikator żądania serwera jest wyświetlany w Operation Text kolumnie wpisu dziennika zawierającego szczegóły odpowiedzi serwera.

Uwaga

Usługa magazynu zawsze przypisuje unikatowy identyfikator żądania serwera do każdego otrzymanego żądania, więc każda próba ponownej próby od klienta i każda operacja uwzględniona w partii ma unikatowy identyfikator żądania serwera.

W poniższym przykładzie kodu pokazano, jak używać niestandardowego identyfikatora żądania klienta.

var connectionString = Constants.connectionString;

BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

BlobContainerClient blobContainerClient = blobServiceClient.GetBlobContainerClient("demcontainer");

BlobClient blobClient = blobContainerClient.GetBlobClient("testImage.jpg");

string clientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());

using (HttpPipeline.CreateClientRequestIdScope(clientRequestID))
{
    BlobDownloadInfo download = blobClient.Download();

    using (FileStream downloadFileStream = File.OpenWrite("C:\\testImage.jpg"))
    {
        download.Content.CopyTo(downloadFileStream);
        downloadFileStream.Close();
    }
}

Sygnatury czasowe

Sygnatur czasowych można również użyć do lokalizowania powiązanych wpisów dziennika, ale należy uważać na wszelkie niesymetryczność zegara między klientem a serwerem, który może istnieć. Search plus lub minus 15 minut na dopasowanie wpisów po stronie serwera na podstawie sygnatury czasowej na kliencie. Należy pamiętać, że metadane obiektów blob dla obiektów blob zawierających metryki wskazują zakres czasu metryk przechowywanych w obiektach blob. Ten zakres czasu jest przydatny, jeśli masz wiele obiektów blob metryk dla tej samej minuty lub godziny.

Wskazówki dotyczące rozwiązywania problemów

Ta sekcja pomoże Ci w diagnozowaniu i rozwiązywaniu niektórych typowych problemów, które aplikacja może napotkać podczas korzystania z usług Azure Storage. Skorzystaj z poniższej listy, aby znaleźć informacje dotyczące konkretnego problemu.

Drzewo decyzyjne rozwiązywania problemów

Czy problem dotyczy wydajności jednej z usług magazynu?

Czy problem dotyczy dostępności jednej z usług magazynu?

Czy aplikacja kliencka otrzymuje odpowiedź HTTP 4XX (na przykład 404) z usługi magazynu?

Metryki pokazują, że wpisy dziennika percentSuccess lub analytics mają operacje ze stanem transakcji ClientOtherErrors.

Metryki pojemności pokazują nieoczekiwany wzrost użycia pojemności magazynu.

Problem wynika z używania emulatora magazynu do programowania lub testowania.

Występują problemy z instalacją zestawu Azure SDK dla platformy .NET.

Masz inny problem z usługą magazynu.

Metryki pokazują wysoką wartość AverageE2ELatency i niską wartość AverageServerLatency

Poniższa ilustracja z narzędzia do monitorowania Azure Portal przedstawia przykład, w którym wartość AverageE2ELatency jest znacznie wyższa niż wartość AverageServerLatency.

Ilustracja z Azure Portal przedstawiająca przykład, w którym wartość AverageE2ELatency jest znacznie wyższa niż wartość AverageServerLatency.

Usługa magazynu oblicza tylko metrykę AverageE2ELatency dla pomyślnych żądań i, w przeciwieństwie do AverageServerLatency, zawiera czas potrzebny klientowi na wysłanie danych i odebranie potwierdzenia z usługi magazynu. W związku z tym różnica między wartościami AverageE2ELatency i AverageServerLatency może być spowodowana powolnym reagowaniem aplikacji klienckiej lub z powodu warunków w sieci.

Uwaga

Możesz również wyświetlić E2ELatency i ServerLatency dla poszczególnych operacji magazynu w danych dziennika rejestrowania magazynu.

Badanie problemów z wydajnością klienta

Możliwe przyczyny, dla których klient reaguje powoli, obejmują ograniczoną liczbę dostępnych połączeń lub wątków lub brak zasobów, takich jak procesor CPU, pamięć lub przepustowość sieci. Możesz rozwiązać ten problem, modyfikując kod klienta tak, aby był bardziej wydajny (na przykład za pomocą wywołań asynchronicznych do usługi magazynu) lub używając większej maszyny wirtualnej (z większą ilością rdzeni i większą ilością pamięci).

W przypadku usług tabel i kolejek algorytm Nagle może również powodować wysoką wartość AverageE2ELatency w porównaniu z wartością AverageServerLatency. Aby uzyskać więcej informacji, zobacz Algorytm Nagle'a nie jest przyjazny dla małych żądań. Algorytm Nagle w kodzie można wyłączyć przy użyciu ServicePointManager klasy w System.Net przestrzeni nazw. Należy to zrobić przed wykonaniem jakichkolwiek wywołań do usług tabel lub kolejek w aplikacji, ponieważ nie ma to wpływu na połączenia, które są już otwarte. Poniższy przykład pochodzi z Application_Start metody w roli procesu roboczego.

var connectionString = Constants.connectionString;

QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);

ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

Należy sprawdzić dzienniki po stronie klienta, aby sprawdzić liczbę żądań przesyłanych przez aplikację kliencką i sprawdzić, czy nie ma ogólnego . Wąskie gardła wydajności związane z siecią w kliencie, takie jak procesor CPU, odzyskiwanie pamięci platformy .NET, wykorzystanie sieci lub pamięć. Jako punkt wyjścia do rozwiązywania problemów z aplikacjami klienckimi platformy .NET zobacz Debugowanie, Śledzenie i Profilowanie.

Badanie problemów z opóźnieniem sieci

Zazwyczaj duże opóźnienia end-to-end spowodowane przez sieć wynikają z przejściowych warunków. Możesz zbadać zarówno przejściowe, jak i trwałe problemy z siecią, takie jak porzucone pakiety, przy użyciu narzędzi takich jak Wireshark.

Aby uzyskać więcej informacji na temat rozwiązywania problemów z siecią za pomocą narzędzia Wireshark, zobacz Dodatek 2: Przechwytywanie ruchu sieciowego za pomocą narzędzia Wireshark.

Metryki pokazują niską wartość AverageE2ELatency i niską wartość AverageServerLatency, ale klient ma duże opóźnienie

W tym scenariuszu najbardziej prawdopodobną przyczyną jest opóźnienie żądań magazynu docierających do usługi magazynu. Należy zbadać, dlaczego żądania od klienta nie są przekazywane do usługi obiektów blob.

Jedną z możliwych przyczyn opóźnienia wysyłania żądań przez klienta jest ograniczona liczba dostępnych połączeń lub wątków.

Sprawdź również, czy klient wykonuje wiele ponownych prób, i zbadaj przyczynę, jeśli tak jest. Aby określić, czy klient wykonuje wiele ponownych prób, możesz:

  • Sprawdź dzienniki analityka magazynu. W przypadku wielu ponownych prób zostanie wyświetlonych wiele operacji o tym samym identyfikatorze żądania klienta, ale z różnymi identyfikatorami żądań serwera.
  • Sprawdź dzienniki klienta. Pełne rejestrowanie będzie wskazywać, że nastąpiła ponawianie próby.
  • Debuguj kod i sprawdź właściwości obiektu OperationContext skojarzonego z żądaniem. Jeśli operacja została ponowiona, właściwość RequestResults będzie zawierać wiele unikatowych identyfikatorów żądań serwera. Możesz również sprawdzić godziny rozpoczęcia i zakończenia dla każdego żądania. Aby uzyskać więcej informacji, zobacz przykład kodu w sekcji Identyfikator żądania serwera.

Jeśli klient nie ma żadnych problemów, należy zbadać potencjalne problemy z siecią, takie jak utrata pakietów. Aby zbadać problemy z siecią, możesz użyć narzędzi, takich jak Wireshark.

Aby uzyskać więcej informacji na temat rozwiązywania problemów z siecią za pomocą narzędzia Wireshark, zobacz Dodatek 2: Przechwytywanie ruchu sieciowego za pomocą narzędzia Wireshark.

Metryki pokazują wysoką wartość AverageServerLatency

W przypadku wysokiego parametru AverageServerLatency dla żądań pobierania obiektów blob należy użyć dzienników rejestrowania magazynu, aby sprawdzić, czy istnieją powtarzające się żądania dotyczące tego samego obiektu blob (lub zestawu obiektów blob). W przypadku żądań przekazywania obiektów blob należy zbadać, jakiego rozmiaru bloku używa klient (na przykład bloki o rozmiarze mniejszym niż 64 K mogą powodować narzuty, chyba że operacje odczytu znajdują się również w fragmentach mniejszych niż 64 K) i jeśli wielu klientów przekazuje bloki do tego samego obiektu blob równolegle. Należy również sprawdzić metryki na minutę pod kątem skoków liczby żądań, które powodują przekroczenie wartości docelowych skalowalności na sekundę. Aby uzyskać więcej informacji, zobacz Metryki pokazują wzrost percentTimeoutError.

Jeśli widzisz wysoką wartość AverageServerLatency dla żądań pobierania obiektów blob, gdy występują powtarzające się żądania dotyczące tego samego obiektu blob lub zestawu obiektów blob, rozważ buforowanie tych obiektów blob przy użyciu usługi Azure Cache lub Azure Content Delivery Network (CDN). W przypadku żądań przekazywania można zwiększyć przepływność przy użyciu większego rozmiaru bloku. W przypadku zapytań do tabel można również zaimplementować buforowanie po stronie klienta na klientach, którzy wykonują te same operacje zapytań i gdzie dane nie zmieniają się często.

Wartości High AverageServerLatency mogą być również objawem źle zaprojektowanych tabel lub zapytań, które powodują operacje skanowania lub które są zgodne z antywzorzecem dołączania/przedpłaty. Aby uzyskać więcej informacji, zobacz Metryki pokazują wzrost wartości PercentThrottlingError.

Uwaga

Pełną listę kontrolną dotyczącą wydajności można znaleźć tutaj: Microsoft Azure Storage Performance and Scalability Checklist (Lista kontrolna dotycząca wydajności i skalowalności).

Występują nieoczekiwane opóźnienia w dostarczaniu komunikatów w kolejce

Jeśli występuje opóźnienie między czasem dodawania komunikatu do kolejki przez aplikację a czasem, kiedy będzie ona dostępna do odczytu z kolejki, wykonaj następujące kroki, aby zdiagnozować problem:

  • Sprawdź, czy aplikacja pomyślnie dodaje komunikaty do kolejki. Przed pomyślnym pomyślnym sprawdzeniem, czy aplikacja nie ponawia AddMessage próby wykonania metody kilka razy. Dzienniki biblioteki klienta magazynu będą pokazywać powtarzające się ponowne próby operacji magazynowania.
  • Sprawdź, czy nie ma niesymetryczności zegara między rolą procesu roboczego, która dodaje komunikat do kolejki, a rolą procesu roboczego, która odczytuje komunikat z kolejki. Niesymetryczność zegara sprawia, że występuje opóźnienie przetwarzania.
  • Sprawdź, czy rola procesu roboczego, która odczytuje komunikaty z kolejki, kończy się niepowodzeniem. Jeśli klient kolejki wywoła GetMessage metodę, ale nie odpowie potwierdzeniem, komunikat pozostanie niewidoczny w kolejce do czasu wygaśnięcia okresu invisibilityTimeout . W tym momencie komunikat stanie się dostępny do ponownego przetworzenia.
  • Sprawdź, czy długość kolejki rośnie w czasie. Taka sytuacja może wystąpić, jeśli nie masz wystarczającej liczby dostępnych procesów roboczych, aby przetworzyć wszystkie komunikaty umieszczane w kolejce przez innych pracowników. Sprawdź również metryki, aby sprawdzić, czy żądania usunięcia kończą się niepowodzeniem, oraz czy kolejka liczy na komunikaty, co może wskazywać na powtarzające się nieudane próby usunięcia komunikatu.
  • Sprawdź dzienniki rejestrowania magazynu pod kątem wszystkich operacji w kolejce, które mają wyższe niż oczekiwano wartości E2ELatency i ServerLatency w dłuższym okresie niż zwykle.

Metryki pokazują wzrost percentthrottlingError

Błędy ograniczania przepustowości występują w przypadku przekroczenia wartości docelowych skalowalności usługi magazynu. Ogranicza usługi magazynu, aby upewnić się, że żaden pojedynczy klient lub dzierżawca nie może korzystać z usługi kosztem innych użytkowników. Aby uzyskać więcej informacji, zobacz Cele skalowalności i wydajności dla standardowych kont magazynu , aby uzyskać szczegółowe informacje na temat celów skalowalności dla kont magazynu i celów wydajności partycji na kontach magazynu.

Jeśli metryka PercentThrottlingError pokazuje wzrost procentu żądań, które kończą się niepowodzeniem z powodu błędu ograniczania przepustowości, należy zbadać jeden z dwóch scenariuszy:

Wzrost percentthrottlingError często występuje w tym samym czasie, co wzrost liczby żądań magazynu lub podczas wstępnego testowania obciążenia aplikacji. Może to również przejawiać się w kliencie jako komunikaty stanu HTTP "503 Server Busy" lub "500 Operation Timeout" z operacji magazynu.

Przejściowy wzrost percentthrottlingError

Jeśli widzisz skoki wartości PercentThrottlingError , które pokrywają się z okresami dużej aktywności aplikacji, możesz zaimplementować strategię wycofywania wykładniczego (nie liniowego) dla ponownych prób w kliencie. Ponowne próby wycofywania zmniejszają natychmiastowe obciążenie partycji i pomagają aplikacji wygładzić skoki ruchu. Aby uzyskać więcej informacji na temat implementowania zasad ponawiania prób przy użyciu biblioteki klienta magazynu, zobacz przestrzeń nazw Microsoft.Azure.Storage.RetryPolicies.

Uwaga

Mogą również zostać wyświetlone skoki wartości PercentThrottlingError , które nie pokrywają się z okresami wysokiej aktywności aplikacji. Najbardziej prawdopodobną przyczyną jest przenoszenie partycji przez usługę magazynu w celu poprawy równoważenia obciążenia.

Stały wzrost percentthrottlingError

Jeśli widzisz stale wysoką wartość percentthrottlingError po stałym wzroście liczby transakcji lub podczas wykonywania początkowych testów obciążeniowych w aplikacji, musisz ocenić, jak aplikacja korzysta z partycji magazynu i czy zbliża się do celów skalowalności dla konta magazynu. Jeśli na przykład występują błędy ograniczania przepustowości w kolejce (która jest liczona jako pojedyncza partycja), rozważ rozłożenie transakcji na wiele partycji przy użyciu dodatkowych kolejek. Jeśli występują błędy ograniczania przepustowości w tabeli, należy rozważyć użycie innego schematu partycjonowania w celu rozłożenia transakcji na wiele partycji przy użyciu szerszego zakresu wartości klucza partycji. Jedną z typowych przyczyn tego problemu jest antywzorzec przedpłaty/dołączania, w którym wybrano datę jako klucz partycji, a następnie wszystkie dane w danym dniu są zapisywane na jednej partycji: w ramach obciążenia może to spowodować wąskie gardło zapisu. Rozważ inny projekt partycjonowania lub oceń, czy użycie magazynu obiektów blob może być lepszym rozwiązaniem. Sprawdź również, czy ograniczanie przepustowości występuje w wyniku skoków ruchu i zbadaj sposoby wygładzania wzorca żądań.

Jeśli transakcje są dystrybuowane między wiele partycji, nadal musisz pamiętać o limitach skalowalności ustawionych dla konta magazynu. Jeśli na przykład użyto dziesięciu kolejek, każda z nich przetwarza maksymalnie 2000 komunikatów 1 KB na sekundę, będziesz mieć całkowity limit 20 000 komunikatów na sekundę dla konta magazynu. Jeśli potrzebujesz przetworzyć więcej niż 20 000 jednostek na sekundę, rozważ użycie wielu kont magazynu. Należy również pamiętać, że rozmiar żądań i jednostek ma wpływ na to, kiedy usługa magazynu ogranicza klientów. Jeśli masz większe żądania i jednostki, może nastąpić ograniczenie przepustowości wcześniej.

Nieefektywne projektowanie zapytań może również powodować osiągnięcie limitów skalowalności partycji tabel. Na przykład zapytanie z filtrem, które wybiera tylko jeden procent jednostek w partycji, ale skanuje wszystkie jednostki w partycji, będzie musiało uzyskać dostęp do każdej jednostki. Każdy odczyt jednostki będzie wliczać się do całkowitej liczby transakcji w tej partycji; W związku z tym można łatwo osiągnąć cele skalowalności.

Uwaga

Testy wydajnościowe powinny ujawnić wszelkie nieefektywne projekty zapytań w aplikacji.

Metryki pokazują wzrost percentTimeoutError

Metryki pokazują wzrost percentTimeoutError dla jednej z usług magazynu. W tym samym czasie klient otrzymuje dużą ilość komunikatów o stanie HTTP "500 Operation Timeout" z operacji magazynu.

Uwaga

Błędy przekroczenia limitu czasu mogą być tymczasowo widoczne, ponieważ obciążenie usługi magazynu równoważy żądania, przenosząc partycję na nowy serwer.

Metryka PercentTimeoutError jest agregacją następujących metryk: ClientTimeoutError, AnonymousClientTimeoutError, SASClientTimeoutError, ServerTimeoutError, AnonymousServerTimeoutError i SASServerTimeoutError.

Przekroczenia limitu czasu serwera są spowodowane przez błąd na serwerze. Limity czasu klienta występują, ponieważ operacja na serwerze przekroczyła limit czasu określony przez klienta; Na przykład klient korzystający z biblioteki klienta magazynu może ustawić limit czasu dla operacji przy użyciu ServerTimeout właściwości QueueRequestOptions klasy .

Przekroczenia limitu czasu serwera wskazują na problem z usługą magazynu, która wymaga dalszego zbadania. Możesz użyć metryk, aby sprawdzić, czy osiągasz limity skalowalności dla usługi i zidentyfikować wszelkie skoki ruchu, które mogą być przyczyną tego problemu. Jeśli problem występuje sporadycznie, może to być spowodowane działaniem równoważenia obciążenia w usłudze. Jeśli problem jest trwały i nie jest spowodowany osiągnięciem przez aplikację limitów skalowalności usługi, należy zgłosić problem z pomocą techniczną. W przypadku przekroczenia limitu czasu klienta należy zdecydować, czy limit czasu jest ustawiony na odpowiednią wartość w kliencie i zmienić wartość limitu czasu ustawioną w kliencie lub zbadać, w jaki sposób można zwiększyć wydajność operacji w usłudze magazynu, na przykład optymalizując zapytania tabeli lub zmniejszając rozmiar komunikatów.

Metryki pokazują wzrost wartości PercentNetworkError

Metryki pokazują wzrost wartości PercentNetworkError dla jednej z usług magazynu. Metryka PercentNetworkError jest agregacją następujących metryk: NetworkError, AnonymousNetworkError i SASNetworkError. Występują one, gdy usługa magazynu wykryje błąd sieci, gdy klient wysyła żądanie magazynu.

Najczęstszą przyczyną tego błędu jest odłączenie klienta przed wygaśnięciem limitu czasu w usłudze magazynu. Zbadaj kod w kliencie, aby zrozumieć, dlaczego i kiedy klient odłącza się od usługi magazynu. Możesz również użyć narzędzia Wireshark lub Tcping, aby zbadać problemy z łącznością sieciową z klienta. Te narzędzia są opisane w dodatkach.

Klient odbiera komunikaty HTTP 403 (Zabronione)

Jeśli aplikacja kliencka zgłasza błędy HTTP 403 (Zabronione), prawdopodobną przyczyną jest to, że klient używa wygasłego sygnatury dostępu współdzielonego (SAS) podczas wysyłania żądania magazynu (chociaż inne możliwe przyczyny to niesymetryczność zegara, nieprawidłowe klucze i puste nagłówki). Jeśli przyczyną jest wygasły klucz sygnatury dostępu współdzielonego, nie będą widoczne żadne wpisy w danych dziennika rejestrowania magazynu po stronie serwera. W poniższej tabeli przedstawiono przykład z dziennika po stronie klienta wygenerowanego przez bibliotekę klienta magazynu, który ilustruje ten problem:

Źródło Szczegółowości Szczegółowości Identyfikator żądania klienta Tekst operacji
Microsoft.Azure.Storage Informacji 3 85d077ab-... Starting operation with location Primary per location mode PrimaryOnly.
Microsoft.Azure.Storage Informacji 3 85d077ab -... Starting synchronous request to https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Synchronous_request.
Microsoft.Azure.Storage Informacji 3 85d077ab -... Waiting for response.
Microsoft.Azure.Storage Ostrzeżenie 2 85d077ab -... Exception thrown while waiting for response: The remote server returned an error: (403) Forbidden.
Microsoft.Azure.Storage Informacji 3 85d077ab -... Response received. Status code = 403, Request ID = <Request ID>, Content-MD5 = , ETag = .
Microsoft.Azure.Storage Ostrzeżenie 2 85d077ab -... Exception thrown during the operation: The remote server returned an error: (403) Forbidden..
Microsoft.Azure.Storage Informacji 3 85d077ab -... Checking if the operation should be retried. Retry count = 0, HTTP status code = 403, Exception = The remote server returned an error: (403) Forbidden..
Microsoft.Azure.Storage Informacji 3 85d077ab -... The next location has been set to Primary, based on the location mode.
Microsoft.Azure.Storage Error 1 85d077ab -... Retry policy did not allow for a retry. Failing with The remote server returned an error: (403) Forbidden.

W tym scenariuszu należy zbadać, dlaczego token SAS wygasa, zanim klient wyśle token do serwera:

  • Zazwyczaj nie należy ustawiać czasu rozpoczęcia podczas tworzenia sygnatury dostępu współdzielonego dla klienta do natychmiastowego użycia. Jeśli istnieją niewielkie różnice zegara między hostem generującym sygnaturę dostępu współdzielonego przy użyciu bieżącego czasu i usługi magazynu, usługa magazynu może odbierać sygnaturę dostępu współdzielonego, która nie jest jeszcze prawidłowa.
  • Nie ustawiaj bardzo krótkiego czasu wygaśnięcia dla sygnatury dostępu współdzielonego. Ponownie małe różnice zegara między hostem generującym sygnaturę dostępu współdzielonego a usługą magazynu mogą prowadzić do pozornego wygaśnięcia sygnatury dostępu współdzielonego wcześniej niż przewidywano.
  • Czy parametr wersji w kluczu sygnatury dostępu współdzielonego (na przykład sv=2015-04-05) jest zgodny z wersją używanej biblioteki klienta magazynu? Zalecamy, aby zawsze używać najnowszej wersji biblioteki klienta magazynu.
  • W przypadku ponownego wygenerowania kluczy dostępu do magazynu wszystkie istniejące tokeny SAS mogą zostać unieważnione. Ten problem może wystąpić, jeśli wygenerujesz tokeny SAS z długim czasem wygaśnięcia dla aplikacji klienckich do pamięci podręcznej.

Jeśli używasz biblioteki klienta magazynu do generowania tokenów SAS, możesz łatwo utworzyć prawidłowy token. Jeśli jednak używasz interfejsu API REST magazynu i konstruujesz tokeny SAS ręcznie, zobacz Delegowanie dostępu za pomocą sygnatury dostępu współdzielonego.

Klient odbiera komunikaty HTTP 404 (nie znaleziono)

Jeśli aplikacja kliencka odbiera komunikat HTTP 404 (Nie znaleziono) z serwera, oznacza to, że obiekt, którego klient próbował użyć (taki jak jednostka, tabela, obiekt blob, kontener lub kolejka), nie istnieje w usłudze magazynu. Istnieje wiele możliwych przyczyn, takich jak:

Klient lub inny proces wcześniej usunął obiekt

W scenariuszach, w których klient próbuje odczytywać, aktualizować lub usuwać dane w usłudze magazynu, zwykle łatwo jest zidentyfikować w dziennikach po stronie serwera poprzednią operację, która usunęła dany obiekt z usługi magazynu. Często dane dziennika pokazują, że inny użytkownik lub proces usunął obiekt. W dzienniku rejestrowania magazynu po stronie serwera kolumny operation-type i requested-object-key są wyświetlane, gdy klient usunął obiekt.

W scenariuszu, w którym klient próbuje wstawić obiekt, może nie być od razu oczywiste, dlaczego powoduje to odpowiedź HTTP 404 (Nie znaleziono), biorąc pod uwagę, że klient tworzy nowy obiekt. Jeśli jednak klient tworzy obiekt blob, musi mieć możliwość znalezienia kontenera obiektów blob. Jeśli klient tworzy komunikat, musi mieć możliwość znalezienia kolejki. A jeśli klient dodaje wiersz, musi mieć możliwość znalezienia tabeli.

Możesz użyć dziennika po stronie klienta z biblioteki klienta magazynu, aby uzyskać bardziej szczegółową wiedzę na temat tego, kiedy klient wysyła określone żądania do usługi magazynu.

Poniższy dziennik po stronie klienta wygenerowany przez bibliotekę klienta magazynu ilustruje problem, gdy klient nie może odnaleźć kontenera dla tworzonego obiektu blob. Ten dziennik zawiera szczegółowe informacje o następujących operacjach magazynowania:

Identyfikator żądania Operacja
07b26a5d-... DeleteIfExists metoda usuwania kontenera obiektów blob. Należy pamiętać, że ta operacja obejmuje HEAD żądanie sprawdzenia istnienia kontenera.
e2d06d78... CreateIfNotExists metoda tworzenia kontenera obiektów blob. Należy pamiętać, że ta operacja obejmuje HEAD żądanie, które sprawdza istnienie kontenera. Zwraca HEAD komunikat 404, ale jest kontynuowany.
de8b1c3c-... UploadFromStream metoda tworzenia obiektu blob. Żądanie PUT kończy się niepowodzeniem z komunikatem 404.

Wpisy dziennika:

Identyfikator żądania Tekst operacji
07b26a5d-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
07b26a5d-... StringToSign = HEAD............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:11 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
07b26a5d-... Waiting for response.
07b26a5d-... Response received. Status code = 200, Request ID = eeead849-...Content-MD5 = , ETag = &quot;0x8D14D2DC63D059B&quot;.
07b26a5d-... Response headers were processed successfully, proceeding with the rest of the operation.
07b26a5d-... Downloading response body.
07b26a5d-... Operation completed successfully.
07b26a5d-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
07b26a5d-... StringToSign = DELETE............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
07b26a5d-... Waiting for response.
07b26a5d-... Response received. Status code = 202, Request ID = 6ab2a4cf-..., Content-MD5 = , ETag = .
07b26a5d-... Response headers were processed successfully, proceeding with the rest of the operation.
07b26a5d-... Downloading response body.
07b26a5d-... Operation completed successfully.
e2d06d78-... Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
e2d06d78-... StringToSign = HEAD............x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
e2d06d78-... Waiting for response.
de8b1c3c-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer/blobCreated.txt.
de8b1c3c-... StringToSign = PUT...64.qCmF+TQLPhq/YYK50mP9ZQ==........x-ms-blob-type:BlockBlob.x-ms-client-request-id:de8b1c3c-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer/blobCreated.txt.
de8b1c3c-... Preparing to write request data.
e2d06d78-... Exception thrown while waiting for response: The remote server returned an error: (404) Not Found..
e2d06d78-... Response received. Status code = 404, Request ID = 353ae3bc-..., Content-MD5 = , ETag = .
e2d06d78-... Response headers were processed successfully, proceeding with the rest of the operation.
e2d06d78-... Downloading response body.
e2d06d78-... Operation completed successfully.
e2d06d78-... Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
e2d06d78-... StringToSign = PUT...0.........x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
e2d06d78-... Waiting for response.
de8b1c3c-... Writing request data.
de8b1c3c-... Waiting for response.
e2d06d78-... Exception thrown while waiting for response: The remote server returned an error: (409) Conflict..
e2d06d78-... Response received. Status code = 409, Request ID = c27da20e-..., Content-MD5 = , ETag = .
e2d06d78-... Downloading error response body.
de8b1c3c-... Exception thrown while waiting for response: The remote server returned an error: (404) Not Found..
de8b1c3c-... Response received. Status code = 404, Request ID = 0eaeab3e-..., Content-MD5 = , ETag = .
de8b1c3c-... Exception thrown during the operation: The remote server returned an error: (404) Not Found..
de8b1c3c-... Retry policy did not allow for a retry. Failing with The remote server returned an error: (404) Not Found..
e2d06d78-... Retry policy did not allow for a retry. Failing with The remote server returned an error: (409) Conflict..

W tym przykładzie dziennik pokazuje, że klient przeplata żądania z CreateIfNotExists metody (identyfikator żądania e2d06d78...) z żądaniami z UploadFromStream metody (de8b1c3c-...). Ta interleaving dzieje się, ponieważ aplikacja kliencka wywołuje te metody asynchronicznie. Zmodyfikuj kod asynchroniczny w kliencie, aby upewnić się, że tworzy kontener przed podjęciem próby przekazania jakichkolwiek danych do obiektu blob w tym kontenerze. Najlepiej utworzyć wszystkie kontenery z wyprzedzeniem.

Problem z autoryzacją sygnatury dostępu współdzielonego

Jeśli aplikacja kliencka próbuje użyć klucza SAS, który nie zawiera niezbędnych uprawnień do operacji, usługa magazynu zwraca klientowi komunikat HTTP 404 (Nie znaleziono). W tym samym czasie w metrykach zostanie również wyświetlona wartość inna niż zero.SASAuthorizationError

W poniższej tabeli przedstawiono przykładowy komunikat dziennika po stronie serwera z pliku dziennika rejestrowania magazynu:

Name (Nazwa) Value
Godzina rozpoczęcia żądania 2014-05-30T06:17:48.4473697Z
Typ operacji GetBlobProperties
Stan żądania SASAuthorizationError
Kod stanu HTTP 404
Typ uwierzytelniania Sas
Typ usługi Blob
Adres URL żądania https://domemaildist.blob.core.windows.net/azureimblobcontainer/blobCreatedViaSAS.txt
  ?sv=2014-02-14&sr=c&si=mypolicy&sig=XXXXX&; api-version=2014-02-14
Nagłówek identyfikatora żądania <Nagłówek identyfikatora żądania>
Identyfikator żądania klienta <Identyfikator żądania klienta>

Zbadaj, dlaczego aplikacja kliencka próbuje wykonać operację, do której nie udzielono jej uprawnień.

Kod JavaScript po stronie klienta nie ma uprawnień dostępu do obiektu

Jeśli używasz klienta JavaScript, a usługa magazynu zwraca komunikaty HTTP 404, sprawdź, czy w przeglądarce występują następujące błędy języka JavaScript:

SEC7120: nie odnaleziono źródła http://localhost:56309 w nagłówku Access-Control-Allow-Origin.
SCRIPT7002: XMLHttpRequest: błąd sieci 0x80070005, odmowa dostępu.

Uwaga

Narzędzia deweloperskie F12 w programie Internet Explorer umożliwiają śledzenie komunikatów wymienianych między przeglądarką a usługą magazynu podczas rozwiązywania problemów z językiem JavaScript po stronie klienta.

Te błędy występują, ponieważ przeglądarka sieci Web implementuje to samo ograniczenie zabezpieczeń zasad pochodzenia , które uniemożliwia stronie internetowej wywoływanie interfejsu API w innej domenie niż domena, z których pochodzi strona.

Aby obejść problem z językiem JavaScript, możesz skonfigurować współużytkowanie zasobów między źródłami (CORS) dla usługi magazynu, do którą uzyskuje dostęp klient. Aby uzyskać więcej informacji, zobacz Obsługa współużytkowania zasobów między źródłami (CORS) dla usług Azure Storage.

W poniższym przykładzie kodu pokazano, jak skonfigurować usługę blob, aby umożliwić skryptowi JavaScript działającemu w domenie firmy Contoso dostęp do obiektu blob w usłudze blob Storage:

var connectionString = Constants.connectionString;

 BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

 BlobServiceProperties sp = blobServiceClient.GetProperties();

 // Set the service properties.
 sp.DefaultServiceVersion = "2013-08-15";
 BlobCorsRule bcr = new BlobCorsRule();
 bcr.AllowedHeaders = "*";

 bcr.AllowedMethods = "GET,POST";
 bcr.AllowedOrigins = "http://www.contoso.com";
 bcr.ExposedHeaders = "x-ms-*";
 bcr.MaxAgeInSeconds = 5;
 sp.Cors.Clear();
 sp.Cors.Add(bcr);
 blobServiceClient.SetProperties(sp);

Awaria sieci

W pewnych okolicznościach utracone pakiety sieciowe mogą prowadzić do zwrócenia przez usługę magazynu komunikatów HTTP 404 do klienta. Na przykład gdy aplikacja kliencka usuwa jednostkę z usługi tabel, zobaczysz, że klient zgłasza wyjątek magazynu, zgłaszając komunikat o stanie "HTTP 404 (nie znaleziono)" z usługi tabel. Podczas badania tabeli w usłudze magazynu tabel zobaczysz, że usługa usunie jednostkę zgodnie z żądaniem.

Szczegóły wyjątku w kliencie obejmują identyfikator żądania (7e84f12d...) przypisany przez usługę tabel dla żądania. Te informacje umożliwiają zlokalizowanie szczegółów żądania w dziennikach magazynu po stronie serwera, wyszukując request-id-header w kolumnie w pliku dziennika. Możesz również użyć metryk, aby określić, kiedy wystąpią takie błędy, a następnie przeszukać pliki dziennika na podstawie czasu zarejestrowania tego błędu przez metryki. Ten wpis dziennika pokazuje, że usuwanie nie powiodło się z komunikatem o stanie "HTTP (404) Client Other Error". Ten sam wpis dziennika zawiera również identyfikator żądania wygenerowany przez klienta w kolumnie client-request-id (813ea74f...).

Dziennik po stronie serwera zawiera również inny wpis o tej samej client-request-id wartości (813ea74f...) dla pomyślnej operacji usuwania dla tej samej jednostki i z tego samego klienta. Ta pomyślna operacja usuwania miała miejsce bardzo krótko przed niepowodzeniem żądania usunięcia.

Najbardziej prawdopodobną przyczyną tego scenariusza jest wysłanie przez klienta żądania usunięcia jednostki do usługi tabel, która zakończyła się powodzeniem, ale nie otrzymała potwierdzenia z serwera (być może z powodu tymczasowego problemu z siecią). Następnie klient automatycznie ponowił próbę wykonania operacji (przy użyciu tego samego client-request-id), a ta ponawianie próby nie powiodło się, ponieważ jednostka została już usunięta.

Jeśli ten problem występuje często, należy zbadać, dlaczego klient nie otrzymuje potwierdzenia z usługi tabel. Jeśli problem występuje sporadycznie, należy wychwycić błąd "HTTP (404) Nie znaleziono" i zalogować go w kliencie, ale zezwolić klientowi na kontynuowanie.

Klient odbiera komunikaty HTTP 409 (konflikt)

W poniższej tabeli przedstawiono wyodrębnienie z dziennika po stronie serwera dla dwóch operacji klienta: DeleteIfExists następuje natychmiastowe CreateIfNotExists użycie tej samej nazwy kontenera obiektów blob. Każda operacja klienta powoduje wysłanie dwóch żądań do serwera, najpierw GetContainerProperties żądania w celu sprawdzenia, czy kontener istnieje, a następnie DeleteContainer żądania lub CreateContainer .

Znacznik czasu Operacja Result (Wynik) Nazwa kontenera Identyfikator żądania klienta
05:10:13.7167225 GetContainerProperties 200 mmcont c9f52c89-...
05:10:13.8167325 DeleteContainer 202 mmcont c9f52c89-...
05:10:13.8987407 GetContainerProperties 404 mmcont bc881924-...
05:10:14.2147723 CreateContainer 409 mmcont bc881924-...

Kod w aplikacji klienckiej usuwa, a następnie natychmiast ponownie tworzy kontener obiektów blob o tej samej nazwie: CreateIfNotExists metoda (Identyfikator żądania klienta bc881924-...) ostatecznie kończy się niepowodzeniem z powodu błędu HTTP 409 (Konflikt). Gdy klient usuwa kontenery obiektów blob, tabele lub kolejki, istnieje krótki okres, zanim nazwa stanie się ponownie dostępna.

Aplikacja kliencka powinna używać unikatowych nazw kontenerów za każdym razem, gdy tworzy nowe kontenery, jeśli wzorzec usuwania/ponownego tworzenia jest typowy.

Metryki pokazują, że wpisy dziennika funkcji PercentSuccess lub analytics mają operacje ze stanem transakcji ClientOtherErrors

Metryka PercentSuccess przechwytuje procent operacji zakończonych powodzeniem na podstawie kodu stanu HTTP. Operacje z kodami stanu 2XX są pomyślne, natomiast operacje z kodami stanu w zakresach 3XX, 4XX i 5XX są liczone jako nieudane i obniżają wartość metryki PercentSuccess . W plikach dziennika magazynu po stronie serwera te operacje są rejestrowane ze stanem transakcji ClientOtherErrors.

Należy pamiętać, że te operacje zostały ukończone pomyślnie i w związku z tym nie wpływają na inne metryki, takie jak dostępność. Oto kilka przykładów operacji, które są wykonywane pomyślnie, ale mogą powodować niepowodzenie kodów stanu HTTP:

  • ResourceNotFound (Nie znaleziono 404), na przykład z GET żądania do obiektu blob, który nie istnieje.
  • ResourceAlreadyExists (Konflikt 409), na przykład z CreateIfNotExist operacji, w której zasób już istnieje.
  • ConditionNotMet (Nie zmodyfikowano 304), na przykład z operacji warunkowej, takiej jak wysłanie przez klienta ETag wartości i nagłówka HTTP If-None-Match w celu żądania obrazu tylko wtedy, gdy został zaktualizowany od ostatniej operacji.

Listę typowych kodów błędów interfejsu API REST zwracanych przez usługi magazynu można znaleźć na stronie Typowe kody błędów interfejsu API REST.

Metryki pojemności pokazują nieoczekiwany wzrost użycia pojemności magazynu

Jeśli zobaczysz nagłe, nieoczekiwane zmiany w użyciu pojemności na koncie magazynu, możesz zbadać przyczyny, najpierw przeglądając metryki dostępności; Na przykład zwiększenie liczby żądań usuwania zakończonych niepowodzeniem może prowadzić do zwiększenia ilości magazynu obiektów blob używanych jako operacje oczyszczania specyficzne dla aplikacji, których można się spodziewać, że zwalnianie miejsca może nie działać zgodnie z oczekiwaniami (na przykład dlatego, że tokeny SAS używane do zwalniania miejsca wygasły).

Problem wynika z używania emulatora magazynu na potrzeby programowania lub testowania

Zazwyczaj używasz emulatora magazynu podczas tworzenia i testowania, aby uniknąć wymagania dotyczącego konta usługi Azure Storage. Typowe problemy, które mogą wystąpić podczas korzystania z emulatora magazynu, to:

Funkcja "X" nie działa w emulatorze magazynu

Emulator magazynu nie obsługuje wszystkich funkcji usług azure storage, takich jak usługa plików. Aby uzyskać więcej informacji, zobacz Korzystanie z emulatora usługi Azure Storage na potrzeby programowania i testowania.

W przypadku tych funkcji, które nie obsługują emulatora magazynu, użyj usługi Azure Storage w chmurze.

Błąd "Wartość jednego z nagłówków HTTP nie jest w prawidłowym formacie" podczas korzystania z emulatora magazynu

Testujesz aplikację korzystającą z biblioteki klienta magazynu w emulatorze magazynu lokalnego, a wywołania metody, takie jak CreateIfNotExists niepowodzenie, z komunikatem o błędzie "Wartość jednego z nagłówków HTTP nie jest w prawidłowym formacie". Oznacza to, że używana wersja emulatora magazynu nie obsługuje wersji używanej biblioteki klienta magazynu. Biblioteka klienta magazynu dodaje nagłówek x-ms-version do wszystkich żądań, które wykonuje. Jeśli emulator magazynu nie rozpoznaje wartości w nagłówku x-ms-version , odrzuca żądanie.

Dzienniki klienta biblioteki magazynu umożliwiają wyświetlenie wartości x-ms-version header wysyłanej biblioteki. Możesz również zobaczyć wartość elementu , x-ms-version header jeśli używasz programu Fiddler do śledzenia żądań z aplikacji klienckiej.

Ten scenariusz zazwyczaj występuje w przypadku instalowania i używania najnowszej wersji biblioteki klienta magazynu bez aktualizowania emulatora magazynu. Należy zainstalować najnowszą wersję emulatora magazynu lub użyć magazynu w chmurze zamiast emulatora do programowania i testowania.

Uruchomienie emulatora magazynu wymaga uprawnień administracyjnych

Po uruchomieniu emulatora magazynu zostanie wyświetlony monit o podanie poświadczeń administratora. Dzieje się tak tylko wtedy, gdy inicjujesz emulator magazynu po raz pierwszy. Po zainicjowaniu emulatora magazynu nie potrzebujesz uprawnień administracyjnych, aby uruchomić go ponownie.

Aby uzyskać więcej informacji, zobacz Korzystanie z emulatora usługi Azure Storage na potrzeby programowania i testowania. Możesz również zainicjować emulator magazynu w programie Visual Studio, który będzie również wymagał uprawnień administracyjnych.

Występują problemy z instalacją zestawu Azure SDK dla platformy .NET

Próba zainstalowania zestawu SDK kończy się niepowodzeniem podczas próby zainstalowania emulatora magazynu na komputerze lokalnym. Dziennik instalacji zawiera jeden z następujących komunikatów:

  • CAQuietExec: Błąd: Nie można uzyskać dostępu do wystąpienia SQL
  • CAQuietExec: Błąd: Nie można utworzyć bazy danych

Przyczyną jest problem z istniejącą instalacją bazy danych LocalDB. Domyślnie emulator magazynu używa bazy danych LocalDB do utrwalania danych podczas symulowania usług azure storage. Wystąpienie bazy danych LocalDB można zresetować, uruchamiając następujące polecenia w oknie wiersza polecenia przed próbą zainstalowania zestawu SDK.

sqllocaldb stop v11.0
sqllocaldb delete v11.0
delete %USERPROFILE%\WAStorageEmulatorDb3*.*
sqllocaldb create v11.0

Polecenie delete usuwa wszystkie stare pliki bazy danych z poprzednich instalacji emulatora magazynu.

Masz inny problem z usługą magazynu

Jeśli poprzednie sekcje rozwiązywania problemów nie zawierają problemu z usługą magazynu, należy zastosować następujące podejście do diagnozowania i rozwiązywania problemów.

  • Sprawdź metryki, aby sprawdzić, czy nastąpiła jakakolwiek zmiana w stosunku do oczekiwanego zachowania punktu odniesienia. Na podstawie metryk możesz określić, czy problem jest przejściowy, czy trwały, i jakie operacje magazynu mają wpływ na problem.
  • Informacje o metrykach ułatwiają wyszukiwanie danych dziennika po stronie serwera w celu uzyskiwania bardziej szczegółowych informacji o wszelkich występujących błędach. Te informacje mogą pomóc w rozwiązaniu i rozwiązaniu problemu.
  • Jeśli informacje w dziennikach po stronie serwera nie są wystarczające do pomyślnego rozwiązania problemu, możesz użyć dzienników po stronie klienta biblioteki klienta magazynu, aby zbadać zachowanie aplikacji klienckiej i narzędzi, takich jak Fiddler i Wireshark, w celu zbadania sieci.

Aby uzyskać więcej informacji na temat korzystania z programu Fiddler, zobacz Dodatek 1: Przechwytywanie ruchu HTTP i HTTPS przy użyciu narzędzia Fiddler.

Aby uzyskać więcej informacji na temat korzystania z narzędzia Wireshark, zobacz Dodatek 2: Przechwytywanie ruchu sieciowego za pomocą narzędzia Wireshark.

Dodatki

W dodatkach opisano kilka narzędzi, które mogą okazać się przydatne podczas diagnozowania i rozwiązywania problemów z usługą Azure Storage (i innymi usługami). Te narzędzia nie są częścią usługi Azure Storage, a niektóre są produktami innych firm. W związku z tym narzędzia omówione w tych dodatkach nie są objęte żadną umową pomocy technicznej, którą możesz mieć z platformą Microsoft Azure ani usługą Azure Storage. W związku z tym w ramach procesu oceny należy przeanalizować opcje licencjonowania i pomocy technicznej dostępne dla dostawców tych narzędzi.

Dodatek 1: przechwytywanie ruchu HTTP i HTTPS przy użyciu narzędzia Fiddler

Fiddler to przydatne narzędzie do analizowania ruchu HTTP i HTTPS między aplikacją kliencką a używaną usługą Azure Storage.

Uwaga

Program Fiddler może dekodować ruch HTTPS. Należy uważnie zapoznać się z dokumentacją programu Fiddler, aby zrozumieć, jak to działa i jakie ma to wpływ na bezpieczeństwo.

Ten dodatek zawiera krótki przewodnik po sposobie konfigurowania programu Fiddler w celu przechwytywania ruchu między maszyną lokalną, na której zainstalowano program Fiddler, a usługami azure storage.

Po uruchomieniu programu Fiddler rozpocznie przechwytywanie ruchu HTTP i HTTPS na maszynie lokalnej. Poniżej przedstawiono kilka przydatnych poleceń do kontrolowania programu Fiddler:

  • Zatrzymaj i rozpocznij przechwytywanie ruchu. W menu głównym przejdź do pozycji Plik , a następnie wybierz pozycję Przechwyć ruch , aby włączyć i wyłączyć przechwytywanie.
  • Zapisz przechwycone dane ruchu. W menu głównym przejdź do pozycji Plik, wybierz pozycję Zapisz, a następnie wybierz pozycję Wszystkie sesje. Umożliwia to zapisanie ruchu w pliku archiwum sesji. Możesz ponownie załadować archiwum sesji później do analizy lub wysłać je na żądanie pomocy technicznej firmy Microsoft.

Aby ograniczyć ilość ruchu przechwyconego przez program Fiddler, można użyć filtrów skonfigurowanych na karcie Filtry . Poniższy zrzut ekranu przedstawia filtr, który przechwytuje tylko ruch wysyłany do contosoemaildist.table.core.windows.net punktu końcowego magazynu:

Zrzut ekranu przedstawiający filtr, który przechwytuje tylko ruch wysyłany do punktu końcowego magazynu contosoemaildist.table.core.windows.net.

Dodatek 2: przechwytywanie ruchu sieciowego za pomocą narzędzia Wireshark

Wireshark to analizator protokołów sieciowych, który umożliwia wyświetlanie szczegółowych informacji o pakietach dla szerokiego zakresu protokołów sieciowych.

Poniższa procedura pokazuje, jak przechwycić szczegółowe informacje o pakietach dla ruchu z komputera lokalnego, na którym zainstalowano usługę Wireshark do usługi tabel na koncie usługi Azure Storage.

  1. Uruchom narzędzie Wireshark na komputerze lokalnym.

  2. W sekcji Start wybierz lokalny interfejs sieciowy lub interfejsy połączone z Internetem.

  3. Wybierz pozycję Opcje przechwytywania.

  4. Dodaj filtr do pola tekstowego Filtr przechwytywania . Na przykład host contosoemaildist.table.core.windows.net program Wireshark zostanie skonfigurowany do przechwytywania tylko pakietów wysyłanych do lub z punktu końcowego usługi tabeli na koncie magazynu contosoemaildist . Zapoznaj się z pełną listą filtrów przechwytywania.

    Zrzut ekranu przedstawiający sposób dodawania filtru do pola tekstowego Przechwyć filtr.

  5. Kliknij przycisk Start. Narzędzie Wireshark będzie teraz przechwytywać wszystkie pakiety wysyłane do lub z punktu końcowego usługi tabeli podczas korzystania z aplikacji klienckiej na komputerze lokalnym.

  6. Po zakończeniu wybierz pozycję Zatrzymaj przechwytywanie> w menu głównym.

  7. Aby zapisać przechwycone dane w pliku przechwytywania wireshark, wybierz pozycję Zapisz plik> w menu głównym.

Program WireShark wyróżni wszystkie błędy, które istnieją w oknie listy pakietów . Możesz również użyć okna Informacje o ekspertach (wybierz pozycję Analizujinformacje o ekspertach>), aby wyświetlić podsumowanie błędów i ostrzeżeń.

Zrzut ekranu przedstawiający okno Informacje o ekspertach, w którym można wyświetlić podsumowanie błędów i ostrzeżeń.

Możesz również wyświetlić dane TCP, gdy warstwa aplikacji je zobaczy, klikając prawym przyciskiem myszy dane TCP i wybierając pozycję Postępuj zgodnie z Stream TCP. Jest to przydatne w przypadku przechwycenia zrzutu bez filtru przechwytywania. Aby uzyskać więcej informacji, zobacz Obserwowanie strumieni TCP.

Zrzut ekranu przedstawiający sposób wyświetlania danych TCP w miarę wyświetlania ich przez warstwę aplikacji.

Uwaga

Aby uzyskać więcej informacji na temat korzystania z narzędzia Wireshark, zobacz Przewodnik użytkowników programu Wireshark.

Dodatek 4. Wyświetlanie metryk i danych dziennika przy użyciu programu Excel

Wiele narzędzi umożliwia pobranie danych metryk usługi Storage z usługi Azure Table Storage w formacie rozdzielanym, który ułatwia ładowanie danych do programu Excel na potrzeby wyświetlania i analizy. Dane rejestrowania magazynu z Azure Blob Storage są już w rozdzielanym formacie, który można załadować do programu Excel. Należy jednak dodać odpowiednie nagłówki kolumn na podstawie informacji w witrynie analityka magazynu Format dziennika i analityka magazynu Schemat tabeli metryk.

Aby zaimportować dane rejestrowania magazynu do programu Excel po pobraniu ich z magazynu obiektów blob:

  • W menu Dane wybierz pozycję Z tekstu.
  • Przejdź do pliku dziennika, który chcesz wyświetlić, i wybierz pozycję Importuj.
  • W kroku 1 Kreatora importowania tekstu wybierz pozycję Rozdzielane.

W kroku 1 Kreatora importu tekstu wybierz pozycję Średnik jako jedyny ogranicznik i wybierz podwójny cudzysłów jako kwalifikator tekstu. Następnie wybierz pozycję Zakończ i wybierz miejsce umieszczenia danych w skoroszycie.

Dodatek 5. Monitorowanie za pomocą usługi Application Insights dla usługi Azure DevOps

Możesz również użyć funkcji Application Insights dla usługi Azure DevOps w ramach monitorowania wydajności i dostępności. To narzędzie może:

  • Upewnij się, że usługa internetowa jest dostępna i odpowiada. Niezależnie od tego, czy aplikacja jest witryną internetową, czy aplikacją urządzenia korzystającą z usługi internetowej, może co kilka minut testować twój adres URL z lokalizacji na całym świecie i poinformować Cię, czy wystąpił problem.
  • Szybko diagnozuj wszelkie problemy z wydajnością lub wyjątki w usłudze internetowej. Dowiedz się, czy procesor CPU lub inne zasoby są rozciągnięte, pobierz ślady stosu z wyjątków i łatwo przeszukaj ślady dzienników. Jeśli wydajność aplikacji spadnie poniżej dopuszczalnych limitów, firma Microsoft może wysłać Ci wiadomość e-mail. Możesz monitorować zarówno usługi sieci Web .NET, jak i Java.

Więcej informacji można znaleźć w witrynie Co to jest usługa Application Insights.

Następne kroki

Aby uzyskać więcej informacji na temat analizy w usłudze Azure Storage, zobacz następujące zasoby:

Zastrzeżenie dotyczące innych firm

Produkty innych firm omówione w tym artykule są wytwarzane przez producentów niezależnych od firmy Microsoft. Firma Microsoft nie udziela żadnych gwarancji, dorozumianych ani żadnego innego rodzaju, w odniesieniu do wydajności lub niezawodności tych produktów.

Skontaktuj się z nami, aby uzyskać pomoc

Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii platformy Azure.