Freigeben über

Überwachen, Diagnostizieren und Problembehandlung für Microsoft Azure Storage (klassisch)

  • Artikel

In diesem Leitfaden erfahren Sie, wie Sie Features wie Azure Storage Analytics, clientseitige Protokollierung in der Azure Storage-Clientbibliothek und andere Tools von Drittanbietern verwenden, um Probleme im Zusammenhang mit Azure Storage zu identifizieren, zu diagnostizieren und zu beheben.

Diagramm, das den Informationsfluss zwischen Clientanwendungen und Azure-Speicherdiensten zeigt.

Dieser Leitfaden soll in erster Linie von Entwicklern von Onlinedienste gelesen werden, die Azure Storage-Dienste verwenden, und IT-Experten, die für die Verwaltung solcher Onlinedienste verantwortlich sind. Die Ziele dieses Leitfadens sind:

  • Zur Aufrechterhaltung der Integrität und Leistung Ihrer Azure Storage-Konten.
  • Um Ihnen die erforderlichen Prozesse und Tools zur Verfügung zu stellen, mit denen Sie entscheiden können, ob ein Problem oder ein Problem in einer Anwendung mit Azure Storage zusammenhängt.
  • Hier erhalten Sie umsetzbare Anleitungen zum Beheben von Problemen im Zusammenhang mit Azure Storage.

Hinweis

Dieser Artikel basiert auf der Verwendung von Storage Analytics Metriken und Protokollen, die als klassische Metriken und Protokolle bezeichnet werden. Es wird empfohlen, Azure Storage-Metriken und -Protokolle in Azure Monitor anstelle von Storage Analytics Protokollen zu verwenden. Weitere Informationen finden Sie in den folgenden Artikeln:

Übersicht

Die Diagnose und Problembehandlung von Problemen in einer verteilten Anwendung, die in einer Cloudumgebung gehostet wird, kann komplexer sein als in herkömmlichen Umgebungen. Anwendungen können in einer PaaS- oder IaaS-Infrastruktur, lokal, auf einem mobilen Gerät oder in einer Kombination dieser Umgebungen bereitgestellt werden. In der Regel durchläuft der Netzwerkdatenverkehr Ihrer Anwendung öffentliche und private Netzwerke, und Ihre Anwendung kann zusätzlich zu anderen Datenspeichern wie relationalen Datenbanken und Dokumentdatenbanken mehrere Speichertechnologien wie Microsoft Azure Storage Tabellen, Blobs, Warteschlangen oder Dateien verwenden.

Um solche Anwendungen erfolgreich zu verwalten, sollten Sie sie proaktiv überwachen und verstehen, wie Sie alle Aspekte dieser Anwendungen und ihrer abhängigen Technologien diagnostizieren und behandeln können. Als Benutzer von Azure Storage-Diensten sollten Sie die von Ihrer Anwendung verwendeten Speicherdienste kontinuierlich auf unerwartete Verhaltensänderungen (z. B. langsamere Antwortzeiten als üblich) überwachen und die Protokollierung verwenden, um detailliertere Daten zu sammeln und ein Problem ausführlich zu analysieren. Die Diagnose Informationen, die Sie aus der Überwachung und Protokollierung erhalten, helfen Ihnen dabei, die Grundursache des Problems zu ermitteln, das bei Ihrer Anwendung aufgetreten ist. Anschließend können Sie das Problem beheben und die geeigneten Schritte zum Beheben des Problems festlegen. Azure Storage ist ein zentraler Azure-Dienst und ein wichtiger Bestandteil der meisten Lösungen, die Kunden in der Azure-Infrastruktur bereitstellen. Azure Storage bietet Funktionen zur Vereinfachung der Überwachung, Diagnose und Problembehandlung von Speicherproblemen in Ihren cloudbasierten Anwendungen.

Wie dieser Leitfaden organisiert ist

Im Abschnitt Überwachen Ihres Speicherdiensts wird beschrieben, wie Sie die Integrität und Leistung Ihrer Azure Storage-Dienste mithilfe von Azure Storage Analytics Metrics (Storage Metrics) überwachen.

Im Abschnitt Diagnose von Speicherproblemen wird beschrieben, wie Sie Probleme mithilfe der Azure Storage Analytics-Protokollierung (Speicherprotokollierung) diagnostizieren. Außerdem wird beschrieben, wie Die clientseitige Protokollierung mithilfe der Funktionen in einer der Clientbibliotheken wie der Speicherclientbibliothek für .NET oder dem Azure SDK für Java aktiviert wird.

Im Abschnitt End-to-End-Ablaufverfolgung wird beschrieben, wie Sie die in verschiedenen Protokolldateien und Metrikdaten enthaltenen Informationen korrelieren können.

Der Abschnitt Leitfaden zur Problembehandlung enthält Anleitungen zur Problembehandlung für einige der häufig auftretenden speicherbezogenen Probleme.

Der Abschnitt "Appendices " enthält Informationen zur Verwendung anderer Tools wie Wireshark und Netmon zum Analysieren von Netzwerkpaketdaten und Fiddler zum Analysieren von HTTP/HTTPS-Nachrichten.

Überwachen Ihres Speicherdiensts

Wenn Sie mit der Windows-Leistungsüberwachung vertraut sind, können Sie sich Speichermetriken als Eine Azure Storage-Entsprechung von Windows Leistungsmonitor-Indikatoren vorstellen. Unter Speichermetriken finden Sie einen umfassenden Satz von Metriken (Indikatoren in Windows Leistungsmonitor Terminologie), z. B. Dienstverfügbarkeit, Gesamtanzahl von Dienstanforderungen oder Prozentsatz der erfolgreichen Serviceanforderungen. Eine vollständige Liste der verfügbaren Metriken finden Sie unter Storage Analytics Metriktabellenschema. Sie können angeben, ob der Speicherdienst stündlich oder minütlich Metriken sammeln und aggregieren soll. Weitere Informationen zum Aktivieren von Metriken und überwachen Ihrer Speicherkonten finden Sie unter Aktivieren von Speichermetriken und Anzeigen von Metrikdaten.

Sie können auswählen, welche Stundenmetriken Sie im Azure-Portal anzeigen möchten, und Regeln konfigurieren, die Administratoren per E-Mail benachrichtigen, wenn eine Stündliche Metrik einen bestimmten Schwellenwert überschreitet. Weitere Informationen finden Sie unter Empfangen von Warnungsbenachrichtigungen.

Wir empfehlen Ihnen, Azure Monitor für Storage (Vorschau) zu lesen. Es ist ein Feature von Azure Monitor, das eine umfassende Überwachung Ihrer Azure Storage-Konten bietet, indem eine einheitliche Ansicht der Leistung, Kapazität und Verfügbarkeit Ihrer Azure Storage-Dienste bereitgestellt wird. Es ist nicht erforderlich, dass Sie etwas aktivieren oder konfigurieren, und Sie können diese Metriken sofort aus den vordefinierten interaktiven Diagrammen und anderen enthaltenen Visualisierungen anzeigen.

Der Speicherdienst versucht sein Bestes, Um Metriken zu sammeln, zeichnet aber möglicherweise nicht jeden Speichervorgang auf.

Im Azure-Portal können Sie Metriken wie Verfügbarkeit, Gesamtanforderungen und durchschnittliche Latenzzahlen für ein Speicherkonto anzeigen. Außerdem wurde eine Benachrichtigungsregel eingerichtet, um einen Administrator zu benachrichtigen, wenn die Verfügbarkeit unter eine bestimmte Ebene fällt. Aus der Anzeige dieser Daten besteht ein möglicher Bereich für die Untersuchung darin, dass der Prozentsatz des Tabellendiensterfolgs unter 100 % liegt (weitere Informationen finden Sie im Abschnitt Metriken zeigen niedrige Prozentwerte oder Analyseprotokolleinträge weisen Vorgänge mit Transaktionsvorgängen status von ClientOtherErrors auf).

Sie sollten Ihre Azure-Anwendungen kontinuierlich überwachen, um sicherzustellen, dass sie fehlerfrei sind und wie erwartet funktionieren:

  • Einrichten einiger Basismetriken für die Anwendung, mit denen Sie aktuelle Daten vergleichen und wesentliche Änderungen am Verhalten von Azure Storage und Ihrer Anwendung identifizieren können. Die Werte Ihrer Baselinemetriken sind in vielen Fällen anwendungsspezifisch, und Sie sollten sie beim Testen der Leistung Ihrer Anwendung festlegen.
  • Aufzeichnen von Minutenmetriken und deren Verwendung zur aktiven Überwachung auf unerwartete Fehler und Anomalien, z. B. Spitzen bei der Fehleranzahl oder Anforderungsraten.
  • Aufzeichnen von stundenbasierten Metriken und Deren Verwendung zum Überwachen von Durchschnittswerten, z. B. durchschnittliche Fehleranzahl und Anforderungsraten.
  • Untersuchen potenzieller Probleme mit Diagnose Tools, wie weiter unten im Abschnitt Diagnose von Speicherproblemen erläutert.

Die Diagramme in der folgenden Abbildung veranschaulichen, wie der Mittelwert, der für stündliche Metriken auftritt, Aktivitätsspitzen ausblenden kann. Die Stundenmetriken scheinen eine konstante Rate von Anforderungen zu zeigen, während die Minutenmetriken die Schwankungen aufdecken, die tatsächlich stattfinden.

Diagramme, die zeigen, wie die Mittelwertung, die für Stündliche Metriken auftritt, Aktivitätsspitzen ausblenden kann.

Im restlichen Teil dieses Abschnitts wird beschrieben, welche Metriken Sie überwachen sollten und warum.

Überwachen der Dienstintegrität

Sie können die Azure-Portal verwenden, um die Integrität des Speicherdiensts (und anderer Azure-Dienste) in allen Azure-Regionen auf der ganzen Welt anzuzeigen. Mithilfe der Überwachung können Sie sofort erkennen, ob sich ein Problem außerhalb Ihrer Kontrolle auf den Speicherdienst in der Region auswirkt, die Sie für Ihre Anwendung verwenden.

