Freigeben über

Microsoft Azure-Speicher: Überwachung, Diagnose und Problembehandlung (klassisch)

  • Artikel

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

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

Dieser Leitfaden richtet sich in erster Linie an Entwickler von Online-Diensten, die Azure-Speicherdienste verwenden, sowie an IT-Experten, die für die Verwaltung solcher Online-Dienste verantwortlich sind. Mit dieser Anleitung möchten wir:

  • Ihnen helfen, die Integrität und Leistungsfähigkeit Ihres Azure-Speicherkontos aufrechtzuerhalten
  • Ihnen die notwendigen Prozesse und Tools für die Diagnose an die Hand geben, ob ein Problem in einer Anwendung mit Azure Storage zusammenhängt.
  • Ihnen umsetzbare Anleitungen für die Lösung von Problemen in Verbindung mit Azure-Speicher bereitstellen

Notiz

Dieser Artikel basiert auf der Verwendung von Speicheranalysemetriken und Protokollen, die als klassische Metriken und Protokolle bezeichnet werden. Wir empfehlen, Azure Storage-Metriken und -Protokolle in Azure Monitor (statt Storage Analytics-Protokollen) zu verwenden. Weitere Informationen finden Sie in einem der folgenden Artikel:

Übersicht

Diagnose und Problembehandlung können in einer verteilten Anwendung, die in einer Cloudumgebung gehostet wird, 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 verwendet möglicherweise mehrere Speichertechnologien wie Microsoft Azure Storage Tables, Blobs, Warteschlangen oder Dateien zusätzlich zu anderen Datenspeichern wie relationalen und Dokumentdatenbanken.

Um solche Anwendungen erfolgreich zu verwalten, sollten Sie sie proaktiv überwachen und verstehen, wie sie alle Aspekte dieser Anwendungen und deren abhängige Technologien diagnostizieren und beheben können. Als Benutzer von Azure Storage-Diensten sollten Sie die Speicherdienste, die Ihre Anwendung verwendet, kontinuierlich auf unerwartete Verhaltensänderungen (z. B. langsamere als übliche Reaktionszeiten) überwachen und die Protokollierung verwenden, um detailliertere Daten zu sammeln und ein Problem im Detail zu analysieren. Die Diagnoseinformationen, die Sie von der Überwachung und Protokollierung erhalten, helfen Ihnen, die Ursache des Problems zu ermitteln, das ihre Anwendung festgestellt hat. Dann können Sie das Problem behandeln und die entsprechenden Schritte zur Beseitigung bestimmen. Azure Storage ist ein zentraler Azure-Dienst und bildet einen wichtigen Teil der meisten Lösungen, die Kunden in der Azure-Infrastruktur bereitstellen. Azure-Speicher beinhaltet Funktionen zur vereinfachten Überwachung, Diagnose und Problembehandlung von Speicherproblemen in Ihren cloudbasierten Anwendungen.

Wie diese Anleitung aufgebaut ist

Im Abschnitt "Überwachung Ihres Speicherdiensts " wird beschrieben, wie Sie den Status und die Leistung Ihrer Azure Storage-Dienste mithilfe von Azure Storage Analytics-Metriken (Speichermetriken) überwachen.

Im Abschnitt "Diagnose von Speicherproblemen " wird beschrieben, wie Sie Probleme mithilfe der Azure Storage Analytics-Protokollierung (Speicherprotokollierung) diagnostizieren. Außerdem wird beschrieben, wie Sie die clientseitige Protokollierung mithilfe der Einrichtungen in einer der Clientbibliotheken aktivieren, z. B. die Speicherclientbibliothek für .NET oder das Azure SDK für Java.

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

Der Abschnitt "Anleitung zur Problembehandlung" enthält Anleitungen zur Problembehandlung für einige der häufig auftretenden Speicherprobleme.

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.

Überwachung Ihres Speicherdiensts

Wenn Sie mit der Windows-Leistungsüberwachung vertraut sind, können Sie von Speichermetriken als einem Azure-Speicher-Pendant zu Windows-Leistungsüberwachungsindikatoren ausgehen. In Speichermetriken finden Sie einen umfassenden Satz von Metriken (Leistungsindikatoren in Windows Leistungsmonitor Terminologie), z. B. die Dienstverfügbarkeit, die Gesamtanzahl der Anforderungen an den Dienst oder den Prozentsatz der erfolgreichen Anforderungen an den Dienst. Eine vollständige Liste der verfügbaren Kennzahlen finden Sie im Thema zu den Kennzahlen zur Speicheranalyse – Tabellenschema. Sie können spezifizieren, ob der Speicherdienst die Metriken jede Stunde oder jede Minute sammeln und aggregieren soll. Weitere Informationen zur Metrik-Aktivierung und Überwachung Ihrer Speicherkonten finden Sie unter Aktivieren der Speichermetriken und Anzeigen von Metrikdaten.

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

Es wird empfohlen, Azure Monitor für Storage (Vorschau) zu überprüfen. Dieses Feature von Azure Monitor ermöglicht eine umfassende Überwachung ihrer Azure Storage-Konten, indem eine einheitliche Ansicht der Leistung, Kapazität und Verfügbarkeit Ihrer Azure Storage-Dienste bereitgestellt wird. Sie müssen nichts aktivieren oder konfigurieren und können diese Metriken aus den vordefinierten interaktiven Diagrammen und anderen darin enthaltenen Visualisierungen sofort anzeigen.

Der Speicherdienst versucht am besten, Metriken zu sammeln, aber möglicherweise nicht jeden Speichervorgang aufzuzeichnen.

Im Azure-Portal können Sie Metriken wie Verfügbarkeit, Gesamtanforderungen und durchschnittliche Latenzzahlen für ein Speicherkonto anzeigen. Zudem wurde eine Benachrichtigungsregel eingerichtet, um einen Administrator zu benachrichtigen, wenn die Verfügbarkeit unter ein bestimmtes Niveau sinkt. Bei der Anzeige dieser Daten ist ein möglicher Bereich für die Untersuchung der Prozentsatz des Tabellendiensterfolgs unter 100 % (weitere Informationen finden Sie unter " Metriken" mit niedrigen "PercentSuccess"- oder Analyseprotokolleinträgen mit Vorgängen mit dem Transaktionsstatus des Abschnitts "ClientOtherErrors ").

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

  • Erstellen einiger Basismetriken für die Anwendung, mit denen Sie aktuelle Daten vergleichen und wichtige Änderungen am Verhalten von Azure Storage und Ihrer Anwendung identifizieren können. Die Werte Ihrer Basismetriken sind in vielen Fällen anwendungsspezifisch, und Sie sollten diese festlegen, wenn Sie ihre Anwendung leistungstests.
  • Aufzeichnen von Minutenmetriken und deren Verwendung, um aktiv auf unerwartete Fehler und Anomalien zu überwachen, z. B. Spitzen bei Fehleranzahlen oder Anforderungsraten.
  • Aufzeichnung von Stundenmetriken und ihre Verwendung zur Überwachung von Durchschnittswerten wie durchschnittliche Fehlerzahlen und Anfrageraten.
  • Untersuchen potenzieller Probleme mithilfe von Diagnosetools, wie weiter unten im Abschnitt "Diagnose von Speicherproblemen " beschrieben.

Die Diagramme in der folgenden Abbildung illustrieren, wie die Durchschnittsberechnung für die Stundenmetrik Aktivitätsspitzen verstecken kann. Die Stundenmetriken scheinen eine konstante Anfragerate anzuzeigen, während die Minutenmetriken die wirklichen Schwankungen offenbaren.

