Storage-Performance untersuchen? Metriken, Logs und Fehler prüfen

Ein Storage-Problem kann eine langsame erfolgreiche Anfrage, ein falscher Pfad oder ein dienstseitiger Fehler sein. Metriken zeigen das Muster über die Zeit; Request-Logs zeigen die konkrete Operation und Antwort dahinter.

Verwende stctmonitorweu, monitor-demo und law-ctmonitorweu aus Log Analytics konfigurieren. Die Blob-Diagnoseeinstellung muss weiterhin StorageRead, StorageWrite und StorageDelete erfassen. Verwende überall deinen tatsächlichen global eindeutigen Kontonamen.

Metriken vergleichen

Lade bei Bedarf monitor-check.txt in monitor-demo hoch und lade die Datei mehrmals herunter. Öffne Storage account → Monitoring → Metrics, wähle den Blob-Namespace/Dienstbereich und Last hour mit einer Granularität von einer Minute.

Vergleiche diese Metriken bei unterschiedlichen Einheiten in getrennten Diagrammen:

Metrik	Aggregation	Untersuchungszweck
Transactions	Sum	Anfragevolumen; nach API name oder Response type aufteilen.
Availability	Average	Einstufung der Anfrageverfügbarkeit durch den Dienst im Intervall.
Success E2E Latency	Average	Vom Dienst beobachtete Dauer erfolgreicher Anfragen einschließlich transferbedingter Wartezeit.
Success Server Latency	Average	Verarbeitungszeit erfolgreicher Anfragen innerhalb des Speicherdienstes.

Filtere Latenzdiagramme vor dem Vergleich auf dieselbe API, beispielsweise GetBlob. Ein Abstand zwischen beiden Werten deutet auf Zeit außerhalb der internen Dienstverarbeitung hin. Ergänze Anwendungs- und Netzwerkdaten; der Wert misst nicht die vollständige Antwortzeit im Browser. Mit einer kleinen Lab-Datei kann die Latenz sehr niedrig und fast konstant sein.

Screenshot 1: Blob-Metriken mit aktuellen Transaktionen und beiden Latenzwerten für denselben Zeitraum und dieselbe API.

Erkennbaren Fehler erzeugen

Öffne Azure Cloud Shell → Bash. Dieses Lab nutzt den bereits im Storage-Trip aktivierten Kontoschlüsselzugriff. Mit deinem Lab-Owner-/Contributor-Konto kann die CLI den Schlüssel automatisch abrufen; du musst ihn nicht kopieren.

az account set --subscription 'CloudTrips TEST'
az storage blob download \
  --account-name stctmonitorweu \
  --container-name monitor-demo \
  --name cloudtrips-deliberately-missing.txt \
  --file /tmp/cloudtrips-deliberately-missing.txt \
  --auth-mode key

Dieser Blob soll nicht existieren. Erwartet wird BlobNotFound / HTTP 404. Notiere die UTC-Zeit. Erhältst du stattdessen einen Berechtigungs- oder Netzwerkfehler, behebe diesen zuerst. Bei einem Konto mit ausschließlich Entra-Zugriff verwendest du --auth-mode login mit der Benutzerrolle Storage Blob Data Reader und wartest auf die Übernahme der Rolle.

Anfrage hinter dem Fehler finden

Öffne nach der Datenaufnahme law-ctmonitorweu → Logs, wähle Last hour und führe aus:

StorageBlobLogs
| where TimeGenerated > ago(1h)
| where AccountName == "stctmonitorweu"
| where toint(StatusCode) >= 400
| project TimeGenerated, OperationName, StatusCode, StatusText,
          DurationMs, AuthenticationType, Uri
| order by TimeGenerated desc

Suche den Datensatz für cloudtrips-deliberately-missing.txt. Die CLI kann zuerst Blob-Eigenschaften abfragen; die Operation heißt dann möglicherweise GetBlobProperties statt GetBlob. URI, Zeit und Status verbinden diesen Datensatz mit deinem Test.

Screenshot 2: Fehlerabfrage mit dem fehlenden Blob und Status 404.

Kehre zu Transactions zurück, entferne einen eventuell gesetzten GetBlob-Filter und teile nach Response type auf. Clientfehler können auftreten, während die Dienst-Availability hoch bleibt: Ein fehlender Blob ist eine gültige Dienstantwort. Die Verfügbarkeitseinstufung dieser Metrik unterscheidet sich von der Erfolgserwartung deiner Anwendung.

Vergleiche Ergebnisse mit dieser Zusammenfassung:

StorageBlobLogs
| where TimeGenerated > ago(1h)
| where AccountName == "stctmonitorweu"
| summarize Requests=count(), AverageMs=avg(DurationMs), P95Ms=percentile(DurationMs, 95)
    by OperationName, StatusCode
| order by Requests desc

P95 ist die Dauer, bei oder unter der ungefähr 95 % dieser Anfragen liegen. Vergleiche gleiche Operationen und Statuscodes; mit wenigen Stichproben sagt ein Perzentil wenig über normales Verhalten aus. Untersuche bei 403 Authentifizierung und Berechtigungen, bei 404 den angefragten Pfad und bei 5xx Dienstzustand und Wiederholungsversuche.

Abschluss

Behalte Konto und Workspace, solange andere Monitoring-Trips darauf aufbauen. Endet hier dein Storage-Lab, entferne Diagnoseeinstellung und Testwarnungsregeln. Lösche das Konto, sobald du seine Daten nicht mehr brauchst. Solange Diagnosen aktiviert sind und Anfragen eintreffen, werden weiter Logs aufgenommen.