Die Azure-Portal kann auch Benachrichtigungen zu Vorfällen bereitstellen, die sich auf die verschiedenen Azure-Dienste auswirken.

Hinweis

Diese Informationen waren zuvor zusammen mit Verlaufsdaten im Azure-Dienstdashboard verfügbar. Weitere Informationen zu Application Insights für Azure DevOps finden Sie unter Anhang 5: Überwachen mit Application Insights für Azure DevOps.

Überwachen der Kapazität

Speichermetriken speichern nur Kapazitätsmetriken für den Blobdienst, da Blobs in der Regel den größten Anteil der gespeicherten Daten umfassen (zum Zeitpunkt des Schreibens ist es nicht möglich, Speichermetriken zum Überwachen der Kapazität Ihrer Tabellen und Warteschlangen zu verwenden). Sie finden diese Daten in der $MetricsCapacityBlob Tabelle, wenn Sie die Überwachung für den Blobdienst aktiviert haben. Speichermetriken zeichnet diese Daten einmal pro Tag auf, und Sie können den Wert von RowKey verwenden, um zu bestimmen, ob die Zeile eine Entität enthält, die sich auf Benutzerdaten (Wert data) oder Analysedaten (Wert analytics) bezieht. Jede gespeicherte Entität enthält Informationen zur Menge des verwendeten Speichers (Capacity gemessen in Bytes) und zur aktuellen Anzahl von Containern (ContainerCount) und Blobs (ObjectCount), die im Speicherkonto verwendet werden. Weitere Informationen zu den in der $MetricsCapacityBlob Tabelle gespeicherten Kapazitätsmetriken finden Sie unter Storage Analytics Metriktabellenschema.

Hinweis

Sie sollten diese Werte überwachen, um frühzeitig darauf hinzuweisen, dass Sie sich den Kapazitätsgrenzen Ihres Speicherkontos nähern. Im Azure-Portal können Sie Warnungsregeln hinzufügen, um Sie zu benachrichtigen, wenn die aggregierte Speichernutzung die von Ihnen angegebenen Schwellenwerte überschreitet oder unterschreitet.

Informationen zum Schätzen der Größe verschiedener Speicherobjekte wie Blobs finden Sie im Blogbeitrag Grundlegendes zur Azure Storage-Abrechnung – Bandbreite, Transaktionen und Kapazität.

Überwachen der Verfügbarkeit

Sie sollten die Verfügbarkeit der Speicherdienste in Ihrem Speicherkonto überwachen, indem Sie den Wert in der Availability Spalte in den Stunden- oder Minutenmetrikentabellen überwachen – $MetricsHourPrimaryTransactionsBlob, $MetricsHourPrimaryTransactionsTable, $MetricsHourPrimaryTransactionsQueue, $MetricsMinutePrimaryTransactionsBlob, $MetricsMinutePrimaryTransactionsTable, $MetricsMinutePrimaryTransactionsQueue, $MetricsCapacityBlob, . Die Availability Spalte enthält einen Prozentwert, der die Verfügbarkeit des Diensts oder des API-Vorgangs angibt, der durch die Zeile dargestellt wird (zeigt an RowKey , ob die Zeile Metriken für den Dienst als Ganzes oder für einen bestimmten API-Vorgang enthält).

Jeder Wert unter 100 % gibt an, dass einige Speicheranforderungen fehlschlagen. Sie können sehen, warum sie fehlschlagen, indem Sie die anderen Spalten in den Metrikdaten untersuchen, die die Anzahl der Anforderungen mit unterschiedlichen Fehlertypen anzeigen, z. B. ServerTimeoutError. Sie sollten davon ausgehen, Availability dass vorübergehend unter 100 % fallen, z. B. vorübergehende Servertimeouts, während der Dienst Partitionen zu einem besseren Lastenausgleich für Anforderungen verschiebt. Die Wiederholungslogik in Ihrer Clientanwendung sollte solche zeitweiligen Bedingungen verarbeiten. Der Artikel Storage Analytics Protokollierte Vorgänge und Statusmeldungen listet die Transaktionstypen auf, die Storage-Metriken in die Availability Berechnung einbezieht.

Im Azure-Portal können Sie Warnungsregeln hinzufügen, um Sie zu benachrichtigen, wenn Availability für einen Dienst ein von Ihnen angegebener Schwellenwert unterschritten wird.

Im Abschnitt "Leitfaden zur Problembehandlung" dieses Handbuchs werden einige allgemeine Speicherdienstprobleme im Zusammenhang mit der Verfügbarkeit beschrieben.

Überwachen der Leistung

Um die Leistung der Speicherdienste zu überwachen, können Sie die folgenden Metriken aus den Metriktabellen für Stunden und Minuten verwenden.

  • Die Werte in den AverageE2ELatency Spalten und AverageServerLatency zeigen die durchschnittliche Zeit an, die der Speicherdienst oder API-Vorgangstyp für die Verarbeitung von Anforderungen in Anspruch nimmt. AverageE2ELatency ist ein Maß für die End-to-End-Latenz, das die Zeit einschließt, die zum Lesen der Anforderung und zum Senden der Antwort erforderlich ist, zusätzlich zu der Zeit, die für die Verarbeitung der Anforderung erforderlich ist (umfasst daher die Netzwerklatenz, sobald die Anforderung den Speicherdienst erreicht hat); AverageServerLatency ist ein Maß für die Verarbeitungszeit und schließt daher jede Netzwerklatenz im Zusammenhang mit der Kommunikation mit dem Client aus. Im Abschnitt Metriken mit hoher AverageE2ELatency und niedriger AverageServerLatency weiter unten in diesem Leitfaden finden Sie eine Erläuterung, warum es einen signifikanten Unterschied zwischen diesen beiden Werten geben könnte.
  • Die Werte in den TotalIngress Spalten und TotalEgress zeigen die Gesamtmenge der Daten in Bytes an, die in Ihren Speicherdienst ein- und ausgehend werden oder über einen bestimmten API-Vorgangstyp.
  • Die Werte in der TotalRequests Spalte zeigen die Gesamtzahl der Anforderungen an, die der Speicherdienst des API-Vorgangs empfängt. TotalRequests ist die Gesamtanzahl der Anforderungen, die der Speicherdienst empfängt.

In der Regel überwachen Sie unerwartete Änderungen an einem dieser Werte, da dies darauf hindeutet, dass ein Problem vorliegt, das untersucht werden muss.

Im Azure-Portal können Sie Warnungsregeln hinzufügen, um Sie zu benachrichtigen, wenn Leistungsmetriken für diesen Dienst einen von Ihnen angegebenen Schwellenwert unter- oder überschreiten.

Im Abschnitt "Leitfaden zur Problembehandlung" dieses Handbuchs werden einige allgemeine Speicherdienstprobleme im Zusammenhang mit der Leistung beschrieben.

Diagnostizieren von Speicherproblemen

Es gibt eine Reihe von Möglichkeiten, wie Sie auf ein Problem in Ihrer Anwendung aufmerksam werden können, einschließlich:

  • Ein schwerwiegender Fehler, der dazu führt, dass die Anwendung abstürzt oder nicht mehr funktioniert.
  • Wesentliche Änderungen gegenüber Baselinewerten in den Metriken, die Sie überwachen, wie im vorherigen Abschnitt Überwachen Ihres Speicherdiensts beschrieben.
  • Berichte von Benutzern Ihrer Anwendung, dass ein bestimmter Vorgang nicht wie erwartet abgeschlossen wurde oder dass ein Feature nicht funktioniert.
  • In Ihrer Anwendung generierte Fehler, die in Protokolldateien oder über eine andere Benachrichtigungsmethode angezeigt werden.

In der Regel fallen Probleme im Zusammenhang mit Azure-Speicherdiensten in eine von vier allgemeinen Kategorien:

  • Ihre Anwendung weist ein Leistungsproblem auf, das entweder von Ihren Benutzern gemeldet oder durch Änderungen in den Leistungsmetriken aufgedeckt wird.
  • Es gibt ein Problem mit der Azure Storage-Infrastruktur in einer oder mehreren Regionen.
  • Ihre Anwendung tritt auf einen Fehler auf, der entweder von Ihren Benutzern gemeldet oder durch eine Erhöhung einer der von Ihnen überwachten Fehleranzahlmetriken angezeigt wird.
  • Während der Entwicklung und tests verwenden Sie möglicherweise den lokalen Speicher-Emulator. Möglicherweise treten einige Probleme auf, die sich speziell auf die Verwendung des Speicheremulators beziehen.

In den folgenden Abschnitten werden die Schritte beschrieben, die Sie ausführen sollten, um Probleme in jeder dieser vier Kategorien zu diagnostizieren und zu beheben. Im Abschnitt Leitfaden zur Problembehandlung weiter unten in diesem Handbuch finden Sie ausführlichere Informationen zu einigen häufig auftretenden Problemen.

Dienststatus Probleme

Dienststatus Probleme liegen in der Regel außerhalb Ihrer Kontrolle. Die Azure-Portal enthält Informationen zu allen laufenden Problemen mit Azure-Diensten, einschließlich Speicherdiensten. Wenn Sie sich beim Erstellen Ihres Speicherkontos für Read-Access Geo-Redundant Storage entschieden haben, kann Ihre Anwendung vorübergehend zur schreibgeschützten Kopie am sekundären Speicherort wechseln, wenn Ihre Daten am primären Standort nicht mehr verfügbar sind. Um aus dem sekundären Speicher lesen zu können, muss Ihre Anwendung zwischen der Verwendung des primären und sekundären Speicherorts wechseln und in einem modus mit eingeschränkter Funktionalität mit schreibgeschützten Daten arbeiten können. Mit den Azure Storage-Clientbibliotheken können Sie eine Wiederholungsrichtlinie definieren, die Lesevorgänge aus sekundärem Speicher für den Fall eines Fehlers beim Lesen aus dem primären Speicher ermöglicht. Ihre Anwendung muss sich auch darüber im Klaren sein, dass die Daten am sekundären Standort letztendlich konsistent sind. Weitere Informationen finden Sie im Blogbeitrag Azure Storage-Redundanzoptionen und Georedundanter Speicher mit Lesezugriff.

