Azure Storage-Blobbestand

Die BLOB-Inventur von Azure Storage enthält eine Liste der Container, BLOBs, BLOB-Versionen und Momentaufnahmen in Ihrem Speicherkonto sowie die zugehörigen Eigenschaften. Sie generiert täglich oder wöchentlich einen Ausgabebericht im CSV- oder Apache Parquet-Format. Sie können den Bericht verwenden, um den Status der Aufbewahrung, der gesetzlichen Aufbewahrungspflicht oder der Verschlüsselung Ihrer Speicherkontoinhalte zu überwachen, oder Sie können ihn verwenden, um die Gesamtdatengröße, das Alter, die Ebenenverteilung oder andere Attribute Ihrer Daten zu verstehen. Sie können auch die BLOB-Inventur verwenden, um Ihre Geschäfts-Workflows zu vereinfachen oder Datenverarbeitungsaufträge zu beschleunigen, indem Sie die BLOB-Inventur als geplante Automatisierung der APIs Listencontainer und Listen-BLOBs verwenden. Mithilfe von BLOB-Inventurregeln können Sie die Inhalte des Berichts nach BLOB-Typ, Präfix oder durch die Auswahl der BLOB-Eigenschaften filtern, die in den Bericht aufgenommen werden sollen.

Die Azure Storage Blob-Inventarisierung ist für die folgenden Arten von Speicherkonten verfügbar:

• Standard „Allgemein v2“
• Premium Blockblobspeicher
• Blob Storage

Inventurfeatures

Die folgende Liste beschreibt Features und Funktionen, die im aktuellen Release der Azure Storage-Blobinventur verfügbar sind.

• Inventurberichte für Blobs und Container

  Sie können Inventurberichte für Blobs und Container erstellen. Ein Blobbericht kann Basisblobs, Momentaufnahmen, Inhaltslängen, Blobversionen und die damit verbunden Eigenschaften (z. B. den Zeitpunkt der Erstellung oder den Zeitpunkt der letzten Änderung) enthalten. Leere Container werden im Blobinventurbericht nicht aufgeführt. Ein Containerbericht beschreibt Container und die damit verbundenen Eigenschaften (z. B. den Status der Unveränderlichkeitsrichtlinie oder den Status der gesetzlichen Aufbewahrungspflicht).

• Benutzerdefiniertes Schema

  Sie können auswählen, welche Felder im Bericht enthalten sind. Wählen Sie diese aus einer Liste unterstützter Felder aus. Die Liste finden Sie weiter unten in diesem Artikel.

• CSV- und Apache Parquet-Ausgabeformat

  Sie können den Inventurbericht entweder in einem CSV- oder einem Apache Parquet-Ausgabeformat erstellen.

• Manifestdatei und Azure Event Grid-Ereignis pro Inventurbericht

  Pro Inventurbericht werden eine Manifestdatei und ein Azure Event Grid-Ereignis erstellt. Diese werden weiter unten in diesem Artikel beschrieben.

Aktivieren von Inventurberichten

Sie aktivieren Blobinventurberichte, indem Sie Ihrem Speicherkonto eine Richtlinie mit mindestens einer Regel hinzufügen. Weitere Anweisungen dazu finden Sie unter Aktivieren von Azure Storage-Blobinventurberichten.

Aktualisieren einer Inventurrichtlinie

Wenn Sie die Azure Storage-Blobinventur bereits nutzen und vor Juni 2021 konfiguriert haben, müssen Sie für die Nutzung der neuen Features nur die Richtlinie laden und sie wieder abspeichern, nachdem Sie die Änderungen vorgenommen haben. Wenn Sie die Richtlinie dann erneut laden, werden die neuen Felder in der Richtlinie mit den Standardwerten ausgefüllt. Sie können diese Werte bei Bedarf ändern. Darüber hinaus sind die beiden folgenden Features verfügbar.

• Ein Zielcontainer wird nun für jede Regel und nicht mehr nur für die Richtlinie unterstützt.

