Azure Storage Analytics-Protokollierung

  • Artikel

Storage Analytics protokolliert ausführliche Informationen zu erfolgreichen und nicht erfolgreichen Anforderungen an einen Speicherdienst. Anhand dieser Informationen können einzelne Anforderungen überwacht und Probleme mit einem Speicherdienst untersucht werden. Anforderungen werden auf Grundlage der besten Leistung protokolliert. Das bedeutet, dass die meisten Anforderungen einen Protokolleintrag zur Folge haben. Die Vollständigkeit und Aktualität von Storage Analytics-Protokollen werden jedoch nicht garantiert.

Hinweis

Wir empfehlen, Azure Storage-Protokolle in Azure Monitor (statt Storage Analytics-Protokollen) zu verwenden. Weitere Informationen finden Sie in einem der folgenden Artikel:

Die Storage Analytics-Protokollierung ist für Ihr Speicherkonto nicht standardmäßig aktiviert. Sie können sie im Azure-Portal oder mithilfe von PowerShell oder der Azure CLI aktivieren. Eine Schrittanleitung finden Sie unter Aktivieren und Verwalten von Azure Storage Analytics-Protokollen (klassisch).

Sie können Azure Storage Analytics auch programmgesteuert über die REST-API oder Clientbibliothek aktivieren. Über die Vorgänge Get Blob Service Properties, Get Queue Service Properties und Get Table Service Properties können Sie Storage Analytics für jeden Dienst aktivieren. Ein Beispiel für die Aktivierung von Storage Analytics-Protokollen mithilfe von .NET finden Sie unter Aktivieren von Protokollen.

Protokolleinträge werden nur erstellt, wenn Anforderungen für den Dienstendpunkt gestellt wurden. Wenn ein Speicherkonto beispielsweise Aktivität im Blobendpunkt, jedoch nicht im Tabellen- oder Warteschlangenendpunkt aufweist, werden nur Protokolle für den Blob-Dienst erstellt.

Hinweis

Die Storage Analytics-Protokollierung ist derzeit nur für Blob-, Warteschlangen- und Tabellenspeicherdienste verfügbar. Storage Analytics-Protokollierung ist außerdem für Premium-Leistung von BlockBlobStorage-Konten verfügbar. Allerdings ist sie für allgemeine v2-Konten (GPv2) mit Premium-Leistung nicht verfügbar.

Erfasste Anforderungen bei der Protokollierung

Protokollierung authentifizierter Anforderungen

Die folgenden Typen authentifizierter Anforderungen werden protokolliert:

  • Erfolgreiche Anforderungen

  • Fehlerhafte Anforderungen, einschließlich Timeout-, Drosselungs-, Netzwerk- und Autorisierungsfehler sowie anderer Fehler

  • Anforderungen mithilfe einer SAS (Shared Access Signature) oder mit OAuth, einschließlich fehlerhafter 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 ist in den Themen Protokollierte Speicheranalysevorgänge und Statusmeldungen und Protokollformat der Speicheranalyse dokumentiert.

Protokollieren anonymer Anforderungen

Die folgenden Typen anonymer Anforderungen werden protokolliert:

Hinweis

Storage Analytics protokolliert alle internen Aufrufe der Datenebene. Aufrufe vom Azure Storage-Ressourcenanbieter werden ebenfalls protokolliert. Um diese Anforderungen zu identifizieren, suchen Sie in der Anforderungs-URL nach der Abfragezeichenfolge <sk=system-1>.

Wie Protokolle gespeichert werden

Alle Protokolle werden in Blockblobs in einem Container mit der Bezeichnung $logs gespeichert, der automatisch erstellt wird, wenn Storage Analytics für ein Speicherkonto aktiviert ist. Der Container $logs befindet sich im Blobnamespace 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 hingegen gelöscht werden. Wenn Sie über das Tool zum Durchsuchen des Speichers direkt zu diesem Container navigieren, werden alle Blobs angezeigt, die Ihre Protokollierungsdaten enthalten.

Hinweis

Der Container $logs wird nicht angezeigt, wenn ein Containerauflistungsvorgang durchgeführt wird, z. B. der Vorgang „List Containers“. Der Zugriff auf ihn muss direkt erfolgen. Beispielsweise können Sie den Vorgang „List Blobs“ verwenden, um auf die Blobs im Container $logs zuzugreifen.

Sobald 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. Aufgrund der Häufigkeit, mit der der Speicherdienst die Protokollwriter leert, kann es bis zu einer Stunde dauern, bis die Protokolldaten in den Blobs im Container $logs angezeigt werden. Für Protokolle, die in derselben Stunde erstellt werden, können doppelte Einträge vorhanden sein. Sie können feststellen, ob ein Datensatz ein Duplikat ist, indem Sie RequestId und Vorgangsnummer prüfen.

Bei einer großen Menge an Protokolldaten mit mehreren Dateien pro Stunde können Sie anhand der Blobmetadaten ermitteln, welche Daten das Protokoll enthält, indem Sie die Blobmetadatenfelder untersuchen. Dies ist auch deshalb nützlich, weil es in manchen Fällen zu Verzögerungen beim Schreiben von Daten in die Protokolldateien kommen kann: Die Blobmetadaten bieten eine genauere Angabe des Blobinhalts als der Blobname.