Leistungsprobleme

Die Leistung einer Anwendung kann subjektiv sein, insbesondere aus Benutzersicht. Daher ist es wichtig, dass Baselinemetriken verfügbar sind, damit Sie ermitteln können, wo ein Leistungsproblem vorliegt. Aus Sicht der Clientanwendung können sich viele Faktoren auf die Leistung eines Azure-Speicherdiensts auswirken. Diese Faktoren können im Speicherdienst, auf dem Client oder in der Netzwerkinfrastruktur ausgeführt werden. Daher ist es wichtig, eine Strategie zu haben, um den Ursprung des Leistungsproblems zu identifizieren.

Nachdem Sie den wahrscheinlichen Speicherort der Ursache des Leistungsproblems anhand der Metriken ermittelt haben, können Sie die Protokolldateien verwenden, um detaillierte Informationen zu finden, um das Problem weiter zu diagnostizieren und zu beheben.

Im Abschnitt Leitfaden zur Problembehandlung weiter unten in diesem Handbuch finden Sie weitere Informationen zu einigen häufig auftretenden leistungsbezogenen Problemen.

Diagnostizieren von Fehlern

Benutzer Ihrer Anwendung können Sie über Von der Clientanwendung gemeldete Fehler benachrichtigen. Speichermetriken zeichnet auch die Anzahl verschiedener Fehlertypen ihrer Speicherdienste auf, z. B. NetworkError, ClientTimeoutError oder AuthorizationError. Während Speichermetriken nur die Anzahl verschiedener Fehlertypen aufzeichnet, können Sie weitere Details zu einzelnen Anforderungen abrufen, indem Sie serverseitige, clientseitige und Netzwerkprotokolle untersuchen. In der Regel gibt der vom Speicherdienst zurückgegebene HTTP-status Code einen Hinweis darauf, warum die Anforderung fehlgeschlagen ist.

Hinweis

Denken Sie daran, dass Sie einige zeitweilige Fehler erwarten sollten, z. B. Fehler aufgrund vorübergehender Netzwerkbedingungen oder Anwendungsfehler.

Die folgenden Ressourcen sind hilfreich, um speicherbezogene status und Fehlercodes zu verstehen:

Probleme mit dem Speicher-Emulator

Das Azure SDK enthält einen Speicheremulator, den Sie auf einer Entwicklungsarbeitsstation ausführen können. Dieser Emulator simuliert den Großteil des Verhaltens der Azure-Speicherdienste und ist während der Entwicklung und Tests nützlich, sodass Sie Anwendungen ausführen können, die Azure-Speicherdienste verwenden, ohne dass ein Azure-Abonnement und ein Azure-Speicherkonto erforderlich sind.

Im Abschnitt "Leitfaden zur Problembehandlung " dieses Handbuchs werden einige häufige Probleme beschrieben, die bei der Verwendung des Speicheremulators auftreten.

Speicherprotokollierungstools

Die Speicherprotokollierung ermöglicht die serverseitige Protokollierung von Speicheranforderungen in Ihrem Azure-Speicherkonto. Weitere Informationen zum Aktivieren der serverseitigen Protokollierung und zum Zugreifen auf die Protokolldaten finden Sie unter Aktivieren der Speicherprotokollierung und Zugreifen auf Protokolldaten.

Mit der Speicherclientbibliothek für .NET können Sie clientseitige Protokolldaten sammeln, die sich auf Speichervorgänge beziehen, die von Ihrer Anwendung ausgeführt werden. Weitere Informationen finden Sie unter Clientseitige Protokollierung mit der .NET-Speicherclientbibliothek.

Hinweis

Unter bestimmten Umständen (z. B. SAS-Autorisierungsfehlern) kann ein Benutzer einen Fehler melden, für den Sie keine Anforderungsdaten in den serverseitigen Speicherprotokollen finden können. Sie können die Protokollierungsfunktionen der Speicherclientbibliothek verwenden, um zu untersuchen, ob die Ursache des Problems auf dem Client liegt, oder sie können Netzwerküberwachungstools verwenden, um das Netzwerk zu untersuchen.

Verwenden von Netzwerkprotokollierungstools

Sie können den Datenverkehr zwischen Client und Server erfassen, um detaillierte Informationen zu den Daten bereitzustellen, die Client und Server austauschen, sowie zu den zugrunde liegenden Netzwerkbedingungen. Zu den nützlichen Tools für die Netzwerkprotokollierung gehören:

In vielen Fällen reichen die Protokolldaten aus der Speicherprotokollierung und der Speicherclientbibliothek aus, um ein Problem zu diagnostizieren. In einigen Szenarien benötigen Sie jedoch möglicherweise die detaillierteren Informationen, die diese Netzwerkprotokollierungstools bereitstellen können. Mithilfe von Fiddler zum Anzeigen von HTTP- und HTTPS-Nachrichten können Sie beispielsweise Header- und Nutzlastdaten anzeigen, die an und von den Speicherdiensten gesendet werden, sodass Sie untersuchen können, wie eine Clientanwendung Speichervorgänge wiederholt. Protokollanalysetools wie Wireshark arbeiten auf Paketebene, sodass Sie TCP-Daten anzeigen können, sodass Sie verlorene Pakete und Konnektivitätsprobleme beheben können.

End-to-End-Ablaufverfolgung

Die End-to-End-Ablaufverfolgung mit einer Vielzahl von Protokolldateien ist eine nützliche Technik zum Untersuchen potenzieller Probleme. Sie können die Datums-/Uhrzeitinformationen aus Ihren Metrikdaten verwenden, um anzugeben, wo Sie in den Protokolldateien nach detaillierten Informationen suchen müssen, die Ihnen bei der Problembehandlung helfen.

Korrelieren von Protokolldaten

Beim Anzeigen von Protokollen von Clientanwendungen, Netzwerkablaufverfolgungen und serverseitiger Speicherprotokollierung ist es wichtig, Anforderungen über die verschiedenen Protokolldateien hinweg korrelieren zu können. Die Protokolldateien enthalten eine Reihe verschiedener Felder, die als Korrelationsbezeichner nützlich sind. Die Clientanforderungs-ID ist das nützlichste Feld, das zum Korrelieren von Einträgen in den verschiedenen Protokollen verwendet werden kann. Manchmal kann es jedoch hilfreich sein, entweder die Serveranforderungs-ID oder Zeitstempel zu verwenden. In den folgenden Abschnitten finden Sie weitere Informationen zu diesen Optionen.

Clientanforderungs-ID

Die Speicherclientbibliothek generiert automatisch eine eindeutige Clientanforderungs-ID für jede Anforderung.

  • Im clientseitigen Protokoll, das von der Speicherclientbibliothek erstellt wird, wird die Clientanforderungs-ID im Client Request ID Feld jedes Protokolleintrags angezeigt, der sich auf die Anforderung bezieht.
  • In einer Netzwerkablaufverfolgung, z. B. einer, die von Fiddler erfasst wird, ist die Clientanforderungs-ID in Anforderungsnachrichten als x-ms-client-request-id HTTP-Headerwert sichtbar.
  • Im serverseitigen Speicherprotokoll wird die Clientanforderungs-ID in der Spalte Clientanforderungs-ID angezeigt.

Hinweis

Es ist möglich, dass mehrere Anforderungen dieselbe Clientanforderungs-ID verwenden, da der Client diesen Wert zuweisen kann (obwohl die Speicherclientbibliothek automatisch einen neuen Wert zuweist). Wenn der Client wiederholt, verwenden alle Versuche dieselbe Clientanforderungs-ID. Im Fall eines Batches, der vom Client gesendet wird, verfügt der Batch über eine einzelne Clientanforderungs-ID.

Serveranforderungs-ID

Der Speicherdienst generiert automatisch Serveranforderungs-IDs.

  • Im serverseitigen Speicherprotokoll wird die Serveranforderungs-ID in der Request ID header Spalte angezeigt.
  • In einer Netzwerkablaufverfolgung, z. B. einer, die von Fiddler erfasst wird, wird die Serveranforderungs-ID in Antwortnachrichten als x-ms-request-id HTTP-Headerwert angezeigt.
  • Im clientseitigen Protokoll, das von der Speicherclientbibliothek erstellt wird, wird die Serveranforderungs-ID in der Operation Text Spalte für den Protokolleintrag mit Details zur Serverantwort angezeigt.

Hinweis

Der Speicherdienst weist jeder empfangenen Anforderung immer eine eindeutige Serveranforderungs-ID zu, sodass jeder Wiederholungsversuch vom Client und jeder vorgang, der in einem Batch enthalten ist, über eine eindeutige Serveranforderungs-ID verfügt.

Das folgende Codebeispiel veranschaulicht die Verwendung einer benutzerdefinierten Clientanforderungs-ID.

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

Zeitstempel

Sie können auch Zeitstempel verwenden, um verwandte Protokolleinträge zu finden. Achten Sie jedoch auf eine eventuell vorhandene Uhrabweichung zwischen Client und Server. Search plus oder minus 15 Minuten für übereinstimmende serverseitige Einträge basierend auf dem Zeitstempel auf dem Client. Denken Sie daran, dass die Blobmetadaten für die Blobs, die Metriken enthalten, den Zeitraum für die im Blob gespeicherten Metriken angeben. Dieser Zeitbereich ist nützlich, wenn Sie über viele Metrikblobs für dieselbe Minute oder Stunde verfügen.

Anleitungen zur Problembehandlung

Dieser Abschnitt hilft Ihnen bei der Diagnose und Problembehandlung einiger der häufig auftretenden Probleme, die bei der Verwendung der Azure-Speicherdienste auftreten können. Verwenden Sie die folgende Liste, um die informationen zu finden, die für Ihr spezifisches Problem relevant sind.

Entscheidungsstruktur zur Problembehandlung

Bezieht sich Ihr Problem auf die Leistung eines der Speicherdienste?

Bezieht sich Ihr Problem auf die Verfügbarkeit eines der Speicherdienste?

