Zur Protokollierung der Speicheranalyse
Dieser Artikel wurde maschinell übersetzt. Wenn Sie die englische Version des Artikels anzeigen möchten, aktivieren Sie das Kontrollkästchen Englisch. Sie können den englischen Text auch in einem Popupfenster anzeigen, indem Sie den Mauszeiger über den Text bewegen.
Übersetzung
Englisch

Informationen zur Protokollierung durch die Speicheranalyse

 

Die Speicheranalyse protokolliert ausführliche Informationen über erfolgreiche und fehlgeschlagene Anforderungen an einen Speicherdienst. Anhand dieser Informationen können einzelne Anforderungen überwacht und Probleme mit einem Speicherdienst diagnostiziert werden. Anforderungen werden auf Grundlage der besten Leistung protokolliert.

Zum Verwenden der Speicheranalyse müssen Sie sie einzeln für jeden zu überwachenden Dienst aktivieren. Aktivieren Sie dieses aus der Azure-Verwaltungsportal; ausführliche Informationen finden Sie unter ein Speicherkonto Überwachen. Sie können die Speicheranalyse auch programmgesteuert über die REST-API oder die Clientbibliothek aktivieren. Verwenden der Abrufen von Blob-Diensteigenschaften, Abrufen von Warteschlangendiensteigenschaften, und Get Table Service Properties Vorgänge zum Aktivieren der Speicheranalyse für jeden Dienst.

Protokolleinträge werden erstellt, nur dann, wenn Anforderungen für den Dienstendpunkt. Wenn ein Speicherkonto Aktivität im BLOB-Endpunkt, aber nicht in die Tabelle oder Warteschlange Endpunkte enthält, werden beispielsweise nur Protokolle für den Blob-Dienst erstellt.

System_CAPS_noteHinweis

Speicheranalyse-Protokollierung ist derzeit nur für den Blob, Warteschlange und Tabelle verfügbar.

Die folgenden Typen von authentifizierten Anforderungen werden protokolliert:

  • Erfolgreiche Anforderungen

  • Fehlgeschlagene Anforderungen, einschließlich Timeout-, Drosselungs-, Netzwerk-, Autorisierungs- und anderer Fehler

  • Anforderungen mithilfe einer SAS (Shared Access Signature), einschließlich fehlgeschlagener und erfolgreicher Anforderungen.

  • Anforderungen von Analysedaten

Anforderungen, die durch die Speicheranalyse selbst erfolgen, z. B. Protokollerstellung oder -löschung, werden nicht protokolliert. Eine vollständige Liste der protokollierten Daten finden Sie unter der Protokollierte Speicheranalysevorgänge und Statusmeldungen und Protokollformat der Speicheranalyse Themen.

Die folgenden Typen von anonymen Anforderungen werden protokolliert:

  • Erfolgreiche Anforderungen

  • Serverfehler

  • Timeoutfehler für Client und Server

  • Mit dem Fehlercode 304 (Nicht geändert) fehlgeschlagene GET-Anforderungen

Alle anderen fehlgeschlagenen anonymen Anforderungen werden nicht protokolliert. Eine vollständige Liste der protokollierten Daten finden Sie unter der Protokollierte Speicheranalysevorgänge und Statusmeldungen und Protokollformat der Speicheranalyse Themen.

Alle Protokolle befinden sich im Block-Blobs in einem Container namens $logs, dieser wird automatisch erstellt, wenn die Speicheranalyse für ein Speicherkonto aktiviert ist. Die $logs -Container befindet sich im Blob-Namespace des Speicherkontos, z. B.: http://<accountname>.blob.core.windows.net/$logs. Dieser Container kann nicht gelöscht werden, nachdem die Speicheranalyse aktiviert wurde; sein Inhalt kann jedoch gelöscht werden.

System_CAPS_noteHinweis

Die $logs Container wird nicht angezeigt, wenn ein containerauflistungsvorgang wie z. B. der Listencontainer-Vorgang ausgeführt wird. Der Zugriff auf ihn muss direkt erfolgen. Beispielsweise können den Liste Blobs Vorgang auf die Blobs in der $logs Container.

Wenn Anforderungen protokolliert werden, lädt die Speicheranalyse Zwischenergebnisse als Blöcke hoch. Die Speicheranalyse führt regelmäßig Commits dieser Blöcke aus und macht sie als BLOB verfügbar.

