Udostępnij za pośrednictwem

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

  • Artykuł

W tym przewodniku pokazano, jak używać funkcji, takich jak azure analityka magazynu, rejestrowanie po stronie klienta w bibliotece klienta usługi Azure Storage oraz inne 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 i usługami Azure Storage.

Ten przewodnik jest przeznaczony przede wszystkim dla deweloperów Usługi online korzystających z usług Azure Storage i informatyków 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 ułatwiające podjęcie decyzji, czy problem w aplikacji jest związany z usługą Azure Storage.
  • W celu zapewnienia praktycznych wskazówek dotyczących rozwiązywania problemów związanych z usługą Azure Storage.

Uwaga 16.

Ten artykuł jest oparty na metrykach i dziennikach analityka magazynu nazywanych klasycznymi metrykami i dziennikami. Zalecamy używanie metryk i dzienników usługi Azure Storage w usłudze Azure Monitor zamiast analityka magazynu dzienników. 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 złożone 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 używać wielu technologii magazynowania, takich jak tabele usługi Microsoft Azure Storage, obiekty blob, kolejki lub pliki oprócz innych magazynów danych, takich jak relacyjne i bazy danych dokumentów.

Aby pomyślnie zarządzać takimi aplikacjami, należy aktywnie monitorować je i zrozumieć, 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 nieoczekiwanych zmian zachowania (takich jak wolniejsze niż zwykle czasy odpowiedzi) i używać rejestrowania do zbierania bardziej szczegółowych danych i analizowania problemu w głębi systemu. Informacje diagnostyczne uzyskiwane z monitorowania i rejestrowania ułatwiają określenie głównej przyczyny napotkanego problemu przez aplikację. Następnie możesz rozwiązać ten problem i określić odpowiednie kroki, aby je skorygować. Azure Storage to podstawowa usługa 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 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 sekcji Kompleksowe śledzenie 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 problemów z niektórymi typowymi problemami związanymi z magazynem, które mogą wystąpić.

Sekcja Dołączanie zawiera informacje o korzystaniu z innych narzędzi, takich jak Wireshark i Netmon do analizowania danych pakietów sieciowych, oraz narzędzia 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 liczników monitor wydajności systemu Windows w usłudze Azure Storage. W obszarze Metryki magazynu znajdziesz kompleksowy zestaw metryk (liczniki w terminologii systemu Windows monitor wydajności), takie jak dostępność usługi, łączna liczba żądań do usługi lub procent pomyślnych żądań do usługi. Aby uzyskać pełną listę dostępnych metryk, zobacz analityka magazynu Metrics Table Schema (Schemat tabeli metryk analityka magazynu). 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 witrynie Azure Portal , i skonfigurować reguły, które powiadamiają administratorów pocztą e-mail za każdym razem, gdy metryka godzinowa przekroczy określony próg. Aby uzyskać więcej informacji, zobacz Odbieranie powiadomień o alertach.

Zalecamy przejrzenie usługi Azure Monitor for Storage (wersja zapoznawcza). Jest to funkcja usługi Azure Monitor, która oferuje kompleksowe monitorowanie kont usługi Azure Storage, zapewniając ujednolicony widok wydajności, pojemności i dostępności usług Azure Storage. Nie wymaga to włączenia ani skonfigurowania niczego i natychmiastowego wyświetlenia tych metryk ze wstępnie zdefiniowanych interakcyjnych wykresów i innych wizualizacji.

Usługa magazynu próbuje najlepiej zbierać metryki, ale może nie rejestrować każdej operacji magazynu.

W witrynie Azure Portal można wyświetlać metryki, takie jak dostępność, łączna liczba żądań i średnie opóźnienia dla konta magazynu. Skonfigurowano również regułę powiadamiania o alertach administratora, jeśli dostępność spadnie poniżej określonego poziomu. Z wyświetlania tych danych jednym z możliwych obszarów badania jest procent powodzenia usługi tabeli poniżej 100% (aby uzyskać więcej informacji, zobacz Metryki pokazują niską wartość PercentSuccess lub wpisy dziennika analizy mają operacje ze stanem transakcji ClientOtherErrors sekcji).

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

  • Ustanowienie niektórych metryk punktu odniesienia dla aplikacji, które umożliwią porównywanie bieżących danych i identyfikowanie wszelkich znaczących 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 nieoczekiwanych błędów i anomalii, takich jak skoki liczby błędów lub współczynniki żądań.
  • Rejestrowanie metryk godzinowych i używanie ich do monitorowania średnich wartości, takich jak średnie liczby błędów i współczynniki żądań.
  • Badanie potencjalnych problemów przy użyciu narzędzi diagnostycznych, jak opisano w dalszej części sekcji Diagnozowanie problemów z magazynem.

Wykresy na poniższej ilustracji ilustrują, jak średnie, które występuje dla metryk godzinowych, mogą ukrywać skoki aktywności. Metryki godzinowe pokazują stałą częstotliwość żądań, podczas gdy metryki minut ujawniają wahania, które naprawdę mają miejsce.

Wykresy pokazujące, jak średnie wystąpienie 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ą witryny Azure Portal możesz 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.

Witryna Azure Portal może również udostępniać powiadomienia o zdarzeniach, które mają wpływ na różne usługi platformy Azure.