Empfängt Ihre Clientanwendung eine HTTP 4XX-Antwort (z. B. 404) von einem Speicherdienst?

Metriken zeigen einen niedrigen PercentSuccess-Wert an, oder Analyseprotokolleinträge weisen Vorgänge mit Transaktion status von ClientOtherErrors auf.

Kapazitätsmetriken zeigen einen unerwarteten Anstieg der Speicherkapazitätsauslastung an.

Ihr Problem ergibt sich aus der Verwendung des Speicheremulators für Entwicklung oder Tests.

Bei der Installation des Azure SDK für .NET treten Probleme auf.

Es gibt ein anderes Problem mit einem Speicherdienst.

Metriken zeigen eine hohe AverageE2ELatency und eine niedrige AverageServerLatency an.

Die folgende Abbildung des überwachungstools Azure-Portal zeigt ein Beispiel, in dem AverageE2ELatency deutlich höher als AverageServerLatency ist.

Abbildung aus der Azure-Portal, die ein Beispiel zeigt, in dem AverageE2ELatency deutlich höher als AverageServerLatency ist.

Der Speicherdienst berechnet nur die Metrik AverageE2ELatency für erfolgreiche Anforderungen und enthält im Gegensatz zu AverageServerLatency die Zeit, die der Client benötigt, um die Daten zu senden und bestätigungen vom Speicherdienst zu empfangen. Daher kann ein Unterschied zwischen AverageE2ELatency und AverageServerLatency entweder darauf zurückzuführen sein, dass die Clientanwendung langsam reagiert oder auf Bedingungen im Netzwerk zurückzuführen ist.

Hinweis

Sie können auch E2ELatency und ServerLatency für einzelne Speichervorgänge in den Speicherprotokolldaten anzeigen.

Untersuchen von Clientleistungsproblemen

Mögliche Gründe für die langsame Reaktion des Clients sind eine begrenzte Anzahl verfügbarer Verbindungen oder Threads oder eine geringe Anzahl von Ressourcen wie CPU, Arbeitsspeicher oder Netzwerkbandbreite. Sie können das Problem möglicherweise beheben, indem Sie den Clientcode so ändern, dass er effizienter ist (z. B. durch asynchrone Aufrufe des Speicherdiensts), oder indem Sie einen größeren virtuellen Computer (mit mehr Kernen und mehr Arbeitsspeicher) verwenden.

Für die Tabellen- und Warteschlangendienste kann der Nagle-Algorithmus auch eine hohe AverageE2ELatency im Vergleich zu AverageServerLatency verursachen. Weitere Informationen finden Sie unter Nagles Algorithmus ist für kleine Anforderungen nicht freundlich. Sie können den Nagle-Algorithmus im Code mithilfe der ServicePointManager -Klasse im System.Net -Namespace deaktivieren. Dies sollten Sie tun, bevor Sie aufruft die Tabellen- oder Warteschlangendienste in Ihrer Anwendung, da dies keine Auswirkungen auf bereits geöffnete Verbindungen hat. Das folgende Beispiel stammt aus der Application_Start -Methode in einer Workerrolle.

var connectionString = Constants.connectionString;

QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);

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

Überprüfen Sie die clientseitigen Protokolle, um festzustellen, wie viele Anforderungen Ihre Clientanwendung übermittelt, und überprüfen Sie, ob allgemeine Anforderungen vorhanden sind. NET-bezogene Leistungsengpässe in Ihrem Client, z. B. CPU, .NET Garbage Collection, Netzwerkauslastung oder Arbeitsspeicher. Als Ausgangspunkt für die Problembehandlung von .NET-Clientanwendungen finden Sie unter Debuggen, Ablaufverfolgung und Profilerstellung.

Untersuchen von Netzwerklatenzproblemen

In der Regel ist eine hohe End-to-End-Latenz, die durch das Netzwerk verursacht wird, auf vorübergehende Bedingungen zurückzuführen. Sie können sowohl vorübergehende als auch persistente Netzwerkprobleme wie verworfene Pakete mithilfe von Tools wie Wireshark untersuchen.

Weitere Informationen zur Verwendung von Wireshark zur Behandlung von Netzwerkproblemen finden Sie unter Anhang 2: Verwenden von Wireshark zum Erfassen von Netzwerkdatenverkehr.

Metriken zeigen eine niedrige AverageE2ELatency und eine niedrige AverageServerLatency an, aber der Client weist eine hohe Latenz auf.

In diesem Szenario ist die wahrscheinlichste Ursache eine Verzögerung der Speicheranforderungen, die den Speicherdienst erreichen. Sie sollten untersuchen, warum Anforderungen vom Client nicht an den Blobdienst weitergeleitet werden.

Ein möglicher Grund dafür, dass der Client das Senden von Anforderungen verzögert, ist die begrenzte Anzahl verfügbarer Verbindungen oder Threads.

Überprüfen Sie außerdem, ob der Client mehrere Wiederholungen ausführt, und untersuchen Sie, warum dies der Fall ist. Um zu bestimmen, ob der Client mehrere Wiederholungen ausführt, können Sie:

  • Untersuchen Sie die Storage Analytics Protokolle. Wenn mehrere Wiederholungen ausgeführt werden, werden mehrere Vorgänge mit derselben Clientanforderungs-ID, aber mit unterschiedlichen Serveranforderungs-IDs angezeigt.
  • Untersuchen Sie die Clientprotokolle. Die ausführliche Protokollierung gibt an, dass ein Wiederholungsversuch stattgefunden hat.
  • Debuggen Sie Ihren Code, und überprüfen Sie die Eigenschaften des Objekts, das OperationContext der Anforderung zugeordnet ist. Wenn der Vorgang wiederholt wurde, enthält die RequestResults Eigenschaft mehrere eindeutige Serveranforderungs-IDs. Sie können auch die Start- und Endzeiten für jede Anforderung überprüfen. Weitere Informationen finden Sie im Codebeispiel im Abschnitt Serveranforderungs-ID.

Wenn keine Probleme auf dem Client vorliegen, sollten Sie potenzielle Netzwerkprobleme wie Paketverlust untersuchen. Sie können Tools wie Wireshark verwenden, um Netzwerkprobleme zu untersuchen.

Weitere Informationen zur Verwendung von Wireshark zur Behandlung von Netzwerkproblemen finden Sie unter Anhang 2: Verwenden von Wireshark zum Erfassen von Netzwerkdatenverkehr.

Metriken weisen eine hohe AverageServerLatency auf

Im Fall einer hohen AverageServerLatency für Blobdownloadanforderungen sollten Sie die Speicherprotokollierungsprotokolle verwenden, um zu ermitteln, ob wiederholte Anforderungen für dasselbe Blob (oder eine Gruppe von Blobs) vorhanden sind. Bei Blobuploadanforderungen sollten Sie untersuchen, welche Blockgröße der Client verwendet (z. B. können Blöcke mit einer Größe von weniger als 64 K zu Mehraufwand führen, es sei denn, die Lesevorgänge befinden sich auch in weniger als 64.000 Blöcken) und wenn mehrere Clients Blöcke parallel in dasselbe Blob hochladen. Sie sollten auch die Minutenmetriken auf Spitzen bei der Anzahl der Anforderungen überprüfen, die zur Überschreitung der Skalierbarkeitsziele pro Sekunde führen. Weitere Informationen finden Sie unter Metriken zeigen einen Anstieg von PercentTimeoutError an.

Wenn eine hohe AverageServerLatency für Blobdownloadanforderungen angezeigt wird, wenn wiederholte Anforderungen für dasselbe Blob oder die gleiche Gruppe von Blobs vorhanden sind, sollten Sie diese Blobs mithilfe von Azure Cache oder dem Azure Content Delivery Network (CDN) zwischenspeichern. Bei Uploadanforderungen können Sie den Durchsatz verbessern, indem Sie eine größere Blockgröße verwenden. Für Abfragen von Tabellen ist es auch möglich, die clientseitige Zwischenspeicherung auf Clients zu implementieren, die dieselben Abfragevorgänge ausführen und bei denen sich die Daten nicht häufig ändern.

Hohe AverageServerLatency-Werte können auch ein Symptom schlecht entworfener Tabellen oder Abfragen sein, die zu Scanvorgängen führen oder dem Anfüge-/Prepend-Antimuster folgen. Weitere Informationen finden Sie unter Metriken zeigen einen Anstieg von PercentThrottlingError an.

Hinweis

Eine umfassende Leistungsprüfliste finden Sie hier: Microsoft Azure Storage Checkliste für Leistung und Skalierbarkeit.

Unerwartete Verzögerungen bei der Nachrichtenübermittlung in einer Warteschlange

Wenn eine Verzögerung zwischen dem Zeitpunkt, zu dem eine Anwendung einer Warteschlange eine Nachricht hinzufügt, und dem Zeitpunkt, an dem sie verfügbar ist, um aus der Warteschlange zu lesen, führen Sie die folgenden Schritte aus, um das Problem zu diagnostizieren:

  • Stellen Sie sicher, dass die Anwendung die Nachrichten erfolgreich zur Warteschlange hinzugefügt hat. Überprüfen Sie, ob die Anwendung die AddMessage Methode nicht mehrmals wiederholt, bevor sie erfolgreich ist. In den Protokollen der Speicherclientbibliothek werden alle wiederholten Wiederholungen von Speichervorgängen angezeigt.
  • Stellen Sie sicher, dass zwischen der Workerrolle, die die Nachricht der Warteschlange hinzufügt, und der Workerrolle, die die Nachricht aus der Warteschlange liest, keine Uhrabweichung besteht. Eine Uhrschiefe lässt den Eindruck entstehen, dass es eine Verzögerung bei der Verarbeitung gibt.
  • Überprüfen Sie, ob die Workerrolle, die die Nachrichten aus der Warteschlange liest, fehlschlägt. Wenn ein Warteschlangenclient die GetMessage -Methode aufruft, aber nicht mit einer Bestätigung antwortet, bleibt die Nachricht in der Warteschlange unsichtbar, bis der invisibilityTimeout Zeitraum abläuft. An diesem Punkt wird die Nachricht wieder für die Verarbeitung verfügbar.
  • Überprüfen Sie, ob die Warteschlangenlänge im Laufe der Zeit zunimmt. Dies kann auftreten, wenn Nicht genügend Worker verfügbar sind, um alle Nachrichten zu verarbeiten, die andere Worker in die Warteschlange stellen. Überprüfen Sie außerdem die Metriken, um zu ermitteln, ob Löschanforderungen fehlschlagen, und die Anzahl der Meldungen, die aus der Warteschlange entfernt werden, was auf wiederholte fehlgeschlagene Versuche zum Löschen der Nachricht hindeuten kann.
  • Überprüfen Sie die Speicherprotokollierungsprotokolle auf alle Warteschlangenvorgänge, die über einen längeren Zeitraum als üblich höhere E2ELatency - und ServerLatency-Werte aufweisen als erwartet.