Charts, die illustrieren, wie Aktivitätsspitzen bei der Durchschnittsberechnung für die Stundenmetrik ausgeblendet werden können.

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

Überwachung der Dienstintegrität

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

Das Azure-Portal kann auch Benachrichtigungen zu Vorfällen bereitstellen, die die verschiedenen Azure-Dienste beeinträchtigen.

Notiz

Diese Informationen waren bisher, zusammen mit Verlaufsdaten, auf dem Azure-Dienstdashboardverfügbar. Weitere Informationen zu Application Insights für Azure DevOps finden Sie in Anhang 5: Überwachung mit Application Insights für Azure DevOps.

Kapazitätsüberwachung

Speichermetriken speichern nur Kapazitätsmetriken für den Blob-Dienst, weil Blobs in der Regel den größten Teil der gespeicherten Daten ausmachen. Sie finden diese Daten in der $MetricsCapacityBlob Tabelle, wenn Sie die Überwachung für den Blob-Dienst aktiviert haben. Speichermetriken zeichnet diese Daten einmal pro Tag auf, und Sie können den Wert des Werts 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 über die Menge des verwendeten Speichers (Capacity gemessen in Bytes) und die aktuelle Anzahl von Containern (ContainerCount) und Blobs (ObjectCount) in dem Speicherkonto. Weitere Informationen zu den in der $MetricsCapacityBlob Tabelle gespeicherten Kapazitätsmetriken finden Sie unter Storage Analytics Metrics Table Schema.

Notiz

Sie sollten diese Werte überwachen, um früh zu erkennen, 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 zur Schätzung 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 Tabellen für Stunden- oder Minutenmetriken – $MetricsHourPrimaryTransactionsBlob, $MetricsMinutePrimaryTransactionsBlob$MetricsHourPrimaryTransactionsQueue$MetricsHourPrimaryTransactionsTable$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 (dies RowKey zeigt, ob die Zeile Metriken für den Dienst als Ganzes oder für einen bestimmten API-Vorgang enthält).

Jeder unter 100 % liegende Wert zeigt an, dass einige Speicheranfragen 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, dass sie Availability vorübergehend unter 100 % fallen, z. B. vorübergehende Servertimeouts, während der Dienst Partitionen zu besseren Lastenausgleichsanforderungen verschiebt. Die Wiederholungslogik in Ihrer Clientanwendung sollte solche zeitweiligen Bedingungen verarbeiten. Im Artikel "Protokollierte Speicheranalysen" und "Statusmeldungen" werden die Transaktionstypen aufgelistet, die speichermetriken in der Availability Berechnung enthalten sind.

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

Im Abschnitt zur Problembehandlung in diesem Handbuch werden einige allgemeine Speicherdienstprobleme im Zusammenhang mit der Verfügbarkeit beschrieben.

Leistungsüberwachung

Um die Leistung des Speicherdiensts zu überwachen, können Sie die folgenden Metriken aus den Stunden- und Minuten-Metriktabellen verwenden.

  • Die Werte in den AverageE2ELatency Und AverageServerLatency Spalten zeigen die durchschnittliche Zeit an, die der Speicherdienst oder der API-Vorgangstyp zum Verarbeiten von Anforderungen verwendet. AverageE2ELatency ist ein Maß für die End-to-End-Latenz, die die Zum Lesen der Anforderung benötigte Zeit und das Senden der Antwort zusätzlich zu der zeitaufwand für die Verarbeitung der Anforderung umfasst (umfasst daher die Netzwerklatenz, sobald die Anforderung den Speicherdienst erreicht hat); AverageServerLatency ist ein Maß für die Verarbeitungszeit und schließt daher alle Netzwerklatenz im Zusammenhang mit der Kommunikation mit dem Client aus. In den Metriken werden der Abschnitt "High AverageE2ELatency" und "Low AverageServerLatency " weiter unten in diesem Leitfaden erläutert, warum es einen signifikanten Unterschied zwischen diesen beiden Werten geben könnte.
  • Die Werte in den TotalIngress Und TotalEgress Spalten zeigen die Gesamtmenge der Daten in Bytes an, die in Ihren Speicherdienst oder über einen bestimmten API-Vorgangstyp ein- und aussteigen.
  • Die Werte in der TotalRequests Spalte zeigen die Gesamtanzahl der Anforderungen an, die der Speicherdienst des API-Vorgangs empfängt. TotalRequests ist die Gesamtanzahl der Anforderungen, die der Speicherdienst empfängt.

Normalerweise überwachen Sie unerwartete Änderungen in einem dieser Werte, da dies darauf hinweist, dass ein Problem auftritt, das eine Untersuchung erfordert.

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

Im Abschnitt zur Problembehandlung in diesem Handbuch werden einige allgemeine Speicherdienstprobleme im Zusammenhang mit der Leistung beschrieben.

Diagnose von Speicherproblemen

Es gibt verschiedene Möglichkeiten, um Probleme in Ihrer Anwendung zu erkennen. Dazu gehören:

  • Ein großer Fehler, der dazu führt, dass die Anwendung abstürzt oder nicht mehr funktioniert.
  • Erhebliche Änderungen von Basiswerten in den Metriken, die Sie überwachen, wie im vorherigen Abschnitt "Überwachen Ihres Speicherdiensts" beschrieben.
  • Berichte von Anwendungsbenutzern, dass bestimmte Vorgänge nicht wie erwartet abgeschlossen wurden oder dass einige Funktionen nicht funktionieren
  • In Ihrer Anwendung erzeugte Fehler, die in Protokollierungsdateien oder durch eine andere Benachrichtigungsmethode angezeigt werden

In der Regel fallen Probleme zu Azure-Speicherdiensten unter eine von vier weit gefassten Kategorien:

  • Ihre Anwendung hat ein Leistungsproblem, entweder von Ihren Benutzern gemeldet oder durch Änderungen der Leistungsmetriken offenbart.
  • Es gibt ein Problem mit der Azure-Speicher-Infrastruktur in einer oder mehrerer Regionen.
  • Ihre Anwendung tritt auf einen Fehler hin, der entweder von Ihren Benutzern gemeldet wird 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 Speicher-Emulators beziehen.

Die folgenden Abschnitte beschreiben die Schritte, die Sie befolgen sollten, um Probleme in jeder dieser vier Kategorien zu diagnostizieren und zu beheben. Der Abschnitt "Anleitung zur Problembehandlung" weiter unten in diesem Handbuch enthält ausführlichere Informationen zu einigen häufig auftretenden Problemen.

Probleme mit der Dienstintegrität

Probleme mit der Dienstintegrität liegen in der Regel außerhalb Ihrer Kontrolle. Die Azure-Portal enthält Informationen zu laufenden Problemen mit Azure-Diensten, einschließlich Speicherdiensten. Falls Sie sich beim Erstellen Ihres Speicherkontos für georedundante Speicher mit Lesezugriff entschieden haben, sollte Ihre Anwendung im Falle der Nichtverfügbarkeit Ihrer Daten im primären Speicherort vorübergehend auf die schreibgeschützte Kopie im sekundären Speicherort umschalten können. Um aus der sekundären Datei zu lesen, muss Ihre Anwendung zwischen der Verwendung der primären und sekundären Speicherorte wechseln und in einem modus mit eingeschränkter Funktionalität mit schreibgeschützten Daten arbeiten können. Mit den Azure Speicher-Clientbibliotheken können Sie eine Wiederholungsrichtlinie für das Lesen aus dem Sekundärspeicher definieren, falls der Primärort ausfällt. Ihre Anwendung muss auch erkennen können, ob die Daten am Sekundärort konsistent sind. Weitere Informationen finden Sie im Blogbeitrag Microsoft Azure-Speicher: Redundanzoptionen und Lesezugriff georedundanter Speicher.