• Nun werden pro Regel (und nicht mehr nur pro Richtlinie) eine Manifestdatei und ein Azure Event Grid-Ereignis erstellt.

Inventurrichtlinie

Sie konfigurieren einen Bestandsbericht, indem Sie eine Inventurrichtlinie mit mindestens einer Regel hinzufügen. Eine Inventurrichtlinie ist eine Sammlung von Regeln in einem JSON-Dokument.

{
  "enabled": true,
  "rules": [
  {
    "enabled": true,
    "name": "inventoryrule1",
    "destination": "inventory-destination-container",
    "definition": {. . .}
  },
  {
    "enabled": true,
    "name": "inventoryrule2",
    "destination": "inventory-destination-container",
    "definition": {. . .}
  }]
}

Sie zeigen den JSON-Code für eine Inventurrichtlinie an, indem Sie im Azure-Portal im Abschnitt Blob Inventory (Blobbestand) die Registerkarte Codeansicht auswählen.

Inventurregeln

Eine Regel erfasst die Filterbedingungen und Ausgabeparameter zum Erstellen eines Bestandsberichts. Jeder Regel erstellt einen Bestandsbericht. Regeln können überlappende Präfixe aufweisen. Ein Blob kann abhängig von den Regeldefinitionen auch in mehreren Beständen enthalten sein.

Jede Regel in der Richtlinie umfasst mehrere Parameter:

Das globale Flag Blob inventory enabled (Blobinventur aktiviert) hat Vorrang vor dem enabled-Parameter in einer Regel.

Regeldefinition

Regelfilter

Zum Anpassen eines Blobbestandsberichts sind mehrere Filter verfügbar:

Sie zeigen den JSON-Code für Inventurrichtlinien an, indem Sie im Azure-Portal im Abschnitt Blob Inventory (Blobbestand) die Registerkarte Codeansicht auswählen. Filter werden innerhalb einer Regeldefinition angegeben.

{
  "destination": "inventory-destination-container",
  "enabled": true,
  "rules": [
  {
    "definition": {
      "filters": {
        "blobTypes": ["blockBlob", "appendBlob", "pageBlob"],
        "prefixMatch": ["inventorytestcontainer1", "inventorytestcontainer2/abcd", "etc"],
        "excludePrefix": ["inventorytestcontainer10", "etc/logs"],
        "includeSnapshots": false,
        "includeBlobVersions": true,
      },
      "format": "csv",
      "objectType": "blob",
      "schedule": "daily",
      "schemaFields": ["Name", "Creation-Time"]
    },
    "enabled": true,
    "name": "blobinventorytest",
    "destination": "inventorydestinationContainer"
  },
  {
    "definition": {
      "filters": {
        "prefixMatch": ["inventorytestcontainer1", "inventorytestcontainer2/abcd", "etc"]
      },
      "format": "csv",
      "objectType": "container",
      "schedule": "weekly",
      "schemaFields": ["Name", "HasImmutabilityPolicy", "HasLegalHold"]
    },
    "enabled": true,
    "name": "containerinventorytest",
    "destination": "inventorydestinationContainer"
    }
  ]
}

Benutzerdefinierte Schemafelder, die für die Blobinventur unterstützt werden

Feld	Blob Storage (Standardunterstützung)	Data Lake Storage
Name (Erforderlich)
Erstellungszeit
Last-Modified
LastAccessTime1
ETag
Content-Length
Content-Type
Content-Encoding
Inhaltssprache
Content-CRC64
Content-MD5
Cachesteuerung
Cache-Disposition
BlobType
AccessTier
AccessTierChangeTime
LeaseStatus
LeaseState
ServerEncrypted
CustomerProvidedKeySHA256
Metadaten
Expiry-Time
hdi_isfolder
Besitzer
Group
Berechtigungen
Acl
Momentaufnahme (verfügbar und erforderlich, wenn Sie Momentaufnahmen in Ihren Bericht integrieren möchten)
Deleted
DeletedId
DeletedTime
RemainingRetentionDays
VersionID (verfügbar und erforderlich, wenn Sie Blobversionen in Ihren Bericht integrieren möchten)
IsCurrentVersion (verfügbar und erforderlich, wenn Sie Blobversionen in Ihren Bericht integrieren möchten)
TagCount
`Tags`
CopyId
CopySource
CopyStatus
CopyProgress
CopyCompletionTime
CopyStatusDescription
ImmutabilityPolicyUntilDate
ImmutabilityPolicyMode
LegalHold
RehydratePriority
ArchiveStatus
EncryptionScope
IncrementalCopy
x-ms-blob-sequence-number