Metriken zeigen einen Anstieg von PercentThrottlingError an

Drosselungsfehler treten auf, wenn Sie die Skalierbarkeitsziele eines Speicherdiensts überschreiten. Der Speicherdienst drosselt, um sicherzustellen, dass kein einzelner Client oder Mandant den Dienst auf Kosten anderer verwenden kann. Weitere Informationen finden Sie unter Skalierbarkeits- und Leistungsziele für Standardspeicherkonten . Ausführliche Informationen zu Skalierbarkeitszielen für Speicherkonten und Leistungsziele für Partitionen in Speicherkonten finden Sie unter Skalierbarkeits- und Leistungsziele für Speicherkonten.

Wenn die Metrik PercentThrottlingError einen Anstieg des Prozentsatzes von Anforderungen anzeigt, bei denen ein Drosselungsfehler auftritt, müssen Sie eines von zwei Szenarien untersuchen:

Ein Anstieg von PercentThrottlingError tritt häufig gleichzeitig mit einer Erhöhung der Anzahl von Speicheranforderungen oder beim anfänglichen Auslastungstest Ihrer Anwendung auf. Dies kann sich auch im Client als HTTP-status Nachrichten von Speichervorgängen als "503 Server ausgelastet" oder "500 Vorgangstimeout" manifestieren.

Vorübergehender Anstieg von PercentThrottlingError

Wenn Sie Spitzen im Wert von PercentThrottlingError feststellen, die mit Zeiträumen hoher Aktivität für die Anwendung übereinstimmen, können Sie eine exponentielle (nicht lineare) Backoffstrategie für Wiederholungen in Ihrem Client implementieren. Backoff-Wiederholungsversuche reduzieren die unmittelbare Last auf der Partition und helfen Ihrer Anwendung, Datenverkehrsspitzen zu glätten. Weitere Informationen zum Implementieren von Wiederholungsrichtlinien mithilfe der Speicherclientbibliothek finden Sie im Microsoft.Azure.Storage.RetryPolicies-Namespace.

Hinweis

Möglicherweise treten auch Spitzen im Wert von PercentThrottlingError auf, die nicht mit Zeiträumen hoher Aktivität für die Anwendung übereinstimmen. Die wahrscheinlichste Ursache ist der Speicherdienst, der Partitionen verschiebt, um den Lastenausgleich zu verbessern.

Permanenter Anstieg von PercentThrottlingError

Wenn nach einem dauerhaften Anstieg Ihrer Transaktionsvolumes ein konstant hoher Wert für PercentThrottlingError auftritt oder wenn Sie ihre ersten Auslastungstests für Ihre Anwendung durchführen, müssen Sie auswerten, wie Ihre Anwendung Speicherpartitionen verwendet und ob sie sich den Skalierbarkeitszielen für ein Speicherkonto nähert. Wenn beispielsweise Drosselungsfehler in einer Warteschlange auftreten (die als einzelne Partition zählt), sollten Sie die Verwendung zusätzlicher Warteschlangen in Betracht ziehen, um die Transaktionen auf mehrere Partitionen zu verteilen. Wenn in einer Tabelle Drosselungsfehler auftreten, müssen Sie die Verwendung eines anderen Partitionierungsschemas in Betracht ziehen, um Ihre Transaktionen mithilfe eines größeren Bereichs von Partitionsschlüsselwerten auf mehrere Partitionen zu verteilen. Eine häufige Ursache für dieses Problem ist das Antimuster prepend/append, bei dem Sie das Datum als Partitionsschlüssel auswählen und dann alle Daten an einem bestimmten Tag in eine Partition geschrieben werden: Bei Last kann dies zu einem Schreibengpass führen. Ziehen Sie entweder einen anderen Partitionierungsentwurf in Betracht, oder bewerten Sie, ob die Verwendung von BlobSpeicher eine bessere Lösung ist. Überprüfen Sie außerdem, ob eine Drosselung aufgrund von Spitzen im Datenverkehr auftritt, und untersuchen Sie Möglichkeiten, ihr Anforderungsmuster zu glätten.

Wenn Sie Ihre Transaktionen auf mehrere Partitionen verteilen, müssen Sie die für das Speicherkonto festgelegten Skalierbarkeitsgrenzwerte kennen. Wenn Sie beispielsweise zehn Warteschlangen verwendet haben, die jeweils maximal 2.000 1-KB-Nachrichten pro Sekunde verarbeiten, haben Sie den Gesamtgrenzwert von 20.000 Nachrichten pro Sekunde für das Speicherkonto erreicht. Wenn Sie mehr als 20.000 Entitäten pro Sekunde verarbeiten müssen, sollten Sie mehrere Speicherkonten verwenden. Sie sollten auch bedenken, dass sich die Größe Ihrer Anforderungen und Entitäten darauf auswirkt, wann der Speicherdienst Ihre Clients drosselt. Wenn Sie über größere Anforderungen und Entitäten verfügen, werden Sie möglicherweise früher gedrosselt.

Ineffizienter Abfrageentwurf kann auch dazu führen, dass Sie die Skalierbarkeitsgrenzwerte für Tabellenpartitionen erreichen. Beispielsweise muss eine Abfrage mit einem Filter, der nur ein Prozent der Entitäten in einer Partition auswählt, aber alle Entitäten in einer Partition überprüft, auf jede Entität zugreifen. Jede gelesene Entität wird auf die Gesamtzahl der Transaktionen in dieser Partition angerechnet. Daher können Sie die Skalierbarkeitsziele problemlos erreichen.

Hinweis

Ihre Leistungstests sollten ineffiziente Abfrageentwürfe in Ihrer Anwendung offenlegen.

Metriken zeigen einen Anstieg von PercentTimeoutError an

Ihre Metriken zeigen einen Anstieg von PercentTimeoutError für einen Ihrer Speicherdienste an. Gleichzeitig empfängt der Client eine große Menge von HTTP-status Nachrichten von Speichervorgängen mit "500 Vorgangstimeout".

Hinweis

Möglicherweise treten vorübergehend Timeoutfehler auf, wenn der Speicherdienst einen Lastenausgleich für Anforderungen durch Verschieben einer Partition auf einen neuen Server angibt.

Die Metrik PercentTimeoutError ist eine Aggregation der folgenden Metriken: ClientTimeoutError, AnonymousClientTimeoutError, SASClientTimeoutError, ServerTimeoutError, AnonymousServerTimeoutError und SASServerTimeoutError.

Die Servertimeouts werden durch einen Fehler auf dem Server verursacht. Die Clienttimeouts treten auf, weil ein Vorgang auf dem Server das vom Client angegebene Timeout überschritten hat. Beispielsweise kann ein Client, der die Speicherclientbibliothek verwendet, mithilfe der ServerTimeout -Eigenschaft der QueueRequestOptions -Klasse ein Timeout für einen Vorgang festlegen.

Servertimeouts deuten auf ein Problem mit dem Speicherdienst hin, das eine weitere Untersuchung erfordert. Mithilfe von Metriken können Sie ermitteln, ob Sie die Skalierbarkeitsgrenzwerte für den Dienst erreichen, und um Spitzen im Datenverkehr zu identifizieren, die dieses Problem verursachen könnten. Wenn das Problem zeitweilig auftritt, kann dies auf eine Lastenausgleichsaktivität im Dienst zurückzuführen sein. Wenn das Problem dauerhaft ist und nicht dadurch verursacht wird, dass Ihre Anwendung die Skalierbarkeitsgrenzen des Diensts erreicht, sollten Sie ein Supportproblem auslösen. Bei Clienttimeouts müssen Sie entscheiden, ob das Timeout auf einen geeigneten Wert im Client festgelegt ist, und entweder den im Client festgelegten Timeoutwert ändern oder untersuchen, wie Sie die Leistung der Vorgänge im Speicherdienst verbessern können, z. B. indem Sie Ihre Tabellenabfragen optimieren oder die Größe Ihrer Nachrichten verringern.

Metriken zeigen einen Anstieg von PercentNetworkError an.

Ihre Metriken zeigen einen Anstieg von PercentNetworkError für einen Ihrer Speicherdienste an. Die Metrik PercentNetworkError ist eine Aggregation der folgenden Metriken: NetworkError, AnonymousNetworkError und SASNetworkError. Diese treten auf, wenn der Speicherdienst einen Netzwerkfehler erkennt, wenn der Client eine Speicheranforderung sendet.

Die häufigste Ursache für diesen Fehler ist ein Client, der die Verbindung trennt, bevor ein Timeout im Speicherdienst abläuft. Untersuchen Sie den Code in Ihrem Client, um zu verstehen, warum und wann der Client die Verbindung mit dem Speicherdienst trennt. Sie können auch Wireshark oder Tcping verwenden, um Netzwerkkonnektivitätsprobleme vom Client aus zu untersuchen. Diese Tools werden in den Anhängen beschrieben.

Der Client empfängt HTTP 403 (Verboten) Nachrichten.