Leistungsprobleme

Die Leistungsfähigkeit einer Anwendung kann subjektiv sein, vor allem aus der Benutzerperspektive. Daher ist es wichtig, Baseline-Metriken zur Verfügung zu haben, um Leistungsprobleme identifizieren zu können. Viele Faktoren können die Leistung eines Azure-Speicherdiensts aus der Client-Anwendungs-Perspektive beeinflussen. Diese Faktoren können im Speicherdienst, im Client oder in der Netzwerkinfrastruktur ausgeführt werden; Daher ist es wichtig, eine Strategie zur Identifizierung des Ursprungs des Leistungsproblems zu haben.

Nachdem Sie anhand der Messdaten ermittelt haben, wo die mögliche Ursache des Leistungsproblems liegt, können Sie anschließend die Protokollierungsdateien verwenden, um detaillierte Informationen zur Diagnose und weiteren Problembehandlung zu erhalten.

Der Abschnitt "Anleitung zur Problembehandlung" weiter unten in diesem Handbuch enthält weitere Informationen zu einigen häufig auftretenden leistungsbezogenen Problemen.

Fehlerdiagnose

Benutzer Ihrer Anwendung können Sie über Fehler informieren, die von der Clientanwendung gemeldet werden. Speichermetriken zeichnet auch die Anzahl verschiedener Fehlertypen von Ihren Speicherdiensten auf, z. B. NetworkError, ClientTimeoutError oder AuthorizationError. Während Speichermetriken nur die Anzahl der verschiedenen Fehlerarten verzeichnen, können Sie durch die Untersuchung von Serverseite, Clientseite und Netzwerkprotokollen weitere Informationen zu Einzelanfragen erhalten. In der Regel liefert der vom Speicherdienst zurückgegebene HTTP-Statuscode einen Hinweis auf den Grund für das Scheitern der Anfrage.

Notiz

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

Die folgenden Ressourcen sind nützlich für das Verständnis von speicherbezogenem Status und Fehlercodes:

Probleme mit dem Speicheremulator

Azure SDK enthält einen Speicheremulator, den Sie auf einer Entwicklungsworkstation ausführen können. Dieser Emulator simuliert den größten 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 "Anleitung zur Problembehandlung" dieses Handbuchs werden einige häufige Probleme beschrieben, die mit dem Speicher-Emulator aufgetreten sind.

Speicher-Protokollierungstools

Speicherprotokollierung stellt serverseitige Protokollierung von Speicheranfragen in Ihrem Azure-Speicherkonto bereit. Weitere Informationen zu Aktivierung serverseitiger Protokollierung und Zugriff auf die Protokollierungsdaten finden Sie unter Aktivieren der Speicherprotokollierung und Zugreifen auf Protokolldaten.

Mit der Speicher-Clientbibliothek für .NET können Sie clientseitige Protokollierungsdaten sammeln, die sich auf Speicheroperationen in Ihrer Anwendung beziehen. Weitere Informationen finden Sie unter Clientseitige Protokollierung mit der .NET Storage Client Library.

Hinweis

In einigen Fällen (wie SAS-Authentifizierungsfehler) kann ein Benutzer einen Fehler melden, für den Sie keine Anfragedaten in den serverseitigen Speicherprotokollen finden. Sie können die Protokollierungsfunktionen der Speicher-Clientbibliothek verwenden, um zu untersuchen, ob die Ursache des Problems im Client liegt, oder Überwachungstools verwenden, um das Netzwerk zu untersuchen.

Verwendung von Netzwerk-Protokollierungstools

Sie können den Verkehr zwischen Client und Server erfassen, um detaillierte Informationen über die Daten, die Client und Server austauschen, und die zugrunde liegenden Netzwerkbedingungen bereitzustellen. Nützliche Netzwerkprotokollierungstools sind:

In vielen Fällen reichen die Protokollierungsdaten aus der Speicherprotokollierung und der Speicher-Clientbibliothek aus, um ein Problem zu diagnostizieren, aber in einigen Szenarien können detailliertere Informationen benötigt werden, als diese Netzwerkprotokollierungstools bereitstellen können. Beispielsweise können Sie Fiddler zur Anzeige von HTTP- und HTTPS-Nachrichten verwenden. Anhand der Header- und Nutzlastdaten, die an die und von den Speicherdiensten gesendet werden, können Sie untersuchen, wie eine Clientanwendung Speicheroperationen wiederholt. Protokollierungsanalysatoren wie Wireshark operieren auf Paketebene und erlauben Ihnen dadurch die Anzeige von TCP-Daten, mit denen Sie Probleme bezüglich verlorener Pakete und Konnektivität beheben können.

End-to-End-Ablaufverfolgung

Durchgängige Verfolgung unter Verwendung einer Vielzahl von Protokollierungsdateien ist eine nützliche Technik für die Untersuchung möglicher Probleme. Sie können die Datums-/Uhrzeitinformationen aus Den Metrikdaten verwenden, um anzugeben, wo sie in den Protokolldateien nach detaillierten Informationen suchen können, um Ihnen bei der Problembehandlung zu helfen.

Korrelation von Protokollierungsdaten

Beim Anzeigen von Protokollen aus Clientanwendungen, Netzwerkablaufverfolgungen und serverseitiger Speicherprotokollierung ist es wichtig, Anforderungen in den verschiedenen Protokolldateien korrelieren zu können. Die Protokollierungsdateien enthalten eine Reihe von unterschiedlichen Feldern, die als Korrelationskennungen von Bedeutung sind. Die Clientanforderungs-ID ist das nützlichste Feld, das für die Korrelation von Einträgen in den verschiedenen Protokollen verwendet werden kann. Manchmal kann es jedoch hilfreich sein, entweder die Serveranforderungs-ID oder Zeitstempel zu verwenden. Die folgenden Abschnitte stellen weitere Informationen zu diesen Optionen bereit.

Clientanfrage-ID

Die Speicherclientbibliothek erzeugt 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 von Fiddler erfassten, ist die Clientanforderungs-ID in Anforderungsnachrichten als x-ms-client-request-id HTTP-Headerwert sichtbar.
  • Im Protokoll der serverseitigen Speicherprotokollierung wird die Clientanforderungs-ID in der Spalte „Client request ID“ angezeigt.

Hinweis

Mehrere Anforderungen können die gleiche Clientanforderungs-ID besitzen, da dieser Wert vom Client zugewiesen werden kann (obwohl die Speicher-Clientbibliothek automatisch einen neuen Wert zuweist). Bei Wiederholungsversuchen seitens des Clients nutzen alle Versuche die gleiche Clientanforderungs-ID. Bei einem vom Client gesendeten Batch verfügt der Batch über eine einzelne Clientanforderungs-ID.

Serveranfrage-ID

Der Speicherdienst generiert automatisch Serveranfrage-IDs.

  • Im serverseitigen Speicherprotokollierungsprotokoll wird die Serveranforderungs-ID in der Request ID header Spalte angezeigt.
  • In einer Netzwerkablaufverfolgung, z. B. einer von Fiddler erfassten, wird die Serveranforderungs-ID in Antwortmeldungen 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 der Serverantwort angezeigt.

Notiz

Der Speicherdienst teilt jeder empfangenen Anforderung immer eine eindeutige Serveranforderungs-ID zu, sodass jeder Wiederholungsversuch vom Client und jeder in einem Batch enthaltene Vorgang eine eindeutige Serveranforderungs-ID hat.