Mit den meisten Tools zum Durchsuchen des Speichers können Sie die Metadaten von Blobs anzeigen. Zudem können Sie diese Informationen über PowerShell oder programmgesteuert anzeigen. Der folgende PowerShell-Codeausschnitt ist ein Beispiel für die Filterung der Liste mit Protokollblobs nach dem Namen, um einen Zeitpunkt anzugeben, und nach Metadaten, um nur die Protokolle zu identifizieren, die write-Vorgänge enthalten.

Get-AzStorageBlob -Container '$logs' |  
Where-Object {  
    $_.Name -match 'blob/2014/05/21/05' -and   
    $_.ICloudBlob.Metadata.LogType -match 'write'  
} |  
ForEach-Object {  
    "{0}  {1}  {2}  {3}" -f $_.Name,   
    $_.ICloudBlob.Metadata.StartTime,   
    $_.ICloudBlob.Metadata.EndTime,   
    $_.ICloudBlob.Metadata.LogType  
}

Informationen zum programmgesteuerten Auflisten von Blobs finden Sie unter Auflisten von Blobressourcen und Festlegen und Abrufen von Eigenschaften und Metadaten für Blobressourcen.

Benennungskonventionen für Protokolle

Jedes Protokoll wird im folgenden Format geschrieben:

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

In der folgenden Tabelle werden alle Attribute im Protokollnamen beschrieben:

attribute 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 Tagesangabe für das Protokoll. Beispiel: 31
hh Die zweistellige Angabe der Stunde des Protokollbeginns im 24-Stunden-Format (UTC). Beispiel: 18
mm Die zweistellige Zahl, mit der die Anfangsminute der Protokolle angegeben wird. Hinweis: Dieser Wert wird in der aktuellen Version von Storage Analytics nicht unterstützt und entspricht 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 vorherige 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. Wenn eine GetBlob-Anforderung z. B. am 31.7.2011 um 18:30 Uhr abgeschlossen wurde, wird das Protokoll mit dem folgenden Präfix geschrieben: blob/2011/07/31/1800/

Protokollmetadaten

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:

attribute 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 Der erste Zeitpunkt eines Eintrags im Protokoll, im Format YYYY-MM-DDThh:mm:ssZ. Beispiel: 2011-07-31T18:21:46Z
EndTime Der letzte Zeitpunkt eines Eintrags im Protokoll, im Format YYYY-MM-DDThh:mm:ssZ. Beispiel: 2011-07-31T18:22:09Z
LogVersion Die Version des Protokollformats.

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

Protokolleinträge

In den folgenden Abschnitten finden Sie einen Beispielprotokolleintrag für jeden unterstützten Azure Storage-Dienst.

Beispielprotokolleintrag für Blob Storage

2.0;2022-01-03T20:34:54.4617505Z;PutBlob;SASSuccess;201;7;7;sas;;logsamples;blob;https://logsamples.blob.core.windows.net/container1/1.txt?se=2022-02-02T20:34:54Z&amp;sig=XXXXX&amp;sp=rwl&amp;sr=c&amp;sv=2020-04-08&amp;timeout=901;"/logsamples/container1/1.txt";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;71.197.193.44:53371;2019-12-12;654;13;337;0;13;"xxxxxxxxxxxxxxxxxxxxx==";"xxxxxxxxxxxxxxxxxxxxx==";"&quot;0x8D9CEF88004E296&quot;";Monday, 03-Jan-22 20:34:54 GMT;;"Microsoft Azure Storage Explorer, 1.20.1, win32, azcopy-node, 2.0.0, win32, AzCopy/10.11.0 Azure-Storage/0.13 (go1.15; Windows_NT)";;"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx";;;;;;;;

Beispielprotokolleintrag für Blob-Storage (Data Lake Storage Gen2 aktiviert)

2.0;2022-01-04T22:50:56.0000775Z;RenamePathFile;Success;201;49;49;authenticated;logsamples;logsamples;blob;"https://logsamples.dfs.core.windows.net/my-container/myfileorig.png?mode=legacy";"/logsamples/my-container/myfilerenamed.png";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;73.157.16.8;2020-04-08;591;0;224;0;0;;;;Friday, 11-Jun-21 17:58:15 GMT;;"Microsoft Azure Storage Explorer, 1.19.1, win32 azsdk-js-storagedatalake/12.3.1 (NODE-VERSION v12.16.3; Windows_NT 10.0.22000)";;"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx";;;;;;;;

Beispielprotokolleintrag für Queue Storage

2.0;2022-01-03T20:35:04.6097590Z;PeekMessages;Success;200;5;5;authenticated;logsamples;logsamples;queue;https://logsamples.queue.core.windows.net/queue1/messages?numofmessages=32&amp;peekonly=true&amp;timeout=30;"/logsamples/queue1";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;71.197.193.44:53385;2020-04-08;536;0;232;62;0;;;;;;"Microsoft Azure Storage Explorer, 1.20.1, win32 azsdk-js-storagequeue/12.3.1 (NODE-VERSION v12.16.3; Windows_NT 10.0.22000)";;"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx";;;;;;;;

Beispielprotokolleintrag für Table Storage

1.0;2022-01-03T20:35:13.0719766Z;CreateTable;Success;204;30;30;authenticated;logsamples;logsamples;table;https://logsamples.table.core.windows.net/Tables;"/logsamples/Table1";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;71.197.193.44:53389;2018-03-28;601;22;339;0;22;;;;;;"Microsoft Azure Storage Explorer, 1.20.1, win32, Azure-Storage/2.10.3 (NODE-VERSION v12.16.3; Windows_NT 10.0.22000)";;"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"

Nächste Schritte