Uwaga 16.

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.

Monitorowanie pojemności

Metryki magazynu przechowują tylko metryki pojemności dla usługi blob, ponieważ obiekty blob zwykle stanowią największą część przechowywanych danych (w momencie zapisywania nie można używać metryk magazynu do monitorowania pojemności tabel i kolejek). Te dane można znaleźć w tabeli, $MetricsCapacityBlob jeśli włączono monitorowanie dla usługi Blob Service. Metryki magazynu rejestrują te dane raz dziennie i można użyć wartości RowKey , aby określić, czy wiersz zawiera jednostkę powiązaną z danymi użytkownika (wartość data) lub danymi analitycznymi (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 16.

Należy monitorować te wartości pod kątem wczesnego ostrzeżenia, że zbliżasz się do limitów pojemności konta magazynu. W witrynie Azure Portal możesz dodać reguły alertów, aby powiadomić o przekroczeniu lub przekroczeniu określonego progu zagregowanego użycia magazynu.

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

Należy monitorować dostępność usług magazynu na koncie magazynu, monitorując wartość w kolumnie w Availability tabelach metryk godzinowych lub minutowych — $MetricsHourPrimaryTransactionsBlob, $MetricsHourPrimaryTransactionsTable$MetricsHourPrimaryTransactionsQueue$MetricsMinutePrimaryTransactionsBlob$MetricsMinutePrimaryTransactionsTable$MetricsMinutePrimaryTransactionsQueue. $MetricsCapacityBlob Kolumna Availability zawiera wartość procentową, która wskazuje dostępność usługi lub operacji interfejsu API reprezentowanej przez wiersz ( RowKey pokazuje, czy wiersz zawiera metryki dla usługi jako całości lub 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ń z różnymi typami błędów, takimi jak ServerTimeoutError. Należy spodziewać Availability się tymczasowego spadku poniżej 100% z powodów, takich jak przejściowe przekroczenia limitu czasu serwera, podczas gdy usługa przenosi partycje w celu lepszego równoważenia obciążenia żądań. Logika ponawiania prób w aplikacji klienckiej powinna obsługiwać takie sporadyczne warunki. W artykule analityka magazynu Zarejestrowane operacje i komunikaty o stanie wymieniono typy transakcji, które metryki magazynu zawierają w obliczeniachAvailability.

W witrynie Azure Portal możesz dodać reguły alertów, aby otrzymywać powiadomienia, 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żesz użyć następujących metryk z tabel metryk godzinowych i minutowych.

  • Wartości w kolumnach AverageE2ELatency i AverageServerLatency pokazują średni czas przetwarzania żądań przez usługę magazynu lub typ operacji interfejsu API. AverageE2ELatency to miara kompleksowego opóźnienia, która obejmuje czas potrzebny na odczytanie żądania i wysłanie odpowiedzi oprócz czasu potrzebnego do przetworzenia żądania (w związku z tym obejmuje opóźnienie sieci po osiągnięciu 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ę Metrics show high AverageE2ELatency and low AverageServerLatency w dalszej części tego przewodnika, aby dowiedzieć się, dlaczego może istnieć znacząca różnica między tymi dwiema wartościami.
  • Wartości w kolumnach TotalIngress i TotalEgress pokazują łączną ilość danych w bajtach przychodzących do usługi magazynu i wychodzących z usługi magazynu lub za pomocą określonego typu operacji interfejsu API.
  • Wartości w kolumnie TotalRequests pokazują łączną 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ż wskazuje to na problem, który wymaga zbadania.

W witrynie Azure Portal możesz dodać reguły alertów, aby otrzymywać powiadomienia, jeśli jakiekolwiek metryki wydajności dla tej usługi spadną poniżej lub przekroczy określony próg.

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żna się dowieć o problemie lub problemie w aplikacji, w tym:

  • Poważny błąd powodujący awarię lub zatrzymanie działania aplikacji.
  • Istotne zmiany z wartości punktu odniesienia w monitorowanych metrykach zgodnie z opisem w poprzedniej sekcji Monitorowanie usługi magazynu.
  • Raporty od użytkowników aplikacji, że określona operacja nie została ukończona zgodnie z oczekiwaniami lub że niektóre funkcje nie działają.
  • Błędy wygenerowane w aplikacji, które pojawiają się w plikach dziennika lub za pośrednictwem 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 w metrykach wydajności.
  • Wystąpił problem z infrastrukturą usługi Azure Storage w co najmniej jednym regionie.
  • Aplikacja napotyka błąd zgłaszany przez użytkowników lub ujawniany przez zwiększenie liczby monitorowanych metryk błędów.
  • Podczas programowania i testowania możesz używać lokalnego emulatora magazynu; Mogą wystąpić pewne problemy związane konkretnie 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 więcej szczegółowych informacji na temat niektórych typowych problemów, które mogą wystąpić.

Kondycja usługi problemy

Kondycja usługi problemy są zwykle poza kontrolą. Witryna Azure Portal zawiera informacje o bieżących problemach z usługami platformy Azure, w tym z usługami magazynu. Jeśli zdecydujesz się na magazyn geograficznie nadmiarowy z dostępem do odczytu podczas tworzenia konta magazynu, to jeśli dane staną się niedostępne w lokalizacji podstawowej, aplikacja może tymczasowo przełączyć się na kopię tylko do odczytu w lokalizacji pomocniczej. Aby można było odczytać dane pomocnicze, aplikacja musi być w stanie przełączać się między użyciem lokalizacji magazynu podstawowego i pomocniczego i mieć możliwość pracy w trybie ograniczonej funkcjonalności z danymi tylko do odczytu. Biblioteki klienta usługi Azure Storage umożliwiają zdefiniowanie zasad ponawiania, które mogą odczytywać z pomocniczego magazynu w przypadku niepowodzenia odczytu z magazynu podstawowego. Aplikacja musi również pamiętać, że dane w lokalizacji pomocniczej są ostatecznie spójne. Aby uzyskać więcej informacji, zobacz wpis w blogu Opcje nadmiarowości usługi Azure Storage i Magazyn geograficznie nadmiarowy dostępu do odczytu.

Problemy z wydajnością

Wydajność aplikacji może być wartością subiektywną, zwłaszcza z punktu widzenia użytkownika. Dlatego należy mieć dostępne metryki linii bazowej, które ułatwiają wykrywanie problemów 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żna następnie użyć plików dziennika, aby znaleźć szczegółowe informacje, aby zdiagnozować i rozwiązać problem dalej.

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ę kliencka. Metryki magazynu rejestrują również liczbę różnych typów błędów z usług magazynu, takich jak NetworkError, ClientTimeoutError lub AuthorizationError. Metryki magazynu rejestrują tylko liczby różnych typów błędów, ale można uzyskać więcej szczegółowych informacji na temat poszczególnych żądań, sprawdzając dzienniki po stronie serwera, po stronie klienta i sieci. Zazwyczaj kod stanu HTTP zwrócony przez usługę magazynu daje wskazanie, dlaczego żądanie nie powiodło się.

Uwaga 16.

Należy pamiętać, że należy oczekiwać, że występują sporadyczne błędy: na przykład błędy spowodowane przejściowymi warunkami sieci lub błędami aplikacji.

Przydatne dla zrozumienia kodów stanu i błędów związanych z magazynem są następujące zasoby:

Problemy z emulatorem magazynu

Zestaw Azure SDK zawiera emulator magazynu, który można uruchomić na stacji roboczej dewelopera. Ten emulator symuluje większość zachowania usług Azure Storage i jest przydatny podczas programowania 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 napotkane przy użyciu emulatora magazynu.

Narzędzia rejestrowania magazynu

Rejestrowanie magazynu zapewnia 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 związanych z operacjami magazynu wykonywanymi przez aplikację. Aby uzyskać więcej informacji, zobacz Client-side Logging with the .NET Storage Client Library (Logowanie po stronie klienta przy użyciu biblioteki klienckiej usługi .NET Storage).

Uwaga 16.

W niektórych 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źć 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 rejestrowania sieci

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

  • Fiddler to bezpłatny serwer proxy debugowania internetowego, który umożliwia badanie nagłówków i danych ładunku komunikatów http i HTTPS oraz odpowiedzi. Aby uzyskać więcej informacji, zobacz Dodatek 1: Używanie programu Fiddler do przechwytywania ruchu HTTP i HTTPS.
  • Microsoft Network Monitor (Netmon) i Wireshark to bezpłatne analizatory protokołów sieciowych, które umożliwiają wyświetlanie szczegółowych informacji o pakiecie dla szerokiego zakresu protokołów sieciowych. Aby uzyskać więcej informacji na temat programu Wireshark, zobacz Dodatek 2: Używanie programu Wireshark do przechwytywania ruchu sieciowego.
  • Jeśli chcesz wykonać podstawowy test łączności, aby sprawdzić, czy maszyna kliencka może połączyć się z usługą Azure Storage za pośrednictwem sieci, nie można tego zrobić przy użyciu standardowego narzędzia ping na kliencie. Można jednak użyć narzędzia tcping, aby sprawdzić łączność.

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 mogą zapewnić te narzędzia rejestrowania sieci. 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żliwi sprawdzenie, jak aplikacja kliencka ponawia próbę operacji magazynowania. Analizatory protokołów, takie jak Wireshark, działają na poziomie pakietów, 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 zacząć szukać w plikach dziennika, aby uzyskać szczegółowe informacje ułatwiające rozwiązanie problemu.

Korelowanie danych dziennika

Podczas przeglądania dzienników z aplikacji klienckich, śladów sieci i rejestrowania magazynu po stronie serwera kluczowe znaczenie ma możliwość korelowania żądań 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 przydatnym polem używanym do korelowania wpisów w różnych dziennikach. Czasami jednak 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 usługi Storage 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 odnoszącego się do żądania.
  • W śladzie sieciowym, takim jak przechwycony przez program Fiddler, identyfikator żądania klienta jest widoczny w komunikatach żądania 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 16.

Istnieje możliwość, aby wiele żądań współużytkować ten sam identyfikator żądania klienta, ponieważ klient może przypisać tę wartość (chociaż biblioteka klienta magazynu przypisuje nową wartość automatycznie). Gdy klient ponawia próbę, wszystkie próby współużytkowania tego samego identyfikatora żądania klienta. W przypadku partii wysłanej z klienta partia ma jeden identyfikator żą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 śladzie sieciowym, 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 16.

Usługa magazynu zawsze przypisuje unikatowy identyfikator żądania serwera do każdego odbieranego żądania, więc każda ponowna próba 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();
    }
}

Znaczniki czasu

Możesz również użyć sygnatur czasowych, aby zlokalizować powiązane wpisy dziennika, ale należy zachować ostrożność podczas dowolnego niesymetryczności zegara między klientem a serwerem, który może istnieć. Wyszukaj plus lub minus 15 minut dla pasujących wpisów po stronie serwera na podstawie znacznika czasu na kliencie. Pamiętaj, że metadane obiektów blob dla obiektów blob zawierających metryki wskazują zakres czasu metryk przechowywanych w obiekcie blob. Ten zakres czasu jest przydatny, jeśli masz wiele obiektów blob metryk dla tej samej minuty lub godziny.

Przewodnik rozwiązywania problemów

Ta sekcja pomoże Ci w diagnozowaniu i rozwiązywaniu niektórych typowych problemów, które mogą wystąpić w przypadku korzystania z usług Azure Storage. Skorzystaj z poniższej listy, aby znaleźć informacje istotne dla konkretnego problemu.

Rozwiązywanie problemów z drzewem decyzyjnym

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

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

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

Metryki pokazują niską wartość PercentSuccess lub wpisy dziennika analizy 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 instalowaniem zestawu Azure SDK dla platformy .NET.

Masz inny problem z usługą magazynu.

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

Poniższa ilustracja z narzędzia do monitorowania witryny Azure Portal przedstawia przykład, w którym średniaE2ELatency jest znacznie wyższa niż averageServerLatency.

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

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

Uwaga 16.

Można również wyświetlić dane dziennika E2ELatency i ServerLatency dla poszczególnych operacji magazynowania.

Badanie problemów z wydajnością klienta

Możliwe przyczyny powolnej reakcji klienta 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, aby był bardziej wydajny (na przykład za pomocą asynchronicznych wywołań 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ż spowodować wysoką wartość AverageE2ELatency w porównaniu do averageServerLatency. Aby uzyskać więcej informacji, zobacz Nagle's Algorithm is Not Friendly to Small Requests (Algorytm Nagle 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 wywołań do usług tabeli 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 zobaczyć, ile żądań przesyła aplikacja kliencka i sprawdź, czy jest ogólnie dostępna. Wąskie gardła wydajności związane z platformą NET 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óźnieniami sieci

Zazwyczaj duże opóźnienia spowodowane przez sieć są spowodowane przejściowymi warunkami. 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 używania programu Wireshark do rozwiązywania problemów z siecią, zobacz Dodatek 2: Używanie programu Wireshark do przechwytywania ruchu sieciowego.

Metryki wskazują niską wartość AverageE2ELatency i niską wartość AverageServerLatency, ale na kliencie występuje 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 przechodzą do usługi obiektów blob.

Jedną z możliwych przyczyn opóźnienia wysyłania żądań przez klienta jest to, że istnieje 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. Jeśli wystąpi wiele ponownych prób, zobaczysz wiele operacji z tym samym identyfikatorem żądania klienta, ale z różnymi identyfikatorami żądań serwera.
  • Sprawdź dzienniki klienta. Pełne rejestrowanie oznacza, że wystąpiła ponowna próba.
  • Debuguj kod i sprawdź właściwości obiektu skojarzonego OperationContext z żądaniem. Jeśli operacja została ponowiona, RequestResults właściwość 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ładowy kod w sekcji Identyfikator żądania serwera.

Jeśli nie ma problemów z klientem, 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 używania programu Wireshark do rozwiązywania problemów z siecią, zobacz Dodatek 2: Używanie programu Wireshark do przechwytywania ruchu sieciowego.

Metryki wskazują wysoką wartość AverageServerLatency

W przypadku wysokiej wartości AverageServerLatency dla żądań pobrania obiektów blob należy użyć dzienników rejestrowania usługi Storage, 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ć rozmiar bloku używany przez klienta (na przykład bloki o rozmiarze mniejszym niż 64 K mogą powodować obciążenie, chyba że odczyty znajdują się również w mniej niż 64 K fragmentów) 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 Metrics show an increase in PercentTimeoutError (Metryki pokazują wzrost wartości PercentTimeoutError).

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

Wysokie wartości AverageServerLatency mogą być również objawem źle zaprojektowanych tabel lub zapytań, które powodują operacje skanowania lub obejmują antywzorzec dołączania/poprzedzania. Aby uzyskać więcej informacji, zobacz Metryki pokazują wzrost wartości PercentThrottlingError.

Uwaga 16.

Kompleksową listę kontrolną wydajności można znaleźć tutaj: Lista kontrolna wydajności i skalowalności usługi Microsoft Azure Storage.

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, w którym będzie dostępny odczyt z kolejki, wykonaj następujące kroki, aby zdiagnozować problem:

  • Sprawdź, czy aplikacja pomyślnie dodaje komunikaty do kolejki. Sprawdź, czy aplikacja nie ponawia próby AddMessage metody kilka razy przed powodzeniem. Dzienniki biblioteki klienta usługi Storage będą pokazywać wszelkie powtarzające się ponawianie operacji magazynowania.
  • Sprawdź, czy między rolą procesu roboczego nie ma niesymetryczności zegara, która dodaje komunikat do kolejki i rolę procesu roboczego, która odczytuje komunikat z kolejki. Niesymetryczność zegara sprawia, że wygląda na to, że istnieje opóźnienie przetwarzania.
  • Sprawdź, czy rola procesu roboczego, która odczytuje komunikaty z kolejki, kończy się niepowodzeniem. Jeśli klient kolejki wywołuje GetMessage metodę, ale nie odpowie potwierdzeniem, komunikat pozostanie niewidoczny w kolejce do momentu invisibilityTimeout wygaśnięcia okresu. W tym momencie komunikat stanie się ponownie dostępny do przetworzenia.
  • Sprawdź, czy długość kolejki rośnie wraz z upływem czasu. Taka sytuacja może wystąpić, jeśli nie masz wystarczającej liczby procesów roboczych, aby przetworzyć wszystkie komunikaty, które inni pracownicy umieszczają w kolejce. Sprawdź również metryki, aby sprawdzić, czy żądania usuwania kończą się niepowodzeniem, oraz liczba komunikatów w kolejce, co może wskazywać na powtarzające się nieudane próby usunięcia komunikatu.
  • Sprawdź dzienniki rejestrowania magazynu dla wszystkich operacji kolejki, które mają wyższe niż oczekiwano wartości E2ELatency i ServerLatency w dłuższym okresie niż zwykle.

Metryki wskazują wzrost wartości PercentThrottlingError

Błędy ograniczania występują w przypadku przekroczenia wartości docelowych skalowalności usługi magazynu. Ograniczenie usługi magazynu w celu zapewnienia, że żaden pojedynczy klient lub dzierżawa nie może korzystać z usługi kosztem innych. Aby uzyskać więcej informacji, zobacz Cele skalowalności i wydajności dla kont magazynu w warstwie Standardowa, aby uzyskać szczegółowe informacje na temat celów skalowalności dla kont magazynu i celów wydajności dla partycji w ramach kont magazynu.

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

Wzrost wartości PercentThrottlingError często występuje w tym samym czasie co wzrost liczby żądań magazynu lub podczas początkowego testowania obciążenia aplikacji. Może to również manifestować się w kliencie jako "503 Server Busy" lub "500 Operation Timeout" komunikaty o stanie HTTP z operacji magazynu.

Przejściowy wzrost percentThrottlingError

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

Uwaga 16.

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

Stały wzrost błędu PercentThrottlingError

Jeśli widzisz spójnie wysoką wartość dla wartości PercentThrottlingError po stałym wzroście woluminów transakcji lub podczas przeprowadzania początkowych testów obciążeniowych w aplikacji, musisz ocenić, w jaki sposób 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 liczy się jako pojedyncza partycja), rozważ użycie dodatkowych kolejek w celu rozłożenia transakcji na wiele partycji. Jeśli w tabeli występują błędy ograniczania przepustowości, 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 wstępny/dołączany antywzór, w którym wybierasz datę jako klucz partycji, a następnie wszystkie dane w danym dniu są zapisywane w jednej partycji: pod obciążeniem 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 złagodzenia wzorca żądań.

Jeśli transakcje są dystrybuowane na wiele partycji, nadal należy pamiętać o limitach skalowalności ustawionych dla konta magazynu. Jeśli na przykład użyto dziesięciu kolejek, każde przetwarzanie maksymalnie 2000 1 KB komunikatów na sekundę będzie wynosić całkowity limit 20 000 komunikatów na sekundę dla konta magazynu. Jeśli musisz przetworzyć ponad 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, być może wcześniej będzie ograniczona.

Nieefektywny projekt zapytań może również spowodować osiągnięcie limitów skalowalności partycji tabeli. Na przykład zapytanie z filtrem, które wybiera tylko jeden procent jednostek w partycji, ale skanuje wszystkie jednostki w partycji, będzie musiał uzyskać dostęp do każdej jednostki. Każda odczyt jednostki będzie liczone do całkowitej liczby transakcji w tej partycji; w związku z tym można łatwo uzyskać dostęp do celów skalowalności.

Uwaga 16.

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

Metryki wskazują wzrost wartości PercentTimeoutError

Metryki pokazują wzrost wartości 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 16.

Błędy przekroczenia limitu czasu mogą zostać tymczasowo wyświetlone, ponieważ usługa 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 błędem 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 usługi Storage może ustawić limit czasu dla operacji przy użyciu ServerTimeout właściwości QueueRequestOptions klasy .

Przekroczenia limitu czasu serwera wskazują 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 identyfikujesz wszelkie skoki ruchu, które mogą powodować ten problem. 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 tym, że aplikacja osiąga limity skalowalności usługi, należy zgłosić problem z pomocą techniczną. W przypadku przekroczenia limitu czasu klienta musisz zdecydować, czy limit czasu jest ustawiony na odpowiednią wartość w kliencie i zmienić wartość limitu czasu ustawioną w kliencie lub zbadać, jak można poprawić wydajność operacji w usłudze magazynu, na przykład przez optymalizację zapytań tabeli lub zmniejszenie rozmiaru komunikatów.

Metryki wskazują 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 rozłączenie klienta przed upływem limitu czasu w usłudze magazynu. Zbadaj kod w kliencie, aby dowiedzieć się, dlaczego i kiedy klient rozłącza się z usługą magazynu. Możesz również użyć narzędzia Wireshark lub Tcping, aby zbadać problemy z łącznością sieciową od klienta. Te narzędzia są opisane w dołączaniach.

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łej sygnatury dostępu współdzielonego podczas wysyłania żądania magazynu (chociaż inne możliwe przyczyny to niedokładność 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 usługi Storage, która ilustruje ten problem:

Źródło Poziom szczegółowości Poziom szczegółowości Identyfikator żądania klienta Tekst operacji
Microsoft.Azure.Storage Informacja 3 85d077ab-... Starting operation with location Primary per location mode PrimaryOnly.
Microsoft.Azure.Storage Informacja 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 Informacja 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 Informacja 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 Informacja 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 Informacja 3 85d077ab -... The next location has been set to Primary, based on the location mode.
Microsoft.Azure.Storage Błąd 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 a usługą 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 sygnatury dostępu współdzielonego. Ponownie małe różnice zegarowe między hostem generującym sygnaturę dostępu współdzielonego a usługą magazynu mogą prowadzić do pozornie wygasającej sygnatury dostępu współdzielonego wcześniej niż oczekiwano.
  • 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 usługi Storage? Zalecamy, aby zawsze używać najnowszej wersji biblioteki klienta magazynu.
  • Jeśli ponownie wygenerujesz klucze dostępu do magazynu, wszelkie istniejące tokeny SAS mogą zostać unieważnione. Ten problem może wystąpić, jeśli generujesz tokeny SAS z długim czasem wygaśnięcia dla aplikacji klienckich do przechowywania w pamięci podręcznej.

Jeśli używasz biblioteki klienta usługi Storage do generowania tokenów SAS, możesz łatwo utworzyć prawidłowy token. Jeśli jednak używasz interfejsu API REST usługi Storage 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 otrzyma komunikat HTTP 404 (nie znaleziono) z serwera, oznacza to, że obiekt, którego klient próbował użyć (na przykład jednostki, tabeli, obiektu blob, kontenera lub kolejki) nie istnieje w usłudze magazynu. Istnieje kilka możliwych przyczyn tej sytuacji, 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 dzienniku 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 być w stanie znaleźć tabelę.

Możesz użyć dziennika po stronie klienta z biblioteki klienta magazynu, aby uzyskać bardziej szczegółowe informacje o tym, kiedy klient wysyła określone żądania do usługi magazynu.

Następujący 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 zawiera HEAD żądanie sprawdzenia istnienia kontenera.
e2d06d78... CreateIfNotExists metoda tworzenia kontenera obiektów blob. Pamiętaj, że ta operacja zawiera HEAD żądanie sprawdzające istnienie kontenera. Funkcja HEAD zwraca komunikat 404, ale kontynuuje.
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 metody UploadFromStream (de8b1c3c-...). To przeplatanie występuje, ponieważ aplikacja kliencka wywoła te metody asynchronicznie. Zmodyfikuj kod asynchroniczny w kliencie, aby upewnić się, że tworzy kontener przed podjęciem próby przekazania danych do obiektu blob w tym kontenerze. Najlepiej jest utworzyć wszystkie kontenery z wyprzedzeniem.

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

Jeśli aplikacja kliencka próbuje użyć klucza sygnatury dostępu współdzielonego, który nie zawiera niezbędnych uprawnień do operacji, usługa magazynu zwróci klientowi komunikat HTTP 404 (nie znaleziono). Jednocześnie w metrykach zobaczysz również wartość SASAuthorizationError inną niż zero.

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

Nazwa/nazwisko Wartość
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 Obiekt 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>

Sprawdź, dlaczego aplikacja kliencka próbuje wykonać operację, dla której nie udzielono 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ź następujące błędy języka JavaScript w przeglądarce:

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

Uwaga 16.

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 internetowa implementuje to samo ograniczenie zabezpieczeń zasad pochodzenia, które uniemożliwia stronie internetowej wywoływanie interfejsu API w innej domenie niż domena, z którą 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órej 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.

Poniższy przykładowy kod pokazuje, jak skonfigurować usługę obiektów blob, aby umożliwić uruchamianie kodu JavaScript w domenie firmy Contoso w celu uzyskania dostępu 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);

Błąd sieci

W niektórych okolicznościach utracone pakiety sieciowe mogą prowadzić do zwracania komunikatów HTTP 404 do klienta przez usługę magazynu. Na przykład gdy aplikacja kliencka usuwa jednostkę z usługi tabel, zobaczysz, że klient zgłasza wyjątek magazynu zgłaszający komunikat o stanie "HTTP 404 (Nie znaleziono)" z usługi tabeli. Podczas badania tabeli w usłudze table storage zobaczysz, że usługa usunęła jednostkę zgodnie z żądaniem.

Szczegóły wyjątku w kliencie obejmują identyfikator żądania (7e84f12d...) przypisany przez usługę tabeli dla żądania. Te informacje umożliwiają zlokalizowanie szczegółów żądania w dziennikach magazynu po stronie serwera, wyszukując w request-id-header kolumnie w pliku dziennika. Możesz również użyć metryk, aby określić, kiedy wystąpią błędy, a następnie przeszukać pliki dziennika na podstawie czasu zarejestrowania tego błędu przez metryki. Ten wpis dziennika pokazuje, że usunięcie 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 client-request-id kolumnie (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 to, że klient wysłał żądanie usunięcia jednostki do usługi tabeli, 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ł operację (przy użyciu tej samej client-request-idmetody ), a ta ponowna próba nie powiodła się, ponieważ jednostka została już usunięta.

Jeśli ten problem występuje często, należy zbadać, dlaczego klient nie odbiera 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ępnie natychmiast przy użyciu CreateIfNotExists tej samej nazwy kontenera obiektów blob. Każda operacja klienta powoduje wysłanie dwóch żądań do serwera, najpierw GetContainerProperties żądanie sprawdzenia, czy kontener istnieje, a następnie DeleteContainer żądanie lub CreateContainer .

Sygnatura czasowa Operacja Result 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 utworzy kontener obiektów blob przy użyciu tej samej nazwy: CreateIfNotExists metoda (identyfikator żądania klienta bc881924-...) ostatecznie zakończy się niepowodzeniem z powodu błędu HTTP 409 (konflikt). Gdy klient usuwa kontenery obiektów blob, tabele lub kolejki, przed ponownym udostępnieniem nazwy następuje krótki okres.

Aplikacja kliencka powinna używać unikatowych nazw kontenerów za każdym razem, gdy tworzy nowe kontenery, jeśli wzorzec usuń/utwórz ponownie jest typowy.

Metryki pokazują niską wartość PercentSuccess lub wpisy dziennika analizy mają operacje ze stanem transakcji ClientOtherErrors

Metryka PercentSuccess przechwytuje procent operacji zakończonych powodzeniem na podstawie kodu stanu HTTP. Operacje z kodami stanu 2XX zliczają się jako pomyślne, podczas gdy operacje z kodami stanu w zakresie 3XX, 4XX i 5XX są liczone jako nieudane i niższe wartości 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 dlatego nie mają wpływu na inne metryki, takie jak dostępność. Niektóre przykłady operacji, które są wykonywane pomyślnie, ale mogą spowodować niepowodzenie kodów stanu HTTP, to:

  • 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 (niezmodyfikowany 304), na przykład z operacji warunkowej, takiej jak gdy klient wysyła ETag wartość i nagłówek HTTP If-None-Match , aby zażądać 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 widzisz nagłe, nieoczekiwane zmiany użycia pojemności na koncie magazynu, możesz zbadać przyczyny, najpierw przeglądając metryki dostępności; na przykład zwiększenie liczby żądań usunięcia zakończonych niepowodzeniem może prowadzić do zwiększenia ilości magazynu obiektów blob używanych jako operacji oczyszczania specyficznych dla aplikacji, których można oczekiwać, że zwalnianie miejsca może nie działać zgodnie z oczekiwaniami (na przykład ponieważ tokeny SAS używane do zwalniania miejsca wygasły).

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

Emulator magazynu zwykle jest używany podczas programowania i testowania, aby uniknąć wymagania 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. Więcej informacji można znaleźć w temacie Use the Azure Storage Emulator for Development and Testing (Używanie emulatora usługi Azure Storage do programowania i testowania).

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

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

Testujesz aplikację, która używa biblioteki klienta magazynu względem lokalnego emulatora magazynu, a wywołania metody, takie jak CreateIfNotExists niepowodzenie, z komunikatem o błędzie "Wartość dla jednego z nagłówków HTTP nie jest w poprawnym 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.

Możesz użyć dzienników klienta biblioteki magazynu, aby wyświetlić wartość x-ms-version header wysyłania. Możesz również zobaczyć wartość parametru x-ms-version header , jeśli używasz programu Fiddler do śledzenia żądań z aplikacji klienckiej.

Ten scenariusz zwykle występuje, jeśli instalujesz i używasz najnowszej wersji biblioteki klienta magazynu bez aktualizowania emulatora magazynu. Należy zainstalować najnowszą wersję emulatora magazynu lub użyć magazynu w chmurze zamiast emulatora na potrzeby programowania i testowania.

Uruchomienie emulatora magazynu wymaga uprawnień administracyjnych

Podczas uruchamiania emulatora magazynu zostanie wyświetlony monit o podanie poświadczeń administratora. Dzieje się tak tylko podczas inicjowania emulatora magazynu po raz pierwszy. Po zainicjowaniu emulatora magazynu nie potrzebujesz uprawnień administracyjnych, aby uruchomić go ponownie.

Więcej informacji można znaleźć w temacie Use the Azure Storage Emulator for Development and Testing (Używanie emulatora usługi Azure Storage do programowania i testowania). Można również zainicjować emulator magazynu w programie Visual Studio, który będzie również wymagał uprawnień administracyjnych.

Występują problemy z instalowaniem 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 symulacji 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 problemu.

  • Sprawdź metryki, aby sprawdzić, czy nie ma żadnych zmian w oczekiwanym zachowaniu punktu odniesienia. Na podstawie metryk możesz określić, czy problem jest przejściowy, czy trwały, i które operacje magazynu mają wpływ na problem.
  • Możesz użyć informacji o metrykach, aby ułatwić wyszukiwanie danych dziennika po stronie serwera, aby uzyskać bardziej szczegółowe informacje na temat wszelkich występujących błędów. Te informacje mogą pomóc w rozwiązaniu problemu i rozwiązaniu go.
  • 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 usługi Storage, 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: Używanie programu Fiddler do przechwytywania ruchu HTTP i HTTPS.

Aby uzyskać więcej informacji na temat korzystania z programu Wireshark, zobacz Dodatek 2: Używanie programu Wireshark do przechwytywania ruchu sieciowego.

Dodatki

W dołączaniu 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 dołączaniach nie są objęte żadną umową pomocy technicznej, którą możesz mieć z platformą Microsoft Azure lub usługą Azure Storage. W związku z tym w ramach procesu oceny należy zbadać opcje licencjonowania i pomocy technicznej dostępne u dostawców tych narzędzi.

Dodatek 1: Przechwytywanie ruchu HTTP i HTTPS przy użyciu programu Fiddler

Fiddler to przydatne narzędzie do analizowania ruchu HTTP i HTTPS między aplikacją kliencką i usługą Azure Storage, której używasz.

Uwaga 16.

Program Fiddler może dekodować ruch HTTPS. Należy uważnie przeczytać dokumentację programu Fiddler, aby zrozumieć, jak to robi i jej wpływ na bezpieczeństwo.

Ten dodatek zawiera krótki przewodnik konfigurowania programu Fiddler w celu przechwytywania ruchu między maszyną lokalną, na której zainstalowano program Fiddler i usługi Azure Storage.

Po uruchomieniu programu Fiddler rozpocznie przechwytywanie ruchu HTTP i HTTPS na komputerze lokalnym. 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. Dzięki temu można zapisywać ruch w pliku Archiwum sesji. Możesz ponownie załadować archiwum sesji później do analizy lub wysłać je, jeśli zażądasz pomocy technicznej firmy Microsoft.

Aby ograniczyć ilość ruchu przechwyconego przez program Fiddler, możesz użyć filtrów skonfigurowanych na karcie Filtry . Poniższy zrzut ekranu przedstawia filtr, który przechwytuje tylko ruch wysyłany do punktu końcowego contosoemaildist.table.core.windows.net 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 przy użyciu programu Wireshark

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

Poniższa procedura przedstawia sposób przechwytywania szczegółowych informacji o pakiecie dla ruchu z komputera lokalnego, na którym zainstalowano program Wireshark do usługi tabeli 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 skonfiguruje program Wireshark do przechwytywania tylko pakietów wysyłanych do punktu końcowego usługi tabel 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 Filtr przechwytywania.

  5. Wybierz Start. Narzędzie Wireshark przechwytuje teraz wszystkie pakiety wysyłane do punktu końcowego usługi tabel lub z punktu końcowego usługi tabeli podczas korzystania z aplikacji klienckiej na komputerze lokalnym.

  6. Po zakończeniu wybierz pozycję Przechwyć zatrzymaj> w menu głównym.

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

Narzędzie WireShark wyróżni wszelkie błędy, które istnieją w oknie listy pakietów. Możesz również użyć okna Informacje ekspertów (wybierz pozycję Analizuj>informacje ekspertów), 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 w warstwie aplikacji, klikając prawym przyciskiem myszy dane TCP i wybierając pozycję Obserwuj strumień TCP. Jest to przydatne w przypadku przechwycenia zrzutu bez filtru przechwytywania. Aby uzyskać więcej informacji, zobacz Następujące strumienie TCP.

Zrzut ekranu przedstawiający sposób wyświetlania danych TCP w warstwie aplikacji.

Uwaga 16.

Aby uzyskać więcej informacji na temat korzystania z programu Wireshark, zobacz Wireshark Users Guide (Podręcznik użytkowników usługi Wireshark).

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

Wiele narzędzi umożliwia pobieranie danych metryk magazynu z usługi Azure Table Storage w formacie rozdzielanym, co ułatwia ładowanie danych do programu Excel w celu wyświetlania i analizowania. Rejestrowanie danych magazynu z usługi Azure Blob Storage jest już w formacie rozdzielanym, który można załadować do programu Excel. Należy jednak dodać odpowiednie nagłówki kolumn na podstawie informacji w analityka magazynu Format dziennika i schematu tabeli metryk analityka magazynu.

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 importu 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 umieszczania 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 wykonywać następujące czynności:

  • 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 testować adres URL co kilka minut z lokalizacji na całym świecie i poinformować Cię, czy występuje problem.
  • Szybko zdiagnozuj wszelkie problemy z wydajnością lub wyjątkami w usłudze internetowej. Sprawdź, czy procesor CPU lub inne zasoby są rozciągnięte, uzyskaj ślady stosu z wyjątków i łatwo przeszukiwanie śladów dzienników. Jeśli wydajność aplikacji spadnie poniżej dopuszczalnych limitów, firma Microsoft może wysłać Ci wiadomość e-mail. Można monitorować zarówno usługi internetowe .NET, jak i Java.

Więcej informacji można znaleźć w tematach 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 na temat platformy Azure.