Im folgenden Codebeispiel wird die Verwendung einer benutzerdefinierten Clientanforderungs-ID veranschaulicht.

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 verbundene Protokolleinträge zu finden, aber achten Sie auf eventuellen Zeitversatz zwischen Client und Server. Suchen Sie etwa 15 Minuten nach passenden serverseitigen Einträgen, die auf dem Zeitstempel auf dem Client basieren. Denken Sie daran, dass die Blobmetadaten für die Metriken enthaltenden Blobs den Zeitbereich für die im Blob gespeicherten Metriken anzeigen. Dieser Zeitbereich ist nützlich, wenn Sie viele Metrikblobs für die gleiche Minute oder Stunde haben.

Anleitungen zur Problembehandlung

Dieser Abschnitt wird Sie bei der Diagnose und Behandlung einiger bekannter Probleme unterstützen, die auftreten können, wenn Ihre Anwendung Azure-Speicherdienste verwendet. In der Liste unten finden Sie die für Ihre spezifische Fragestellung relevanten Informationen.

Problembehandlung bei entscheidungsstruktur

Bezieht sich Ihr Problem auf die Leistungsfähigkeit eines Speicherdiensts?

Bezieht sich Ihr Problem auf die Verfügbarkeit eines Speicherdiensts?

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

Metriken zeigen niedrige PercentSuccess- oder Analyseprotokolleinträge mit Vorgängen mit dem Transaktionsstatus von ClientOtherErrors an.

Kapazitätsmetriken zeigen eine unerwartete Erhöhung der Speicherkapazitätsauslastung.

Ihr Problem tritt aus der Verwendung des Speicher-Emulators für die Entwicklung oder tests auf.

Beim Installieren des Azure SDK für .NET treten Probleme auf.

Sie haben ein anderes Problem mit einem Speicherdienst.

Metriken zeigen einen hohen AverageE2ELatency- und einen niedrigen AverageServerLatency-Wert an.

Die Abbildung unten aus dem Überwachungstool des Azure-Portals zeigt ein Beispiel, in dem die AverageE2ELatency wesentlich höher als die AverageServerLatency ist.

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

Der Speicherdienst berechnet die Metrik AverageE2ELatency nur für erfolgreiche Anforderungen und bezieht dabei im Gegensatz zu AverageServerLatency die Zeit ein, die der Client zum Senden der Daten und zum Empfangen der Bestätigung des Speicherdiensts benötigt. Daher könnte ein Unterschied zwischen AverageE2ELatency und AverageServerLatency entweder darauf zurückzuführen sein, dass die Clientanwendung langsam reagiert oder aufgrund von Bedingungen im Netzwerk reagiert.

Notiz

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

Untersuchung von Clientleistungsproblemen

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

Für die Tabellen- und Warteschlangendienste kann der Nagle-Algorithmus auch eine hohe AverageE2ELatency im Vergleich zu AverageServerLatency verursachen. Weitere Informationen finden Sie unter Nagle's Algorithm is Not Friendly to Small Requests. Sie können den Nagle-Algorithmus im Code deaktivieren, indem Sie die ServicePointManager Klasse im System.Net Namespace verwenden. Sie sollten dies tun, bevor Sie Aufrufe an die Tabellen- oder Warteschlangendienste in Ihrer Anwendung senden, da dies keinen Einfluss auf die bereits offenen 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 zu sehen, wie viele Anforderungen Ihre Clientanwendung übermittelt, und überprüfen Sie, ob sie allgemein ist. NET-bezogene Leistungsengpässe in Ihrem Client, z. B. CPU, .NET Garbage Collection, Netzwerkauslastung oder Arbeitsspeicher. Als Ausgangspunkt für die Fehlerbehandlung bei .NET-Clientanwendungen siehe Debuggen, Ablaufverfolgung und Profilerstellung.

Untersuchung von Netzwerklatenzproblemen

In der Regel wird eine hohe durchgängige Latenz durch die Übermittlungsbedingungen im Netzwerk verursacht. Sie können vorübergehende und dauerhafte Netzwerkprobleme wie verworfene Pakete mithilfe von Tools wie Wireshark untersuchen.

Weitere Informationen zur Verwendung von Wireshark zur Behandlung von Netzwerkproblemen finden Sie in Anhang 2: Verwenden von Wireshark zum Erfassen des Netzwerkdatenverkehrs.

Metriken zeigen einen niedrigen AverageE2ELatency- und einen niedrigen AverageServerLatency-Wert an, aber der Client erfährt hohe Latenz.

In diesem Szenario ist ein verzögertes Erreichen des Speicherdiensts durch die Speicheranfragen die wahrscheinlichste Ursache. Sie sollten untersuchen, warum Clientanfragen den Blob-Dienst nicht erreichen.

Ein möglicher Grund für das verzögerte Senden von Anfragen durch den Client ist z. B. eine begrenzte Anzahl verfügbarer Verbindungen oder Threads.

Überprüfen Sie außerdem, ob der Client mehrere Wiederholungsversuche durchführt, und untersuchen Sie den Grund, ob er vorhanden ist. Um zu ermitteln, ob der Client mehrere Wiederholungen ausführt, können Sie folgende Aktionen ausführen:

  • Überprüfen Sie die Storage Analytics-Protokolle. Wenn mehrere Wiederholungen auftreten, sehen Sie mehrere Vorgänge mit der gleichen Client-ID, aber unterschiedliche Serveranfrage-IDs.
  • Überprüfen Sie die Clientprotokolle. Bei einer ausführlichen Protokollierung wird auch angezeigt, dass ein erneuter Versuch erfolgt ist.
  • Debuggen Sie Ihren Code, und überprüfen Sie die Eigenschaften des Objekts, das OperationContext der Anforderung zugeordnet ist. Wenn der Vorgang erneut ausgeführt wurde, enthält die RequestResults Eigenschaft mehrere eindeutige Serveranforderungs-IDs. Sie können auch die Start- und Endzeiten der einzelnen Anforderungen überprüfen. Weitere Information finden Sie im Codebeispiel im Abschnitt Serveranfrage-ID.

Wenn das Problem nicht beim Client liegt, 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 in Anhang 2: Verwenden von Wireshark zum Erfassen des Netzwerkdatenverkehrs.

Metriken zeigen einen hohen AverageServerLatency-Wert an.

Im Fall von hoher AverageServerLatency bei Blob-Download-Anfragen sollten Sie die Speicherprotokollierungen verwenden, um herauszufinden, ob wiederholte Anfragen für den gleichen Blob (oder die gleiche Blob-Gruppe) vorliegen. Bei Blob-Uploadanforderungen sollten Sie untersuchen, welche Blockgröße der Client verwendet (z. B. Blöcke mit weniger als 64 K Größe können zu Mehraufwand führen, es sei denn, die Lesevorgänge befinden sich auch in weniger als 64 K-Blöcken) und wenn mehrere Clients Blöcke parallel in dasselbe Blob hochladen. Sie sollten auch die Metriken pro Minute auf Spitzen in der Anzahl der Anforderungen überprüfen, die zu einer Überschreitung der Skalierbarkeitsziele pro Sekunde führen. Weitere Informationen finden Sie unter Metriken, die eine Zunahme von PercentTimeoutError zeigen.

Wenn hohe AverageServerLatency für Blob-Downloadanforderungen angezeigt wird, wenn wiederholte Anforderungen für dasselbe Blob oder dieselbe Gruppe von Blobs vorhanden sind, sollten Sie diese Blobs mithilfe von Azure Cache oder dem Azure Content Delivery Network (CDN) zwischenspeichern. In Bezug auf Upload-Anfragen können Sie den Durchlauf durch Verwendung einer größeren Blockgröße verbessern. Für Abfragen in Tabellen kann auch clientseitiges Caching auf Clients implementiert werden, die die gleichen Abfrageoperationen durchführen und deren Daten sich nicht häufig ändern.