Für Protokolle, die in derselben Stunde erstellt werden, können doppelte Einträge vorhanden sein. Um festzustellen, ob ein Eintrag ein Duplikat durch Prüfung ist die RequestId und Operation Anzahl.

Jedes Protokoll wird im folgenden Format geschrieben:

<service-name>/YYYY/MM/DD/hhmm/<counter>.log

In der folgenden Tabelle werden die einzelnen Attribute im Protokollnamen beschrieben:

Attribut

Beschreibung

<service-name>

Der Name des Speicherdiensts. Beispiel: blob, table, oder queue

YYYY

Die vierstellige Jahresangabe für das Protokoll. Beispiel: 2011

MM

Die zweistellige Monatsangabe für das Protokoll. Beispiel: 07

DD

Die zweistellige Angabe des Tags für das Protokoll. Beispiel: 31

hh

Die zweistellige Angabe der Stunde des Beginns der Protokolle im 24-Stunden-Forrmat (UTC). Beispiel: 18

mm

Die zweistellige Zahl, mit der die Anfangsminute der Protokolle angegeben wird.

System_CAPS_noteHinweis

Dieser Wert wird in der aktuellen Version der Speicheranalyse nicht unterstützt, und sein Wert immer 00.

<counter>

Ein nullbasierter Zähler mit sechs Stellen, der die Anzahl der im Zeitraum von einer Stunde für den Speicherdienst generierten Protokoll-BLOBs angibt. Dieser Zähler beginnt bei 000000. Beispiel: 000001

In dem folgenden vollständigen Beispielprotokollnamen sind alle oben aufgeführten Beispiele enthalten:

blob/2011/07/31/1800/000001.log

Der folgende Beispiel-URI kann für den Zugriff auf das obige Protokoll verwendet werden:

https://<accountname>.blob.core.windows.net/$logs/blob/2011/07/31/1800/000001.log

Wenn eine Speicheranforderung protokolliert wird, gibt der resultierende Protokollname die Stunde wieder, zu der der angeforderte Vorgang abgeschlossen wurde. Beispielsweise würde eine GetBlob-Anforderung auf 7/31/2011 um 6:30 Uhr abgeschlossen wurde, das Protokoll mit dem folgenden Präfix geschrieben werden: blob/2011/07/31/1800/

Alle Protokoll-BLOBs werden mit Metadaten gespeichert, mit deren Hilfe die im BLOB enthaltenen Protokollierungsdaten ermittelt werden können. In der folgenden Tabelle werden die einzelnen Metadatenattribute beschrieben:

Attribut

Beschreibung

LogType

Gibt an, ob das Protokoll Informationen über Lese-, Schreib- oder Löschvorgänge enthält. Dieser Wert kann einen Typ oder eine durch Kommas getrennte Kombination aller drei Typen enthalten.

Beispiel 1: write

Beispiel 2: read,write

Beispiel 3: read,write,delete

StartTime

Den frühesten Zeitpunkt eines Eintrags in das Protokoll in Form eines YYYY-MM-DDThh:mm:ssZ. Beispiel: 2011-07-31T18:21:46Z

EndTime

Der letzte Zeitpunkt eines Eintrags in das Protokoll in Form eines YYYY-MM-DDThh:mm:ssZ. Beispiel: 2011-07-31T18:22:09Z

LogVersion

Die Version des Protokollformats. Derzeit ist der einzige unterstützte Wert: 1.0

In der folgenden Liste werden alle Beispielmetadaten unter Verwendung der obigen Beispiele dargestellt:

  • LogType=write

  • StartTime=2011-07-31T18:21:46Z

  • EndTime=2011-07-31T18:22:09Z

  • LogVersion=1.0

Alle Daten in der $logs Container kann mithilfe des Blob-Diensts-APIs zugegriffen werden, einschließlich der .NET APIs von Azure verwalteten Bibliothek. Der Speicherkontoadministrator kann Protokolle lesen und löschen, er kann jedoch keine Protokolle erstellen oder aktualisieren. Beim Abfragen eines Protokolls können die Metadaten und der Name des Protokolls verwendet werden. Die Protokolle für eine bestimmte Stunde können außerhalb der Reihenfolge angezeigt werden, die Metadaten geben jedoch immer den Zeitraum der Einträge in einem Protokoll an. Daher können Sie beim Suchen eines bestimmten Protokolls eine Kombination aus Protokollnamen und Metadaten verwenden.

Anzeigen:
© 2016 Microsoft