Wenn Ihre Clientanwendung HTTP 403 (Verboten)-Fehler auslöst, ist eine wahrscheinliche Ursache, dass der Client eine abgelaufene Shared Access Signature (SAS) verwendet, wenn er eine Speicheranforderung sendet (obwohl andere mögliche Ursachen eine Uhrschiefe, ungültige Schlüssel und leere Header sind). Wenn ein abgelaufener SAS-Schlüssel die Ursache ist, werden keine Einträge in den serverseitigen Speicherprotokolldaten angezeigt. Die folgende Tabelle zeigt ein Beispiel aus dem clientseitigen Protokoll, das von der Speicherclientbibliothek generiert wurde und dieses Problem veranschaulicht:

Quelle Ausführlichkeit Ausführlichkeit Clientanforderungs-ID Vorgangstext
Microsoft.Azure.Storage Information 3 85d077ab-... Starting operation with location Primary per location mode PrimaryOnly.
Microsoft.Azure.Storage Information 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 Information 3 85d077ab -... Waiting for response.
Microsoft.Azure.Storage Warnung 2 85d077ab -... Exception thrown while waiting for response: The remote server returned an error: (403) Forbidden.
Microsoft.Azure.Storage Information 3 85d077ab -... Response received. Status code = 403, Request ID = <Request ID>, Content-MD5 = , ETag = .
Microsoft.Azure.Storage Warnung 2 85d077ab -... Exception thrown during the operation: The remote server returned an error: (403) Forbidden..
Microsoft.Azure.Storage Information 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 Information 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.

In diesem Szenario sollten Sie untersuchen, warum das SAS-Token abläuft, bevor der Client das Token an den Server sendet:

  • In der Regel sollten Sie keine Startzeit festlegen, wenn Sie eine SAS erstellen, die von einem Client sofort verwendet werden kann. Wenn zwischen dem Host, der die SAS mit der aktuellen Zeit generiert, und dem Speicherdienst geringfügige Taktunterschiede bestehen, kann der Speicherdienst eine sas empfangen, die noch nicht gültig ist.
  • Legen Sie keine sehr kurze Ablaufzeit für eine SAS fest. Auch hier können kleine Taktunterschiede zwischen dem Host, der die SAS generiert, und dem Speicherdienst dazu führen, dass eine SAS scheinbar früher als erwartet abläuft.
  • Stimmt der Versionsparameter im SAS-Schlüssel (z. B sv. =2015-04-05) mit der Version der verwendeten Speicherclientbibliothek überein? Es wird empfohlen, immer die neueste Version der Speicherclientbibliothek zu verwenden.
  • Wenn Sie Ihre Speicherzugriffsschlüssel erneut generieren, werden alle vorhandenen SAS-Token möglicherweise ungültig. Dieses Problem kann auftreten, wenn Sie SAS-Token mit einer langen Ablaufzeit für die Zwischenspeicherung von Clientanwendungen generieren.

Wenn Sie die Speicherclientbibliothek zum Generieren von SAS-Token verwenden, ist es einfach, ein gültiges Token zu erstellen. Wenn Sie jedoch die Storage-REST-API verwenden und die SAS-Token manuell erstellen, lesen Sie Delegating Access with a Shared Access Signature (Delegating Access with a Shared Access Signature).

Der Client empfängt HTTP 404(Nicht gefunden)-Nachrichten.

Wenn die Clientanwendung eine HTTP 404 (Nicht gefunden)-Nachricht vom Server empfängt, bedeutet dies, dass das Objekt, das der Client zu verwenden versucht (z. B. eine Entität, tabelle, ein Blob, ein Container oder eine Warteschlange), im Speicherdienst nicht vorhanden ist. Hierfür gibt es eine Reihe möglicher Gründe, z. B.:

Der Client oder ein anderer Prozess hat das Objekt zuvor gelöscht.

In Szenarien, in denen der Client versucht, Daten in einem Speicherdienst zu lesen, zu aktualisieren oder zu löschen, ist es in der Regel einfach, in den serverseitigen Protokollen einen vorherigen Vorgang zu identifizieren, der das betreffende Objekt aus dem Speicherdienst gelöscht hat. Häufig zeigen die Protokolldaten, dass ein anderer Benutzer oder Prozess das Objekt gelöscht hat. Im serverseitigen Speicherprotokollprotokoll werden die Spalten operation-type und requested-object-key angezeigt, wenn ein Client ein Objekt gelöscht hat.

In dem Szenario, in dem ein Client versucht, ein Objekt einzufügen, ist es möglicherweise nicht sofort offensichtlich, warum dies zu einer HTTP 404 (Nicht gefunden)-Antwort führt, da der Client ein neues Objekt erstellt. Wenn der Client jedoch ein Blob erstellt, muss er den Blobcontainer finden können. Wenn der Client eine Nachricht erstellt, muss er in der Lage sein, eine Warteschlange zu finden. Und wenn der Client eine Zeile hinzufügt, muss er in der Lage sein, die Tabelle zu finden.

Sie können das clientseitige Protokoll aus der Speicherclientbibliothek verwenden, um ein detaillierteres Verständnis dafür zu erhalten, wann der Client bestimmte Anforderungen an den Speicherdienst sendet.

Das folgende clientseitige Protokoll, das von der Speicherclientbibliothek generiert wird, veranschaulicht das Problem, wenn der Client den Container für das blob, das er erstellt, nicht finden kann. Dieses Protokoll enthält Details zu den folgenden Speichervorgängen:

Anfrage-ID Vorgang
07b26a5d-... DeleteIfExists -Methode zum Löschen des Blobcontainers. Beachten Sie, dass dieser Vorgang eine HEAD Anforderung enthält, um zu überprüfen, ob der Container vorhanden ist.
e2d06d78... CreateIfNotExists -Methode zum Erstellen des Blobcontainers. Beachten Sie, dass dieser Vorgang eine HEAD Anforderung enthält, die überprüft, ob der Container vorhanden ist. Gibt HEAD eine 404-Nachricht zurück, fährt aber fort.
de8b1c3c-... UploadFromStream -Methode zum Erstellen des Blobs. Die PUT Anforderung schlägt mit einer 404-Nachricht fehl.

Protokolleinträge:

Anfrage-ID Vorgangstext
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..

In diesem Beispiel zeigt das Protokoll, dass der Client Anforderungen der CreateIfNotExists -Methode (Anforderungs-ID e2d06d78...) mit den Anforderungen der UploadFromStream -Methode (de8b1c3c-...) übergibt. Diese Verschachtelung erfolgt, weil die Clientanwendung diese Methoden asynchron aufruft. Ändern Sie den asynchronen Code im Client, um sicherzustellen, dass der Container erstellt wird, bevor Versucht wird, Daten in ein Blob in diesem Container hochzuladen. Im Idealfall sollten Sie alle Ihre Container im Voraus erstellen.

Ein Sas-Autorisierungsproblem (Shared Access Signature)

Wenn die Clientanwendung versucht, einen SAS-Schlüssel zu verwenden, der nicht die erforderlichen Berechtigungen für den Vorgang enthält, gibt der Speicherdienst eine HTTP 404 (Nicht gefunden)-Nachricht an den Client zurück. Gleichzeitig wird in den Metriken auch ein Wert ungleich 0 (null) für SASAuthorizationError angezeigt.

Die folgende Tabelle zeigt eine serverseitige Beispielprotokollmeldung aus der Speicherprotokolldatei:

Name Wert
Startzeit der Anforderung 2014-05-30T06:17:48.4473697Z
Typ des Vorgangs GetBlobProperties
Status anfordern SASAuthorizationError
HTTP-Statuscode 404
Authentifizierungstyp Sas
Diensttyp Blob
Anforderungs-URL https://domemaildist.blob.core.windows.net/azureimblobcontainer/blobCreatedViaSAS.txt
  ?sv=2014-02-14&sr=c&si=mypolicy&sig=XXXXX&; api-version=2014-02-14
Anforderungs-ID-Header <Anforderungs-ID-Header>
Clientanforderungs-ID <Clientanforderungs-ID>

Untersuchen Sie, warum Ihre Clientanwendung versucht, einen Vorgang auszuführen, für den ihr keine Berechtigungen erteilt wurden.

Clientseitiger JavaScript-Code verfügt nicht über die Berechtigung für den Zugriff auf das Objekt.

Wenn Sie einen JavaScript-Client verwenden und der Speicherdienst HTTP 404-Nachrichten zurückgibt, suchen Sie im Browser nach den folgenden JavaScript-Fehlern:

SEC7120: Der Ursprung http://localhost:56309 wurde im Access-Control-Allow-Origin-Header nicht gefunden.
SCRIPT7002: XMLHttpRequest: Netzwerkfehler 0x80070005, Zugriff verweigert.

Hinweis

Sie können die F12-Entwicklertools in Internet Explorer verwenden, um die zwischen dem Browser und dem Speicherdienst ausgetauschten Nachrichten nachzuverfolgen, wenn Sie clientseitige JavaScript-Probleme behandeln.

Diese Fehler treten auf, weil der Webbrowser die gleiche Ursprungsrichtlinie-Sicherheitseinschränkung implementiert, die verhindert, dass eine Webseite eine API in einer anderen Domäne als der Domäne aufruft, aus der die Seite stammt.

Um das JavaScript-Problem zu umgehen, können Sie CORS (Cross-Origin Resource Sharing) für den Speicherdienst konfigurieren, auf den der Client zugreift. Weitere Informationen finden Sie unter CorS-Unterstützung (Cross-Origin Resource Sharing) für Azure Storage-Dienste.

Im folgenden Codebeispiel wird gezeigt, wie Sie Ihren Blobdienst so konfigurieren, dass JavaScript, das in der Contoso-Domäne ausgeführt wird, auf ein Blob in Ihrem Blobspeicherdienst zugreifen kann:

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);

Netzwerkfehler

Unter bestimmten Umständen können verlorene Netzwerkpakete dazu führen, dass der Speicherdienst HTTP 404-Nachrichten an den Client zurückgibt. Wenn Ihre Clientanwendung beispielsweise eine Entität aus dem Tabellendienst löscht, sehen Sie, dass der Client eine Speicher-Ausnahme auslöst, die eine "HTTP 404 (Nicht gefunden)"-status Meldung vom Tabellendienst meldet. Wenn Sie die Tabelle im Tabellenspeicherdienst untersuchen, sehen Sie, dass der Dienst die Entität wie angefordert gelöscht hat.