Hohe Werte bei der AverageServerLatency können auch ein Zeichen für schlecht entworfene Tabellen oder Abfragen sein, die zu Scanoperationen führen oder die dem angehängten/vorangestellten Gegenmuster folgen. Weitere Informationen finden Sie unter Metriken, die eine Zunahme von PercentThrottlingError zeigen.

Notiz

Hier finden Sie eine umfassende Leistungsprüfliste: Microsoft Azure Storage Performance and Skalierbarkeit Checkliste.

Sie stoßen auf unerwartete Verzögerungen bei der Nachrichtenübermittlung in einer Warteschlange

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

  • Stellen Sie sicher, dass die Anwendung die Nachrichten erfolgreich zur Warteschlange hinzufügt. Überprüfen Sie, ob die Anwendung die AddMessage Methode nicht mehrmals wiederholt, bevor sie erfolgreich ausgeführt wird. In den Protokollen der Speicherclientbibliothek werden alle wiederholten Versuche der Speicheroperationen angezeigt.
  • Vergewissern Sie sich, dass zwischen der Workerrolle keine Uhr schief ist, die die Nachricht der Warteschlange und der Workerrolle hinzufügt, die die Nachricht aus der Warteschlange liest. Eine Uhr-Schiefe macht es so aus, als ob es eine Verzögerung bei der Verarbeitung gibt.
  • Prüfen Sie, ob der Fehler bei der Workerrolle liegt, die die Nachrichten aus der Warteschlange liest. Wenn ein Warteschlangenclient die GetMessage Methode aufruft, aber nicht mit einer Bestätigung antwortet, bleibt die Nachricht bis zum Ablauf des invisibilityTimeout Zeitraums in der Warteschlange unsichtbar. An diesem Punkt steht die Nachricht wieder zur Verarbeitung zur Verfügung.
  • Prüfen Sie, ob die Länge der Warteschlange im Laufe der Zeit wächst. Dies kann auftreten, wenn Sie nicht über ausreichende Mitarbeiter verfügen, um alle Nachrichten zu verarbeiten, die andere Mitarbeiter in der Warteschlange platzieren. Überprüfen Sie außerdem die Metriken, um festzustellen, ob Löschanforderungen fehlschlagen, und die Anzahl der Benachrichtigungen, die auf wiederholte fehlgeschlagene Versuche zum Löschen der Nachricht hinweisen können.
  • Untersuchen Sie die Protokolle der Speicherprotokollierung auf Warteschlangenvorgänge, die für einen ungewöhnlich langen Zeitraum über höhere Werte für E2ELatency und ServerLatency verfügen.

Metriken zeigen einen Anstieg bei PercentThrottlingError an.

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

Wenn die Metrik "PercentThrottlingError " eine Erhöhung des Prozentsatzes von Anforderungen anzeigt, die mit einem Drosselungsfehler fehlschlagen, müssen Sie eines von zwei Szenarien untersuchen:

Eine Erhöhung von PercentThrottlingError tritt häufig gleichzeitig mit einer Erhöhung der Anzahl von Speicheranforderungen auf oder wenn Sie ihre Anwendung anfänglich laden. Dies kann sich auch im Client als HTTP-Status-Meldungen "503 Server Busy" oder "500 Operation Timeout" bei Speicheroperationen äußern.

Vorübergehender Anstieg bei PercentThrottlingError

Wenn Spitzen im Wert von PercentThrottlingError angezeigt werden, die mit Zeiträumen hoher Aktivität für die Anwendung übereinstimmen, können Sie eine exponentielle (nicht lineare) Back-Off-Strategie für Wiederholungen in Ihrem Client implementieren. Back-off-Wiederholungen reduzieren die sofortige Auslastung der Partition und helfen Ihrer Anwendung, Spitzen im Datenverkehr zu glätten. Weitere Informationen zur Implementierung von Wiederholungsrichtlinien unter Verwendung der Speicher-Clientbibliothek finden Sie unter Microsoft.Azure.Storage.RetryPolicies namespace.

Notiz

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

Permanenter Anstieg von PercentThrottlingError