¹ Standardmäßig deaktiviert. Aktivieren Sie optional die Nachverfolgung der Zugriffszeit.

Benutzerdefinierte Schemafelder, die für die Containerinventur unterstützt werden

Feld	Blob Storage (Standardunterstützung)	Data Lake Storage
Name (Erforderlich)
Last-Modified
ETag
LeaseStatus
LeaseState
LeaseDuration
Metadaten
PublicAccess
DefaultEncryptionScope
DenyEncryptionScopeOverride
HasImmutabilityPolicy
HasLegalHold
ImmutableStorageWithVersioningEnabled
Deleted (nur angezeigt, wenn „Include deleted containers“ (Gelöschte Container einschließen) ausgewählt wurde)
Version (nur angezeigt, wenn „Include deleted containers“ (Gelöschte Container einschließen) ausgewählt wurde)
DeletedTime (Wird nur angezeigt, wenn „include deleted containers“ ausgewählt wurde)
RemainingRetentionDays (Wird nur angezeigt, wenn „include deleted containers“ ausgewählt wurde)

Inventurausführung

Wenn Sie eine Regel für die tägliche Ausführung konfigurieren, wird sie so geplant, dass sie jeden Tag ausgeführt wird. Wenn Sie eine Regel für die wöchentliche Ausführung konfigurieren, wird sie so geplant, dass sie jede Woche am Sonntag (UTC) ausgeführt wird.

Die meisten Bestandsausführungen werden innerhalb von 24 Stunden abgeschlossen. Bei Konten mit aktivierten hierarchischen Namespaces kann eine Ausführung bis zu zwei Tage dauern. Je nach Anzahl der verarbeiteten Dateien ist die Ausführung nach diesen zwei Tagen möglicherweise nicht abgeschlossen. Die maximale Dauer bis zum Abschluss einer Ausführung, bevor diese als fehlerhaft gilt, beträgt sechs Tage.

Ausführungen überschneiden sich nicht, sodass eine Ausführung abgeschlossen werden muss, bevor eine andere Ausführung derselben Regel beginnen kann. Wenn z. B. eine Regel täglich ausgeführt wird und die Ausführung dieser Regel vom Vortag noch nicht abgeschlossen ist, wird an dem betreffenden Tag keine neue Ausführung initiiert. Regeln, die für die wöchentliche Ausführung geplant sind, werden jeden Sonntag ausgeführt, unabhängig davon, ob eine vorherige Ausführung erfolgreich oder fehlerhaft war. Wenn eine Ausführung nicht erfolgreich abgeschlossen wird, überprüfen Sie, ob nachfolgende Ausführungen abgeschlossen werden, bevor Sie sich an den Support wenden. Die Leistung einer Ausführung kann variieren. Wenn eine Ausführung also nicht abgeschlossen wird, ist es dennoch möglich, dass nachfolgende Ausführungen abgeschlossen werden.

Bestandsrichtlinien werden vollständig gelesen oder geschrieben. Teilaktualisierungen werden nicht unterstützt. Bestandsregeln werden täglich ausgewertet. Wenn Sie also die Definition einer Regel ändern, aber die Regeln einer Richtlinie bereits für diesen Tag ausgewertet wurden, werden Ihre Änderungen erst am folgenden Tag ausgewertet.