Die Ausnahmedetails im Client enthalten die Anforderungs-ID (7e84f12d...), die vom Tabellendienst für die Anforderung zugewiesen wurde. Sie können diese Informationen verwenden, um die Anforderungsdetails in den serverseitigen Speicherprotokollen zu suchen, indem Sie in der request-id-header Spalte in der Protokolldatei suchen. Sie können die Metriken auch verwenden, um zu ermitteln, wann Fehler wie dieser auftreten, und dann die Protokolldateien basierend auf dem Zeitpunkt durchsuchen, zu dem die Metriken diesen Fehler aufgezeichnet haben. Dieser Protokolleintrag zeigt, dass beim Löschen die Meldung "HTTP (404) Client Other Error" status fehlgeschlagen ist. Derselbe Protokolleintrag enthält auch die vom Client in der client-request-id Spalte generierte Anforderungs-ID (813ea74f...).

Das serverseitige Protokoll enthält auch einen weiteren Eintrag mit demselben client-request-id Wert (813ea74f...) für einen erfolgreichen Löschvorgang für dieselbe Entität und vom gleichen Client. Dieser erfolgreiche Löschvorgang erfolgte sehr kurz vor der fehlgeschlagenen Löschanforderung.

Die wahrscheinlichste Ursache für dieses Szenario ist, dass der Client eine Löschanforderung für die Entität an den Tabellendienst gesendet hat, die erfolgreich war, aber keine Bestätigung vom Server erhalten hat (möglicherweise aufgrund eines temporären Netzwerkproblems). Der Client hat dann automatisch den Vorgang wiederholt (mit demselben client-request-id), und dieser Wiederholungsversuch ist fehlgeschlagen, da die Entität bereits gelöscht wurde.

Wenn dieses Problem häufig auftritt, sollten Sie untersuchen, warum der Client keine Bestätigungen vom Tabellendienst empfangen kann. Wenn das Problem zeitweilig auftritt, sollten Sie den Fehler "HTTP (404) Nicht gefunden" abfangen und im Client protokollieren, aber dem Client erlauben, den Vorgang fortzusetzen.

Der Client empfängt HTTP 409-Nachrichten (Konflikt)

Die folgende Tabelle zeigt einen Extrakt aus dem serverseitigen Protokoll für zwei Clientvorgänge: DeleteIfExists unmittelbar gefolgt von CreateIfNotExists der Verwendung desselben Blobcontainernamens. Jeder Clientvorgang führt zu zwei Anforderungen, die an den Server gesendet werden, zuerst eine GetContainerProperties Anforderung zur Überprüfung, ob der Container vorhanden ist, gefolgt von der Anforderung oder CreateContainer der DeleteContainer Anforderung.

Zeitstempel Vorgang Ergebnis Containername Clientanforderungs-ID
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-...

Der Code in der Clientanwendung löscht einen Blobcontainer und erstellt dann sofort einen Blobcontainer mit demselben Namen neu: Die CreateIfNotExists Methode (Clientanforderungs-ID bc881924-...) schlägt schließlich mit dem HTTP-Fehler 409 (Konflikt) fehl. Wenn ein Client Blobcontainer, Tabellen oder Warteschlangen löscht, gibt es einen kurzen Zeitraum, bevor der Name wieder verfügbar ist.

Die Clientanwendung sollte eindeutige Containernamen verwenden, wenn sie neue Container erstellt, wenn das Lösch-/Neuerstellungsmuster üblich ist.

Metriken zeigen niedrige PercentSuccess- oder Analyseprotokolleinträge weisen Vorgänge mit transaktionsbezogenen status von ClientOtherErrors auf.

Die Metrik PercentSuccess erfasst den Prozentsatz der erfolgreichen Vorgänge basierend auf ihrem HTTP-Statuscode. Vorgänge mit status Codes von 2XX gelten als erfolgreich, während Vorgänge mit status Codes in den Bereichen 3XX, 4XX und 5XX als nicht erfolgreich gelten und den Metrikwert PercentSuccess verringern. In den serverseitigen Speicherprotokolldateien werden diese Vorgänge mit einer Transaktion status clientOtherErrors aufgezeichnet.

Es ist wichtig zu beachten, dass diese Vorgänge erfolgreich abgeschlossen wurden und sich daher nicht auf andere Metriken auswirken, z. B. die Verfügbarkeit. Beispiele für Vorgänge, die erfolgreich ausgeführt werden, aber zu nicht erfolgreichen HTTP-status Codes führen können:

  • ResourceNotFound (Nicht gefunden 404), z. B. aus einer GET Anforderung an ein Blob, das nicht vorhanden ist.
  • ResourceAlreadyExists (Konflikt 409), z. B. aus einem CreateIfNotExist Vorgang, bei dem die Ressource bereits vorhanden ist.
  • ConditionNotMet (Not Modified 304), z. B. aus einem bedingten Vorgang, z. B. wenn ein Client einen ETag Wert und einen HTTP-Header If-None-Match sendet, um ein Image nur anzufordern, wenn es seit dem letzten Vorgang aktualisiert wurde.

Eine Liste der allgemeinen REST-API-Fehlercodes, die die Speicherdienste zurückgeben, finden Sie auf der Seite Allgemeine REST-API-Fehlercodes.

Kapazitätsmetriken zeigen einen unerwarteten Anstieg der Speicherkapazitätsauslastung an

Wenn Sie plötzliche, unerwartete Änderungen bei der Kapazitätsauslastung in Ihrem Speicherkonto sehen, können Sie die Gründe untersuchen, indem Sie sich zuerst Ihre Verfügbarkeitsmetriken ansehen. Beispielsweise kann eine Erhöhung der Anzahl fehlerhafter Löschanforderungen zu einer Erhöhung der Menge an Blobspeicher führen, die Sie als anwendungsspezifische Bereinigungsvorgänge verwenden, die Sie möglicherweise erwartet haben, um Speicherplatz freizugeben, möglicherweise nicht wie erwartet funktionieren (z. B. weil die SAS-Token, die zum Freigeben von Speicherplatz verwendet werden, abgelaufen sind).

Ihr Problem ergibt sich aus der Verwendung des Speicher-Emulators für Entwicklung oder Test

In der Regel verwenden Sie den Speicheremulator während der Entwicklung und tests, um die Anforderung eines Azure-Speicherkontos zu vermeiden. Die häufigsten Probleme, die bei der Verwendung des Speicher-Emulators auftreten können, sind:

Das Feature "X" funktioniert im Speicher-Emulator nicht.

Der Speicheremulator unterstützt nicht alle Features der Azure-Speicherdienste, z. B. den Dateidienst. Weitere Informationen finden Sie unter Verwenden des Azure Storage-Emulators für Entwicklung und Tests.

Verwenden Sie für die Features, die der Speicheremulator nicht unterstützt, den Azure-Speicherdienst in der Cloud.

Fehler "Der Wert für einen der HTTP-Header hat nicht das richtige Format" bei Verwendung des Speicher-Emulators

Sie testen Ihre Anwendung, die die Speicherclientbibliothek verwendet, mit dem lokalen Speicheremulator, und Methodenaufrufe wie CreateIfNotExists schlagen mit der Fehlermeldung "Der Wert für einen der HTTP-Header hat nicht das richtige Format" fehl. Dies gibt an, dass die Version des verwendeten Speicheremulators die Version der von Ihnen verwendeten Speicherclientbibliothek nicht unterstützt. Die Speicherclientbibliothek fügt den Header x-ms-version allen Anforderungen hinzu, die sie stellt. Wenn der Speicheremulator den Wert im x-ms-version Header nicht erkennt, lehnt er die Anforderung ab.

Sie können die Protokolle des Speicherbibliothekclients verwenden, um den Wert der x-ms-version header gesendeten anzuzeigen. Sie können auch den Wert von x-ms-version header sehen, wenn Sie Fiddler verwenden, um die Anforderungen von Ihrer Clientanwendung nachzuverfolgen.

Dieses Szenario tritt in der Regel auf, wenn Sie die neueste Version der Speicherclientbibliothek installieren und verwenden, ohne den Speicheremulator zu aktualisieren. Sie sollten entweder die neueste Version des Speicheremulators installieren oder Cloudspeicher anstelle des Emulators für Entwicklung und Tests verwenden.

Für die Ausführung des Speicheremulators sind Administratorrechte erforderlich.

Beim Ausführen des Speicheremulators werden Sie zur Eingabe von Administratoranmeldeinformationen aufgefordert. Dies tritt nur auf, wenn Sie den Speicheremulator zum ersten Mal initialisieren. Nachdem Sie den Speicheremulator initialisiert haben, benötigen Sie keine Administratorrechte, um ihn erneut auszuführen.

Weitere Informationen finden Sie unter Verwenden des Azure Storage-Emulators für Entwicklung und Tests. Sie können den Speicheremulator auch in Visual Studio initialisieren, wofür auch Administratorrechte erforderlich sind.

Bei der Installation des Azure SDK für .NET treten Probleme auf.

Wenn Sie versuchen, das SDK zu installieren, tritt beim Versuch, den Speicheremulator auf Ihrem lokalen Computer zu installieren, ein Fehler auf. Das Installationsprotokoll enthält eine der folgenden Meldungen:

  • CAQuietExec: Fehler: Zugriff auf SQL-instance nicht möglich
  • CAQuietExec: Fehler: Datenbank kann nicht erstellt werden

Die Ursache ist ein Problem mit der vorhandenen LocalDB-Installation. Standardmäßig verwendet der Speicheremulator LocalDB, um Daten beizubehalten, wenn er die Azure-Speicherdienste simuliert. Sie können Ihre LocalDB-instance zurücksetzen, indem Sie die folgenden Befehle in einem Eingabeaufforderungsfenster ausführen, bevor Sie versuchen, das SDK zu installieren.

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

Der delete Befehl entfernt alle alten Datenbankdateien aus früheren Installationen des Speicheremulators.