Wenn ein konstant hoher Wert für PercentThrottlingError nach einer dauerhaften Erhöhung der Transaktionsvolumes oder beim Ausführen der anfänglichen Auslastungstests für Ihre Anwendung angezeigt wird, müssen Sie bewerten, wie Ihre Anwendung Speicherpartitionen verwendet und ob sie sich den Skalierbarkeitszielen für ein Speicherkonto nähert. Wenn z. B. Drosselungsfehler in einer Warteschlange angezeigt werden (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 Sie Drosselungsfehler in einer Tabelle feststellen, müssen Sie die Verwendung eines anderen Partitionsschemas für die Verteilung Ihrer Transaktionen über mehrere Partitionen mithilfe einer breiteren Auswahl von Partitionsschlüsseln in Erwägung ziehen. Eine häufige Ursache für dieses Problem ist das Vor-/Anfüge-Antimuster, bei dem Sie das Datum als Partitionsschlüssel auswählen, und dann werden alle Daten an einem bestimmten Tag in eine Partition geschrieben: unter Last kann dies zu einem Schreibengpässe führen. Verwenden Sie entweder ein anderes Partitionierungsmuster, oder prüfen Sie, ob Blobspeicher die bessere Lösung wäre. Überprüfen Sie außerdem, ob die Drosselung aufgrund von Spitzen in Ihrem Datenverkehr auftritt, und untersuchen Sie, wie Sie Ihr Anforderungsmuster glätten.

Wenn Sie Ihre Transaktionen über mehrere Partitionen verteilen, müssen Sie die für das Speicherkonto eingestellten Skalierbarkeitsgrenzen kennen. Wenn Sie z. B. zehn Warteschlangen verwendet haben und jeweils maximal 2.000 1 KB Nachrichten pro Sekunde verarbeiten, beträgt die Gesamtgrenze von 20.000 Nachrichten pro Sekunde für das Speicherkonto. Wenn Sie mehr als 20.000 Entitäten pro Sekunde verarbeiten müssen, erwägen Sie die Verwendung mehrerer Speicherkonten. Sie sollten auch berücksichtigen, dass sich die Größe Ihrer Anforderungen und Entitäten auf die Drosselung Ihrer Clients auswirkt, wenn der Speicherdienst Ihre Clients drosselt. Wenn Sie größere Anforderungen und Entitäten haben, werden Sie möglicherweise früher gedrosselt.

Ineffiziente Abfragemuster können ebenfalls dazu führen, dass Sie an die Skalierbarkeitsgrenzen für Tabellenpartitionen stoßen. Zum Beispiel benötigt eine Abfrage mit einem Filter, der nur ein Prozent der Einheiten in einer Partition auswählt, aber alle Objekte in einer Partition scannt, Zugriff auf jede Entität. Jede Entitätsanzeige wird gegen die Gesamtzahl der Transaktionen in dieser Partition gezählt; daher können Sie die Skalierbarkeitsziele einfach erreichen.

Hinweis

Ihr Leistungstest sollte ineffiziente Abfragemuster in Ihrer Anwendung aufdecken.

Metriken zeigen einen Anstieg bei PercentTimeoutError an.

Ihre Metriken zeigen einen Anstieg bei PercentTimeoutError für einen Ihrer Speicherdienste an. Zugleich erhält der Client ein hohes Volumen an HTTP-Status-Meldungen "500 Operation Timeout" von Speicheroperationen.

Hinweis

Timeout-Fehler werden vorübergehend angezeigt, während der Speicherdienst Lasten durch Verschieben einer Partition zu einem neuen Server ausgleicht.

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

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

Server-Timeouts zeigen ein Problem mit dem Speicherdienst an, das weitere Untersuchung erfordert. Sie können Metriken verwenden, um zu überprüfen, ob Sie die Skalierbarkeitsgrenzen für den Dienst erreichen, und alle Datenverkehrsspitzen zu identifizieren, die dieses Problem verursachen könnten. Wenn das Problem periodisch auftritt, kann es durch Lastenausgleich im Dienst verursacht sein. Wenn das Problem anhält und nicht dadurch verursacht wird, dass Ihre Anwendung die Dienstskalierbarkeitsgrenzen erreicht, sollten Sie eine Supportanfrage öffnen. Für 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 bei PercentNetworkError an.

Ihre Metriken zeigen einen Anstieg bei 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 bei einer Speicheranfrage des Client einen Netzwerkfehler entdeckt.

Die häufigste Ursache für diesen Fehler ist eine Trennung der Client-Verbindung vor Ablauf eines Timeouts im Speicherdienst. Untersuchen Sie den Code in Ihrem Client, um herauszufinden, warum und wann der Client die Verbindung zum Speicherdienst abbricht. Sie können auch Wireshark oder Tcping verwenden, um Netzwerkverbindungsprobleme vom Client zu untersuchen. Die Beschreibung dieser Tools finden Sie in den Anhänge.

Der Client empfängt HTTP 403 (Verboten)-Meldungen

Wenn Ihre Clientanwendung einen HTTP 403 (Verboten)-Fehler ausgibt, ist eine wahrscheinliche Ursache, dass der Client eine abgelaufene Shared Access Signature (SAS) verwendet, wenn er eine Speicheranfrage versendet. (Weitere mögliche Ursachen sind Zeitverzögerung, ungültige Schlüssel und leere Header). Wenn ein abgelaufener SAS-Schlüssel die Ursache ist, werden keine Einträge in den serverseitigen Speicherprotokolldaten angezeigt. Die folgende Tabelle zeigt ein Beispiel für eine von der Speicher-Clientbibliothek generierte Clientprotokollierung, die folgende Problemstellung veranschaulicht:

`Source` Ausführlichkeit Ausführlichkeit Clientanfrage-ID Operation Text
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 Fehler 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 der SAS-Token abläuft, bevor der Client den Token an den Server sendet:

  • In der Regel sollten Sie keine Startzeit festlegen, wenn Sie ein SAS für einen Client erstellen, der sofort verwendet werden soll. Wenn es kleine Taktunterschiede zwischen dem Host gibt, der die SAS mithilfe der aktuellen Zeit und des Speicherdiensts generiert, ist es möglich, dass der Speicherdienst ein SAS empfängt, das 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 der Speicherdienst zu einem SAS führen, das scheinbar früher als erwartet abläuft.
  • Stimmt der Versionsparameter im SAS-Schlüssel (z sv. B. =2015-04-05) mit der Version der verwendeten Speicherclientbibliothek überein? Sie sollten immer die neueste Version der Speicherclientbibliothek verwenden.
  • Wenn Sie Ihren Speicherzugriffsschlüssel neu erstellen, können dadurch vorhandene SAS-Token ungültig werden. Dieses Problem kann auftreten, wenn Sie SAS-Token mit einer langen Ablaufzeit zum Cachen von Clientanwendungen generieren.

Wenn Sie die Speicherclientbibliothek verwenden, um SAS-Token zu erstellen, ist es einfach, einen gültigen Token anzulegen. Wenn Sie allerdings die Speicher-REST-API verwenden und die SAS-Token manuell anlegen, hilft Ihnen das Thema Delegieren des Zugriffs mit einer Shared Access Signature weiter.

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

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

Das Objekt wurde vom Client oder einem anderen Prozess vorher 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 ergeben die Protokollierungsdaten, dass ein anderer Benutzer oder Prozess das Objekt gelöscht hat. In der serverseitigen Speicherprotokollierung zeigen die Spalten mit der Vorgangsart und den angeforderten Objektschlüsseln, wann 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 -Antwort (Nicht gefunden) führt, da der Client ein neues Objekt erstellt. Wenn der Client jedoch ein Blob erstellt, muss er in der Lage sein, den BLOB-Container zu finden. 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 die clientseitige Protokollierung aus der Speicher-Clientbibliothek verwenden, um genauer zu erkennen, wann der Client spezifische Anfragen an den Speicherdienst sendet.

Die folgende von der Speicherclientbibliothek erzeugte Clientprotokollierung verdeutlicht das Problem, wenn der Client den Container für das Blob, das er erstellt, nicht findet. Die Protokollierung enthält Details zu den folgenden Speicheroperationen:

Anfrage-ID Vorgang
07b26a5d-... DeleteIfExists methode zum Löschen des BLOB-Containers. Beachten Sie, dass dieser Vorgang eine HEAD Anforderung enthält, um das Vorhandensein des Containers zu überprüfen.
e2d06d78… CreateIfNotExists -Methode zum Erstellen des BLOB-Containers. Beachten Sie, dass dieser Vorgang eine HEAD Anforderung enthält, die das Vorhandensein des Containers überprüft. Die HEAD 404-Nachricht wird zurückgegeben, wird jedoch fortgesetzt.
de8b1c3c-... UploadFromStream -Methode zum Erstellen des Blobs. Die PUT Anforderung schlägt mit einer 404-Nachricht fehl.

Protokollierungseinträge:

Anfrage-ID Operation Text
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 aus der CreateIfNotExists Methode interleaviert (Anforderungs-ID e2d06d78...) mit den Anforderungen aus der UploadFromStream Methode (de8b1c3c-...). Diese Interleaving geschieht, da die Clientanwendung diese Methoden asynchron aufruft. Ändern Sie den asynchronen Code im Client, um sicherzustellen, dass er die Container erstellt, bevor er versucht, Daten an ein Blob in diesem Container hochzuladen. Idealerweise sollten Sie alle Ihre Container im Voraus erstellen.

Ein Problem mit der Shared Access Signature (SAS)-Authentifizierung

Wenn die Clientanwendung versucht, einen SAS-Schlüssel ohne die notwendigen Genehmigungen für den Vorgang zu verwenden, liefert der Speicherdienst eine HTTP 404-Meldung (Nicht gefunden) an den Client zurück. Gleichzeitig sehen Sie auch einen Wert ungleich Null für SASAuthorizationError die Metriken.

Die folgende Tabelle zeigt eine Muster-Serverprotokollierungsnachricht aus der Speicherprotokollierungsdatei:

Name Wert
Anfragestartzeit 2014-05-30T06:17:48.4473697Z
Vorgangsart GetBlobProperties
Anfragestatus SASAuthorizationError
HTTP-Statuscode 404
Authentifizierungsart SAS
Dienstart Blob
Anfrage-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>
Clientanfrage-ID <Clientanfrage-ID>

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

Clientseitiger JavaScript-Code verfügt nicht über die Zugriffsberechtigung für das Objekt

Wenn Sie einen JavaScript-Client verwenden und der Speicherdienst HTTP 404-Meldungen zurückliefert, überprüfen Sie die folgenden JavaScript-Fehler im Browser:

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

Notiz

Sie können die F12-Entwicklertools im Internet Explorer verwenden, um die zwischen Browser und Speicherdienst ausgetauschten Meldungen zu verfolgen, wenn Sie clientseitige JavaScript-Probleme behandeln.

Diese Fehler treten auf, weil im Webbrowser die Same Origin Policy als Sicherheitsbeschränkung implementiert ist, welche die Webseite daran hindert, eine API aus einer anderen Domäne aufzurufen.

Um das JavaScript-Problem zu umgehen, können Sie cross-Origin Resource Sharing (CORS) für den Speicherdienst konfigurieren, auf den der Client zugreift. Weitere Informationen finden Sie unter Cross-Origin Resource Sharing (CORS)-Support für die Azure-Speicherdienste.

Das folgende Codebeispiel zeigt, wie Sie Ihren Blob-Dienst so konfigurieren, dass JavaScript in der Contoso-Domäne ausgeführt wird, um auf ein Blob in Ihrem Blob-Speicherdienst zuzugreifen:

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.

In einigen Fällen können verlorene Netzwerkpakete dazu führen, dass der Speicherdienst HTTP 404-Nachrichten an den Client zurückliefert. Wenn Ihre Clientanwendung beispielsweise eine Entität aus dem Tabellendienst löscht, wird vom Client eine Speicher ausnahme ausgelöst, die eine Statusmeldung "HTTP 404 (Nicht gefunden)" aus dem Tabellendienst meldet. Wenn Sie die Tabelle im Tabellenspeicherdienst untersuchen, sehen Sie, dass der Dienst die Entität wie gefordert 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 finden, indem Sie in der Spalte in der request-id-header Protokolldatei suchen. Sie könnten die Metriken auch verwenden, um zu identifizieren, wann solche Fehler auftreten, und anschließend die Protokollierungsdateien durchsuchen, ausgehend vom Zeitpunkt, an dem die Metriken diesen Fehler aufgezeichnet haben. Dieser Protokolleintrag zeigt, dass das Löschen mit einer HTTP 404-Status-Meldung "Client Other Error" fehlgeschlagen ist. Derselbe Protokolleintrag enthält auch die vom Client generierte Anforderungs-ID in der client-request-id Spalte (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 von demselben Client. Dieser erfolgreiche Löschvorgang erfolgte unmittelbar vor der fehlgeschlagenen Löschanfrage.

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 den Vorgang automatisch erneut ausgeführt (unter Verwendung desselben 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 aus dem Tabellendienst erhält. Wenn das Problem intermittierend ist, sollten Sie den Fehler "HTTP (404) Nicht gefunden" eingrenzen und im Client protokollieren, aber dem Client die Fortführung erlauben.

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

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

Timestamp Vorgang Ergebnis Containername Clientanfrage-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 und erstellt dann sofort einen BLOB-Container unter demselben Namen neu: Die CreateIfNotExists Methode (Clientanforderungs-ID bc881924-...) schlägt schließlich mit dem HTTP 409 (Conflict)-Fehler fehl. Wenn ein Client Blobcontainer, Tabellen oder Warteschlangen löscht, gibt es einen kurzen Zeitraum, bevor der Name wieder verfügbar wird.

Beim Erstellen neuer Container sollte die Clientanwendung eindeutige Containernamen verwenden, wenn das Lösch-/Wiedererstellungsmuster übereinstimmt.

Metriken zeigen niedrigen PercentSuccess an, oder Analyse-Protokollierungseinträge enthalten Operationen mit Transaktionsstatus "ClientOtherErrors"

Die PercentSuccess -Metrik erfasst den Prozentsatz der erfolgreichen Vorgänge, basierend auf ihrem HTTP-Statuscode. Vorgänge mit Statuscodes von 2XX zählen als erfolgreich, während Vorgänge mit Statuscodes in den Bereichen 3XX, 4XX und 5XX als erfolglos gezählt werden und den Metrikwert "PercentSuccess" verringern. In den serverseitigen Speicher-Protokollierungsdateien sind diese Vorgänge mit dem Transaktionsstatus ClientOtherErrorserfasst.

Es ist wichtig zu beachten, dass diese Vorgänge erfolgreich abgeschlossen wurden und sich daher nicht auf andere Metriken wie verfügbarkeit auswirken. Hier sind einige Beispiele für Vorgänge, die erfolgreich ausgeführt werden, aber zu erfolglosen HTTP-Statuscodes führen:

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

Sie finden eine Liste allgemeiner REST-API-Fehlercodes, die von den Speicherdiensten auf der Seite zurückgegeben werden: Allgemeine REST-API-Fehlercodes.

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

Wenn Sie plötzliche, unerwartete Änderungen in der Kapazitätsauslastung Ihres Speicherkontos feststellen, können Sie die Gründe untersuchen, indem Sie zuerst einen Blick auf Ihre Verfügbarkeitsmetriken werfen. Beispielsweise könnte eine Erhöhung der Anzahl fehlgeschlagener Löschanforderungen, die Sie als anwendungsspezifische Bereinigungsvorgänge verwenden, nicht wie erwartet Platz freimachen (da z. B. die für die Bereinigung verwendeten SAS-Token abgelaufen sind) und zu einem Anstieg der Blobspeichergröße führen.

Ihre Probleme entstehen aus der Verwendung des Speicheremulators für Entwicklung oder Test

Normalerweise verwenden Sie den Speicheremulator während der Entwicklung und Tests, um die Anforderung für ein Azure-Speicherkonto zu vermeiden. Gängige Probleme, die bei der Verwendung des Speicheremulators auftreten können, sind:

Feature „X“ funktioniert im Speicheremulator nicht

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

Für die nicht vom Speicheremulator unterstützten Funktionen verwenden Sie den Azure-Speicherdienst in der Cloud.

Fehler „Der Wert für einen der HTTP-Header weist nicht das richtige Format auf“ bei Verwendung des Speicheremulators

Sie testen Ihre Anwendung, die die Speicherclientbibliothek für den lokalen Speicher-Emulator verwendet, und Methodenaufrufe, wie z CreateIfNotExists . B. Fehler mit der Fehlermeldung "Der Wert für einen der HTTP-Header ist nicht im richtigen Format." Dies gibt an, dass die version des verwendeten Speicher-Emulators die Version der verwendeten Speicherclientbibliothek nicht unterstützt. Die Speicherclientbibliothek fügt den Header x-ms-version allen anforderungen hinzu, die er vorgibt. Wenn der Speicher-Emulator den Wert im x-ms-version Header nicht erkennt, wird die Anforderung abgelehnt.

Sie können die Speicherbibliotheksclientprotokolle verwenden, um den Wert des x-ms-version header Sendens anzuzeigen. Sie können auch den Wert des Werts x-ms-version header sehen, wenn Sie Fiddler zum Nachverfolgen der Anforderungen von Ihrer Clientanwendung verwenden.

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

Das Ausführen des Speicheremulators erfordert Administratorrechte

Sie benötigen Administratorrechte, wenn Sie den Speicheremulator ausführen. Dies ist nur erforderlich, wenn Sie den Speicheremulator zum ersten Mal initialisieren. Nachdem Sie den Speicher-Emulator initialisiert haben, benötigen Sie keine Administratorrechte, um ihn erneut auszuführen.

Weitere Informationen finden Sie unter Einsatz des Azure-Speicheremulators für Entwicklung und Tests. Sie können den Speicheremulator auch in Visual Studio initialisieren. Dafür sind ebenfalls Administratorrechte erforderlich.

Sie stoßen bei der Installation des Azure SDK für .NET auf Probleme

Wenn Sie versuchen, das SDK zu installieren, tritt beim Versuch, den Speicher-Emulator auf Ihrem lokalen Computer zu installieren, fehl. Die Installationsprotokollierung beinhaltet eine der folgenden Nachrichten:

  • CAQuietExec: Fehler: Nicht in der Lage, auf SQL-Instanz zuzugreifen
  • CAQuietExec: Fehler: Nicht in der Lage, Datenbank anzulegen

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

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

Mit delete dem Befehl werden alle alten Datenbankdateien aus früheren Installationen des Speicher-Emulators entfernt.

Sie haben ein anderes Problem mit einem Speicherdienst

Wenn die vorherigen Abschnitte nicht Ihr Problem mit dem Speicherdienst enthalten, sollten Sie den folgenden Ansatz zur Diagnose und Fehlerbehebung Ihres Problems verfolgen.

  • Überprüfen Sie Ihre Metriken, um festzustellen, ob eine Änderung des erwarteten Basisplanverhaltens vorhanden ist. Anhand der Metriken können Sie möglicherweise feststellen, ob das Problem vorübergehend oder dauerhaft ist und welche Speichervorgänge sich auf das Problem auswirken.
  • Die Metrikinformationen unterstützen Sie bei der Suche nach serverseitigen Protokollierungsdaten, um weitere detaillierte Informationen über alle auftretenden Fehler zu erhalten. Diese Informationen können Ihnen dabei helfen, das Problem zu finden 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 in 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 des Netzwerkdatenverkehrs.

Anhänge

Die Anhänge beschreiben verschiedene Tools, die bei der Diagnose und Fehlerbehandlung von Problemen mit Azure Storage (und anderen Diensten) nützlich sein könnten. Diese Tools sind nicht Teil von Azure Storage, und einige sind Produkte von Drittanbietern. Daher werden die in diesen Appendices beschriebenen Tools nicht von einer Supportvereinbarung abgedeckt, die Sie möglicherweise mit Microsoft Azure oder Azure Storage haben. Daher sollten Sie im Rahmen Ihres Evaluierungsprozesses die von den Anbietern dieser Tools verfügbaren Lizenzierungs- und Supportoptionen überprüfen.

Anhang 1: Verwendung von Fiddler zur Erfassung von HTTP- und HTTPS-Verkehr.

Fiddler ist ein nützliches Tool für die Analyse des HTTP- und HTTPS-Datenverkehrs zwischen Ihrer Clientanwendung und dem von Ihnen verwendeten Azure-Speicherdienst.

Notiz

Fiddler kann HTTPS-Datenverkehr decodieren. Sie sollten die Fiddler-Dokumentation sorgfältig lesen, um zu verstehen, wie dies und ihre Sicherheitsauswirkungen sind.

Dieser Anhang enthält eine kurze Anleitung, wie Sie Fiddler konfigurieren, damit der Datenverkehr zwischen dem lokalen Rechner, auf dem Sie Fiddler installiert haben, und den Azure-Speicherdiensten erfasst wird.

Nachdem Sie Fiddler gestartet haben, beginnt die Erfassung von HTTP- und HTTPS-Datenverkehr auf dem lokalen Rechner. Hier folgen einige nützliche Befehle zur Steuerung von Fiddler:

  • Erfassung des Datenverkehrs stoppen und starten. Wechseln Sie im Hauptmenü zu "Datei ", und wählen Sie dann "Datenverkehr erfassen" aus, um die Aufnahme ein- und auszuschalten.
  • Erfasste Verkehrsdaten speichern. Wechseln Sie im Hauptmenü 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 neu laden oder es senden, wenn sie an den Microsoft-Support angefordert wird.

Um den Von Fiddler erfassten Datenverkehr 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, der einen Filter zeigt, der nur an den Speicherendpunkt „contosoemaildist.table.core.windows.net“ gesendeten Verkehr erfasst.

Anhang 2: Verwendung von Wireshark zur Erfassung von Netzwerkverkehr.

Wireshark ist ein Netzwerkprotokoll-Analysator, mit dem Sie detaillierte Paketinformationen für einen breiten Netzwerkprotokollbereich anzeigen können.

Das folgende Verfahren zeigt, wie Sie detaillierte Paketinformationen für Datenverkehr aus dem lokalen Computer erfassen, auf dem Sie Wireshark für den Tabellendienst Ihres Azure-Speicherkontos installiert haben.

  1. Starten Sie Wireshark auf Ihrem lokalen Computer.

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

  3. Wählen Sie "Aufnahmeoptionen" aus.

  4. Fügen Sie einen Filter zum Textfeld Capture Filter hinzu. Konfigurieren Sie z. B. 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 Erfassungsfilteran.

    Screenshot, der zeigt, wie Sie einen Filter zum Textfeld „Erfassungsfilter“ hinzufügen.

  5. Wählen Sie Starten aus. Wireshark erfasst nun 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 "Aufnahmestopp>" im Hauptmenü aus.

  7. Um die erfassten Daten in einer Wireshark Capture-Datei zu speichern, wählen Sie "Datei>speichern" im Hauptmenü aus.

WireShark wird alle aufgetretenen Fehler im Fenster Packetlist markieren. Sie können auch das Expert Info-Fenster (wählen Sie "Experteninformationen analysieren>") verwenden, um eine Zusammenfassung von Fehlern und Warnungen anzuzeigen.

Screenshot, der das Fenster „Experteninformationen“ zeigt, in dem Sie eine Zusammenfassung der Fehler und Warnungen anzeigen können.

Sie können die TCP-Daten auch so anzeigen, wie sie in der Anwendungsschicht vorliegen, indem Sie mit der rechten Maustaste auf die TCP-Daten klicken und Follow TCP Stream auswählen. Dies ist nützlich, wenn Sie Ihre Sicherung ohne Erfassungsfilter erfassen. Weitere Informationen finden Sie in unter Following TCP-Streams.

Screenshot, der zeigt, wie die TCP-Daten in der gleichen Ansicht wie in der Anwendungsschicht angezeigt werden.

Hinweis

Weitere Informationen zu Wireshark finden Sie im Wireshark-Benutzerhandbuch.

Anhang 4: Verwendung von Excel zur Anzeige von Metrik- und Protokollierungsdaten

Viele Tools ermöglichen das Herunterladen von Speichermetrikdaten aus dem Azure-Tabellenspeicher in einem abgegrenzten Format, wodurch die Daten einfach in Excel für die Anzeige und Analyse geladen werden können. Speicherprotokollierungsdaten von Azure Blob Storage verfügen bereits über ein durch Trennzeichen getrenntes Format, das Sie in Excel laden können. Sie müssen jedoch geeignete Spaltenüberschriften basierend auf den Informationen im Storage Analytics-Protokollformat und im Tabellenschema der Speicheranalysemetriken hinzufügen.

Um Speicherprotokollierungsdaten in Excel zu importieren, nachdem Sie diese aus dem BLOB-Speicher heruntergeladen haben, gehen Sie folgendermaßen vor:

  • 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-Assistenten die Option "Getrennt" aus.

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

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

Sie können die Application Insights-Funktion für Azure DevOps auch als Bestandteil der Leistungs- und Verfügbarkeitsüberwachung verwenden. Dieses Tool kann:

  • Sicherstellen, dass Ihr Webdienst verfügbar und reaktionsschnell 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 testen und Sie darüber informieren, ob ein Problem vorliegt.
  • Leistungsprobleme oder Ausnahmen in Ihrem Webdienst schnell diagnostizieren. Finden Sie heraus, ob für CPU oder andere Ressourcen Stretching durchgeführt wird, gewinnen Sie Stapelnachverfolgungen aus Ausnahmen, und durchsuchen Sie ganz einfach Protokollablaufverfolgungen. Wenn die Leistung der Anwendung unter akzeptable 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 unter 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.