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.

Parametername Parametertyp Notizen Erforderlich?
enabled boolean Dient zum Deaktivieren der gesamten Richtlinie. Wenn diese Option auf true festgelegt ist, überschreibt das aktivierte Feld auf Regelebene diesen Parameter. Wenn diese Option deaktiviert ist, wird die Inventur für alle Regeln deaktiviert. Ja
rules Ein Array von Regelobjekten Eine Richtlinie muss mindestens eine Regel enthalten. Pro Richtlinie werden bis zu 100 Regeln unterstützt. Ja

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:

Parametername Parametertyp Notizen Erforderlich?
name Zeichenfolge Ein Regelname kann bis zu 256 alphanumerische Zeichen (Groß-/Kleinschreibung beachten) enthalten. Der Name muss innerhalb einer Richtlinie eindeutig sein. Ja
enabled boolean Ein Flag, das es ermöglicht, eine Regel zu aktivieren oder zu deaktivieren. Der Standardwert lautet true. Ja
Definition JSON-Definition der Inventurregel Jede Definition beinhaltet einen Regelfiltersatz. Ja
destination Zeichenfolge Der Zielcontainer, in dem alle Bestandsdateien generiert werden. Der Zielcontainer muss bereits vorhanden sein.

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

Regeldefinition

Parametername Parametertyp Notizen Erforderlich
Filter json Mit Filtern wird entschieden, ob ein Blob oder ein Container Teil einer Inventur ist oder nicht. Ja
format Zeichenfolge Bestimmt die Ausgabe der Inventurdatei. Gültige Werte sind csv (für das CSV-Format) und parquet (für das Apache Parquet-Format). Ja
objectType Zeichenfolge Gibt an, ob es sich um eine Inventurregel für Blobs oder für Container handelt. Gültige Werte sind blob und container. Ja
schedule Zeichenfolge Zeitplan für die Ausführung dieser Regel. Gültige Werte sind daily und weekly. Ja
schemaFields JSON-Array Liste von Schemafeldern, die Teil der Inventur sind. Ja

Regelfilter

Zum Anpassen eines Blobbestandsberichts sind mehrere Filter verfügbar:

Filtername Filtertyp Notizen Erforderlich?
blobTypes Ein Array von vordefinierten Enumerationswerten. Gültige Werte sind blockBlob und appendBlob für Konten mit aktiviertem hierarchischem Namespace sowie blockBlob, appendBlob und pageBlob für andere Konten. Dieses Feld ist bei einer Containerinventur nicht anwendbar (objectType: container). Ja
creationTime Number Gibt die Anzahl der Tage an, in denen das Blob erstellt werden muss. Ein Wert von 3 enthält beispielsweise im Bericht nur die Blobs, die in den letzten 3 Tagen erstellt wurden. No
prefixMatch Ein Array von bis zu 10 Zeichenfolgen für Präfixe, die abgeglichen werden sollen. Wenn Sie prefixMatch nicht definieren oder ein leeres Präfix angeben, gilt die Regel für alle Blobs im Speicherkonto. Bei dem Präfix muss es sich um das Präfix eines Containernamens oder um einen Containernamen handeln. Platzhalter in einer derartigen Schreibweise sind z.B. container und container1/foo. Nein
excludePrefix Ein Array von bis zu 10 Zeichenfolgen für Präfixe, die ausgeschlossen werden sollen. Gibt die Blobpfade an, die aus dem Bestandsbericht ausgeschlossen werden sollen.

Ein excludePrefix muss das Präfix eines Containernamens oder ein Containername sein. Ein leerer excludePrefix bedeutet, dass alle Blobs mit Namen, die mit einer beliebigen prefixMatch-Zeichenfolge übereinstimmen, aufgelistet werden.

Wenn Sie ein bestimmtes Präfix einschließen, aber eine spezifische Teilmenge daraus ausschließen möchten, können Sie den Filter „excludePrefix“ verwenden. Wenn Sie beispielsweise alle Blobs unter container-a – mit Ausnahme derjenigen unter dem Ordner container-a/folder – einschließen möchten, sollte prefixMatch auf container-a und excludePrefix auf container-a/folder festgelegt werden.
Nein
includeSnapshots boolean Gibt an, ob Momentaufnahmen in die Inventur eingeschlossen werden sollen. Der Standardwert ist false. Dieses Feld ist bei einer Containerinventur nicht anwendbar (objectType: container). Nein
includeBlobVersions boolean Gibt an, ob Blobversionen in die Inventur eingeschlossen werden sollen. Der Standardwert ist false. Dieses Feld ist bei einer Containerinventur nicht anwendbar (objectType: container). Nein
includeDeleted boolean Gibt an, ob gelöschte Blobs in den Bestand eingeschlossen werden sollen. Der Standardwert ist false. Bei Konten mit einem hierarchischen Namespace schließt dieser Filter sowohl Ordner als auch Blobs ein, die sich in einem vorläufig gelöschten Zustand befinden.

Berichte enthalten nur die Ordner und Dateien (Blobs), die explizit gelöscht werden. Untergeordnete Ordner und Dateien, die infolge der Löschung eines übergeordneten Ordners gelöscht werden, werden nicht in den Bericht eingeschlossen.
Nein

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

Hinweis

Die Spalte Data Lake Storage zeigt Unterstützung in Konten, bei denen das Feature „hierarchischer Namespace“ aktiviert wurde.

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

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

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

Hinweis

Die Spalte Data Lake Storage zeigt Unterstützung in Konten, bei denen das Feature „hierarchischer Namespace“ aktiviert wurde.

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

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.

Feld Typ BESCHREIBUNG
scheduleDateTime Zeichenfolge Zeitpunkt, zu dem die Bestandsregel geplant ist.
. Zeichenfolge Der Name des Speicherkontos.
ruleName Zeichenfolge Name der Regel
policyRunStatus Zeichenfolge Status der Inventurausführung Mögliche Werte sind Succeeded, PartiallySucceeded und Failed.
policyRunStatusMessage Zeichenfolge Statusmeldung der Inventurausführung
policyRunId Zeichenfolge Richtlinienausführungs-ID für die Inventurausführung
manifestBlobUrl Zeichenfolge Blob-URL für die Manifestdatei der Inventurausführung

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.

    Screenshot einer in Microsoft Excel geöffneten 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