Sie haben ein anderes Problem mit einem Speicherdienst.

Wenn in den vorherigen Abschnitten zur Problembehandlung nicht das Problem mit einem Speicherdienst enthalten ist, sollten Sie den folgenden Ansatz zur Diagnose und Problembehandlung ihres Problems verwenden.

  • Überprüfen Sie Ihre Metriken, um festzustellen, ob sich das erwartete Baselineverhalten ändert. Anhand der Metriken können Sie möglicherweise ermitteln, ob das Problem vorübergehend oder dauerhaft ist und welche Speichervorgänge das Problem betrifft.
  • Sie können die Metrikinformationen verwenden, um Ihre serverseitigen Protokolldaten nach detaillierteren Informationen zu auftretenden Fehlern zu durchsuchen. Diese Informationen können Ihnen helfen, das Problem zu beheben und zu beheben.
  • Wenn die Informationen in den serverseitigen Protokollen nicht ausreichen, um das Problem erfolgreich zu beheben, können Sie die clientseitigen Protokolle der Speicherclientbibliothek verwenden, um das Verhalten Ihrer Clientanwendung und Tools wie Fiddler und Wireshark zu untersuchen, um Ihr Netzwerk zu untersuchen.

Weitere Informationen zur Verwendung von Fiddler finden Sie unter Anhang 1: Verwenden von Fiddler zum Erfassen von HTTP- und HTTPS-Datenverkehr.

Weitere Informationen zur Verwendung von Wireshark finden Sie in Anhang 2: Verwenden von Wireshark zum Erfassen von Netzwerkdatenverkehr.

Anhänge

In den Anhängen werden mehrere Tools beschrieben, die Bei der Diagnose und Problembehandlung von Problemen mit Azure Storage (und anderen Diensten) nützlich sein können. Diese Tools sind nicht Teil von Azure Storage, und einige sind Produkte von Drittanbietern. Daher werden die in diesen Anhängen erläuterten Tools nicht durch supportvertrag geschlossen, den Sie möglicherweise mit Microsoft Azure oder Azure Storage haben. Daher sollten Sie im Rahmen Ihres Evaluierungsprozesses die Lizenzierungs- und Supportoptionen untersuchen, die von den Anbietern dieser Tools zur Verfügung stehen.

Anhang 1: Verwenden von Fiddler zum Erfassen von HTTP- und HTTPS-Datenverkehr

Fiddler ist ein nützliches Tool zum Analysieren des HTTP- und HTTPS-Datenverkehrs zwischen Ihrer Clientanwendung und dem von Ihnen verwendeten Azure-Speicherdienst.

Hinweis

Fiddler kann HTTPS-Datenverkehr decodieren. Sie sollten die Fiddler-Dokumentation sorgfältig lesen, um zu verstehen, wie dies funktioniert und welche Auswirkungen auf die Sicherheit es hat.

Dieser Anhang enthält eine kurze exemplarische Vorgehensweise zum Konfigurieren von Fiddler zum Erfassen von Datenverkehr zwischen dem lokalen Computer, auf dem Sie Fiddler installiert haben, und den Azure-Speicherdiensten.

Nachdem Sie Fiddler gestartet haben, beginnt es mit der Erfassung von HTTP- und HTTPS-Datenverkehr auf Ihrem lokalen Computer. Im Folgenden sind einige nützliche Befehle zum Steuern von Fiddler aufgeführt:

  • Beenden Sie den Datenverkehr, und beginnen Sie mit der Erfassung von Datenverkehr. Wechseln Sie im menü Standard zu Datei, und wählen Sie dann Datenverkehr erfassen aus, um die Erfassung ein- und auszuschalten.
  • Speichern Sie erfasste Datenverkehrsdaten. Wechseln Sie im menü Standard zu Datei, wählen Sie Speichern und dann Alle Sitzungen aus. Auf diese Weise können Sie den Datenverkehr in einer Sitzungsarchivdatei speichern. Sie können ein Sitzungsarchiv später zur Analyse erneut laden oder es auf Anfrage an den Microsoft-Support senden.

Um die Menge des von Fiddler erfassten Datenverkehrs einzuschränken, können Sie Filter verwenden, die Sie auf der Registerkarte Filter konfigurieren. Der folgende Screenshot zeigt einen Filter, der nur Datenverkehr erfasst, der an den contosoemaildist.table.core.windows.net Speicherendpunkt gesendet wird:

Screenshot: Filter, der nur Datenverkehr erfasst, der an den contosoemaildist.table.core.windows.net-Speicherendpunkt gesendet wird.

Anhang 2: Verwenden von Wireshark zum Erfassen von Netzwerkdatenverkehr

Wireshark ist ein Netzwerkprotokollanalysetool, mit dem Sie detaillierte Paketinformationen für eine Vielzahl von Netzwerkprotokollen anzeigen können.

Das folgende Verfahren zeigt Ihnen, wie Sie detaillierte Paketinformationen für datenverkehr von dem lokalen Computer erfassen, auf dem Sie Wireshark installiert haben, für den Tabellendienst in Ihrem Azure-Speicherkonto.

  1. Starten Sie Wireshark auf Ihrem lokalen Computer.

  2. Wählen Sie im Abschnitt Start die lokale Netzwerkschnittstelle oder die Schnittstellen aus, die mit dem Internet verbunden sind.

  3. Wählen Sie Aufnahmeoptionen aus.

  4. Fügen Sie dem Textfeld Erfassungsfilter einen Filter hinzu. Beispielsweise konfiguriert Wireshark so, dass nur Pakete erfasst werden, host contosoemaildist.table.core.windows.net die an oder vom Tabellendienstendpunkt im Speicherkonto contosoemaildist gesendet werden. Sehen Sie sich die vollständige Liste der Erfassungsfilter an.

    Screenshot: Hinzufügen eines Filters zum Textfeld

  5. Klicken Sie auf Start. Wireshark erfasst jetzt alle Pakete, die an oder vom Tabellendienstendpunkt gesendet werden, während Sie Ihre Clientanwendung auf Ihrem lokalen Computer verwenden.

  6. Wenn Sie fertig sind, wählen Sie im Menü Standard die Option Capture Stop (Aufnahme>beenden) aus.

  7. Um dieerfassten Daten in einer Wireshark Capture-Datei zu speichern, wählen Sie > dateispeichern im menü Standard aus.

WireShark hebt alle Fehler hervor, die im Paketlistenfenster vorhanden sind. Sie können auch das Fenster Experteninformationen (wählen SieExperteninformationenanalysieren>) verwenden, um eine Zusammenfassung der Fehler und Warnungen anzuzeigen.

Screenshot: Fenster

Sie können die TCP-Daten auch so anzeigen, wie sie von der Anwendungsschicht angezeigt werden, indem Sie mit der rechten Maustaste auf die TCP-Daten klicken und TCP-Stream folgen auswählen. Dies ist nützlich, wenn Sie das Speicherabbild ohne Einen Erfassungsfilter erfasst haben. Weitere Informationen finden Sie unter Folgen von TCP-Streams.

Screenshot, der zeigt, wie die TCP-Daten so angezeigt werden, wie sie von der Anwendungsschicht angezeigt werden.

Hinweis

Weitere Informationen zur Verwendung von Wireshark finden Sie im Wireshark-Benutzerhandbuch.

Anhang 4: Anzeigen von Metriken und Protokolldaten mithilfe von Excel

Mit vielen Tools können Sie die Speichermetrikendaten aus Azure Table Storage in einem durch Trennzeichen getrennten Format herunterladen, das das Laden der Daten in Excel zum Anzeigen und Analysieren erleichtert. Storage Protokollierungsdaten aus Azure Blob Storage haben bereits ein durch Trennzeichen getrenntes Format, das Sie in Excel laden können. Sie müssen jedoch geeignete Spaltenüberschriften basierend auf den Informationen unter Storage Analytics Protokollformat und Storage Analytics Metriktabellenschema hinzufügen.

So importieren Sie Ihre Speicherprotokollierungsdaten in Excel, nachdem Sie sie aus Blob Storage heruntergeladen haben:

  • Wählen Sie im Menü Daten die Option Aus Text aus.
  • Navigieren Sie zu der Protokolldatei, die Sie anzeigen möchten, und wählen Sie Importieren aus.
  • Wählen Sie in Schritt 1 des Textimport-Assistentendie Option Trennzeichen aus.

Wählen Sie in Schritt 1 des Textimport-AssistentenSemikolon als einziges Trennzeichen aus, und wählen Sie doppelte Anführungszeichen als Textqualifizierer aus. Wählen Sie dann Fertig stellen aus, und wählen Sie aus, wo die Daten in Ihrer Arbeitsmappe platziert werden sollen.

Anhang 5: Überwachung mit Application Insights für Azure DevOps

Sie können das Application Insights-Feature für Azure DevOps auch als Teil Ihrer Leistungs- und Verfügbarkeitsüberwachung verwenden. Dieses Tool kann:

  • Stellen Sie sicher, dass Ihr Webdienst verfügbar und reaktionsfähig ist. Unabhängig davon, ob es sich bei Ihrer App um eine Website oder eine Geräte-App handelt, die einen Webdienst verwendet, kann sie Ihre URL alle paar Minuten von Standorten weltweit aus testen und Sie darüber informieren, ob ein Problem vorliegt.
  • Diagnostizieren Sie schnell Leistungsprobleme oder Ausnahmen in Ihrem Webdienst. Ermitteln Sie, ob cpu- oder andere Ressourcen gestreckt werden, rufen Sie Stapelablaufverfolgungen von Ausnahmen ab, und durchsuchen Sie einfach Protokollablaufverfolgungen. Wenn die Leistung der App unter die zulässigen Grenzwerte fällt, kann Microsoft Ihnen eine E-Mail senden. Sie können sowohl .NET- als auch Java-Webdienste überwachen.

Weitere Informationen finden Sie unter Was ist Application Insights?

Nächste Schritte

Weitere Informationen zu Analysen in Azure Storage finden Sie in den folgenden Ressourcen:

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.