Inventurabschlussereignis

Das BlobInventoryPolicyCompleted-Ereignis wird erstellt, sobald die Inventur für eine Regel abgeschlossen wurde. Dieses Ereignis tritt auch ein, wenn vor dem Start der Inventur ein Benutzerfehler auftritt. Beispielsweise wird dieses Ereignis durch eine ungültige Richtlinie oder durch einen Fehler aufgrund eines fehlenden Zielcontainers ausgelöst. Die folgende JSON zeigt ein BlobInventoryPolicyCompleted-Ereignis als Beispiel:

{
  "topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/BlobInventory/providers/Microsoft.EventGrid/topics/BlobInventoryTopic",
  "subject": "BlobDataManagement/BlobInventory",
  "eventType": "Microsoft.Storage.BlobInventoryPolicyCompleted",
  "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "data": {
    "scheduleDateTime": "2021-05-28T03:50:27Z",
    "accountName": "testaccount",
    "ruleName": "Rule_1",
    "policyRunStatus": "Succeeded",
    "policyRunStatusMessage": "Inventory run succeeded, refer manifest file for inventory details.",
    "policyRunId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "manifestBlobUrl": "https://testaccount.blob.core.windows.net/inventory-destination-container/2021/05/26/13-25-36/Rule_1/Rule_1-manifest.json"
  },
  "dataVersion": "1.0",
  "metadataVersion": "1",
  "eventTime": "2021-05-28T15:03:18Z"
}

In folgender Tabelle wird das Schema des BlobInventoryPolicyCompleted-Ereignisses beschrieben.

Inventurausgabe

Jede Inventurregel generiert Dateien im angegebenen Inventur-Zielcontainer für die jeweilige Regel. Die Inventurausgabe wird unter folgendem Pfad generiert: https://<accountName>.blob.core.windows.net/<inventory-destination-container>/YYYY/MM/DD/HH-MM-SS/<ruleName. Dabei gilt:

• accountName ist der Name Ihres Azure Blob Storage-Kontos.
• inventory-destination-container ist der in Ihrer Inventurregel angegebene Zielcontainer.
• YYYY/MM/DD/HH-MM-SS ist die Uhrzeit, zu der die Inventur gestartet wurde.
• ruleName ist der Name der Inventurregel.

Inventurdateien

Bei jeder Inventur für eine Regel werden die folgenden Dateien generiert:

• Inventurdatei: Eine Inventurausführung für eine Regel generiert Dateien im CSV- oder Apache Parquet-Format. Jede dieser Dateien enthält die übereinstimmenden Objekte und ihre Metadaten.

  Wichtig

  Ab Oktober 2023 erzeugt die Bestandsausführung mehrere Dateien, wenn die Objektanzahl groß ist. Weitere Informationen finden Sie unter Häufig gestellte Fragen zur Ausgabe mehrerer Inventurdateien.

  Berichte im Apache Parquet-Format enthalten Daten im folgenden Format: timestamp_millis [number of milliseconds since 1970-01-01 00:00:00 UTC. Die erste Zeile in einer CSV-Datei enthält immer das Schema. Die folgende Abbildung zeigt eine in Microsoft Excel geöffnete CSV-Bestandsdatei.

  

  Wichtig

  Die Blobpfade in einer Inventurdatei werden möglicherweise in keiner bestimmten Reihenfolge angezeigt.

• Prüfsummendatei: Eine Prüfsummendatei enthält die MD5-Prüfsumme des Inhalts der Datei „manifest.json“. Der Name der Prüfsummendatei lautet <ruleName>-manifest.checksum. Die Generierung der Prüfsummendatei markiert das Ende der Inventur für eine Regel.

• Manifestdatei: Eine Datei „manifest.json“ enthält Details zu den Inventurdateien, die für die jeweilige Regel generiert wurden. Der Name der Datei lautet <ruleName>-manifest.json. Diese Datei enthält auch die vom Benutzer angegebene Regeldefinition und den Pfad zum Bestand zu dieser Regel. Die folgende JSON zeigt den Inhalt einer manifest.json-Datei als Beispiel.

  {
  "destinationContainer" : "inventory-destination-container",
  "endpoint" : "https://testaccount.blob.core.windows.net",
  "files" : [
    {
      "blob" : "2021/05/26/13-25-36/Rule_1/Rule_1.csv",
      "size" : 12710092
    }
  ],
  "inventoryCompletionTime" : "2021-05-26T13:35:56Z",
  "inventoryStartTime" : "2021-05-26T13:25:36Z",
  "ruleDefinition" : {
    "filters" : {
      "blobTypes" : [ "blockBlob" ],
      "includeBlobVersions" : false,
      "includeSnapshots" : false,
      "prefixMatch" : [ "penner-test-container-100003" ]
    },
    "format" : "csv",
    "objectType" : "blob",
    "schedule" : "daily",
    "schemaFields" : [
      "Name",
      "Creation-Time",
      "BlobType",
      "Content-Length",
      "LastAccessTime",
      "Last-Modified",
      "Metadata",
      "AccessTier"
    ]
  },
  "ruleName" : "Rule_1",
  "status" : "Succeeded",
  "summary" : {
    "objectCount" : 110000,
    "totalObjectSize" : 23789775
  },
  "version" : "1.0"
  }
  

  Diese Datei wird erstellt, wenn die Ausführung beginnt. Das Feld status dieser Datei ist auf Pending festgelegt, bis die Ausführung abgeschlossen ist. Nach Abschluss der Ausführung wird dieses Feld auf einen abgeschlossenen Status festgelegt (z. B. Succeeded oder Failed).

Preise und Abrechnung

Die Preise für die Inventur basieren auf der Anzahl der Blobs und Container, die während des Abrechnungszeitraums gescannt werden. Auf der Preisseite von Azure Blob Storage wird der Preis pro eine Million überprüfter Objekte angezeigt. Wenn der Preis für die Überprüfung einer Million Objekte beispielsweise $0.003 beträgt, Ihr Konto drei Millionen Objekte enthält und Sie vier Berichte pro Monat erstellen, dann würde Ihre Rechnung 4 * 3 * $0.003 = $0.036 betragen.

Nachdem die Inventurdateien erstellt wurden, fallen standardmäßig zusätzliche Datenspeicherungs- und Vorgangskosten im Zusammenhang mit dem Speichern, Lesen und Schreiben der durch die Inventur erstellten Dateien in dem Konto an.

Wenn eine Regel ein Präfix enthält, das mit dem Präfix einer anderen Regel überlappt, dann kann derselbe Blob in mehreren Inventurberichten auftauchen. In diesem Fall werden beide Instanzen abgerechnet. Gehen wir z. B. davon aus, dass das Element prefixMatch einer Regel auf ["inventory-blob-1", "inventory-blob-2"] festgelegt ist, und dass das Element prefixMatch einer anderen Regel auf ["inventory-blob-10", "inventory-blob-20"] festgelegt ist. Ein Objekt mit dem Namen inventory-blob-200 wird in beiden Inventurberichten erscheinen.

Momentaufnahmen und Blobversionen werden ebenfalls abgerechnet, auch wenn Sie die Filter includeSnapshots und includeVersions auf false festgelegt haben. Diese Filterwerte haben keinen Einfluss auf die Abrechnung. Sie können sie nur verwenden, um zu filtern, welche Elemente im Bericht erscheinen.

Weitere Informationen zu den Preisen für die Azure Storage-Blobinventur finden Sie auf der Seite Preise für Azure Blob Storage.

Featureunterstützung

Die Unterstützung für dieses Features kann durch die Aktivierung von Data Lake Storage Gen2, dem Network File System (NFS) 3.0-Protokoll oder dem SSH File Transfer Protocol (SFTP) beeinträchtigt werden. Wenn Sie eine dieser Funktionen aktiviert haben, lesen Sie bitte den Abschnitt Unterstützung der Blob Storage-Funktion in Azure Storage-Konten, um die Unterstützung für dieses Features zu bewerten.

Einschränkungen und bekannte Probleme

In diesem Abschnitt werden Einschränkungen und bekannte Probleme des Azure Storage-Blobbestandsfeatures beschrieben.

Die Ausführung von Inventuraufträgen dauert in bestimmten Fällen länger

Ein Inventurauftrag kann in diesen Fällen länger dauern:

• Eine große Menge neuer Daten wird hinzugefügt.

• Eine Regel oder ein Regelsatz wird zum ersten Mal ausgeführt.

  Die Inventurausführung kann im Vergleich zu den nachfolgenden Inventurausführungen länger dauern.

• Bei der Inventurausführung wird eine große Datenmenge in Konten verarbeitet, für die der hierarchische Namespace aktiviert ist

  Bei Konten mit Unterstützung eines hierarchischen Namespace und Hunderten von Millionen von Blobs kann ein Inventurauftrag länger als einen Tag dauern. Mitunter schlägt der Inventurauftrag fehl, sodass keine Inventurdatei erstellt wird. Wenn ein Auftrag nicht erfolgreich abgeschlossen wird, überprüfen Sie, ob nachfolgende Aufträge abgeschlossen werden, bevor Sie sich an den Support wenden.

• Es gibt keine Möglichkeit, einen Bericht rückwirkend für ein bestimmtes Datum zu generieren.

Inventuraufträge können keine Berichte in Container schreiben, für die eine Objektreplikationsrichtlinie gilt.

Der Inventurauftrag wird möglicherweise durch eine Objektreplikationsrichtlinie daran gehindert, Inventurberichte in den Zielcontainer zu schreiben. In einigen anderen Szenarien können die Berichte archiviert oder unveränderlich gemacht werden, wenn sie teilweise abgeschlossen sind, was dazu führen kann, dass Inventuraufträge nicht erfolgreich sind.

Bestand und unveränderlicher Speicher

Sie können keine Bestandsrichtlinie im Konto konfigurieren, wenn die Unterstützung für die Unveränderlichkeit auf Versionsebene für dieses Konto aktiviert ist oder die Unterstützung für die Unveränderlichkeit auf Versionsebene für den Zielcontainer aktiviert ist, der in der Bestandsrichtlinie definiert ist.

Berichte schließen vorläufig gelöschte Blobs in Konten, die über einen hierarchischen Namespace verfügen, möglicherweise aus.

Wenn ein Container oder ein Verzeichnis gelöscht wird, während die Funktion zum vorläufigen Löschen aktiviert ist, werden der Container oder das Verzeichnis und sein gesamter Inhalt als „vorläufig gelöscht“ markiert. In einem Inventarbericht erscheint jedoch nur der Container oder das Verzeichnis (als Blob mit der Länge Null angegeben) und nicht die vorläufig gelöschten Blobs in diesem Container oder Verzeichnis, selbst wenn Sie das includeDeleted-Feld der Richtlinie auf true festlegen. Dadurch kann es zu einem Unterschied zwischen den Kapazitätsmetriken im Azure-Portal und den Angaben in einem Bestandsbericht kommen.

Nur Blobs, die explizit gelöscht werden, erscheinen in Berichten. Um eine vollständige Auflistung aller vorläufig gelöschten Blobs (Verzeichnis und alle untergeordneten Blobs) zu erhalten, sollten Workloads daher jeden Blob in einem Verzeichnis löschen, bevor sie das Verzeichnis selbst löschen.

Nächste Schritte

• Aktivieren von Azure Storage-Blobinventurberichten
• Berechnen der Anzahl und Gesamtgröße von Blobs pro Container
• Tutorial: Analysieren von Blobinventurberichten
• Verwalten des Azure Blob Storage-Lebenszyklus
• Häufig gestellte Fragen zum Blob-Inventar