Änderungsfeed in Azure Blob Storage

  • Artikel
  • 13 Minuten Lesedauer

Zweck des Änderungsfeeds ist es, Transaktionsprotokolle für alle Änderungen bereitzustellen, die in den Blobs und Blobmetadaten in Ihrem Speicherkonto auftreten. Der Änderungsfeed bietet sortierte, garantierte, permanente, unveränderliche und schreibgeschützte Protokolle dieser Änderungen. Clientanwendungen können diese Protokolle jederzeit lesen, entweder im Streaming- oder im Batchmodus. Der Änderungsfeed ermöglicht es Ihnen, effiziente und skalierbare Lösungen zu erstellen, mit denen Änderungsereignisse, die in Ihrem Blob Storage-Konto auftreten, kostengünstig verarbeitet werden.

Funktionsweise des Änderungsfeeds

Einträge im Änderungsfeed werden in Form von Blobs in einem speziellen Container Ihres Speicherkontos zu standardmäßigen Blobpreisen gespeichert. Sie können den Aufbewahrungszeitraum dieser Dateien Ihren Anforderungen entsprechend steuern (Informationen hierzu finden Sie in den Bedingungen für das aktuelle Release). Änderungsereignisse werden in der Apache Avro-Formatspezifikation als Datensätze an den Änderungsfeed angehängt. Dies ist ein kompaktes, schnelles Binärformat, das umfangreiche Datenstrukturen mit Inlineschemas bereitstellt. Dieses Format wird häufig im Hadoop-Ökosystem, von Stream Analytics und von Azure Data Factory verwendet.

Sie können diese Protokolle asynchron, inkrementell oder vollständig verarbeiten. Eine beliebige Anzahl von Clientanwendungen kann den Änderungsfeed unabhängig, gleichzeitig und in der jeweils eigenen Geschwindigkeit lesen. Analyseanwendungen wie Apache Drill oder Apache Spark können Protokolle direkt als Avro-Dateien nutzen, sodass sie kostengünstig, mit hoher Bandbreite und ohne benutzerdefinierte Anwendung verarbeitet werden können.

Das folgende Diagramm zeigt, wie dem Änderungsfeed Datensätze hinzugefügt werden:

Diagramm, das die Funktionsweise des Änderungsfeeds zum Bereitstellen eines sortierten Protokolls der Änderungen an Blobs zeigt

Die Unterstützung eines Änderungsfeeds eignet sich gut für Szenarien, in denen Daten basierend auf geänderten Objekten verarbeitet werden. Anwendungen können beispielsweise Folgendes ausführen:

  • Aktualisieren eines sekundären Index, Synchronisieren mit einem Cache oder einer Suchmaschine oder andere Content Management-Szenarien.
  • Extrahieren von Erkenntnissen und Metriken aus geschäftlichen Analysen, basierend auf Änderungen an Ihren Objekten – entweder per Streaming oder im Batchmodus.
  • Speichern, Überwachen und Analysieren von Änderungen an Ihren Objekten über einen beliebigen Zeitraum hinweg, um Sicherheit, Compliance oder Business Intelligence für die Verwaltung von Unternehmensdaten zu erzielen.
  • Erstellen von Lösungen zum Sichern, Spiegeln oder Replizieren des Objektzustands in Ihrem Konto für Notfallverwaltung oder Compliance.
  • Erstellen von verbundenen Anwendungspipelines, die auf Änderungsereignisse reagieren oder Ausführungen basierend auf erstellten oder geänderten Objekten planen.

Der Änderungsfeed ist ein erforderliches Feature für Objektreplikation und Point-in-Time-Wiederherstellung für Blockblobs.

Hinweis

Der Änderungsfeed bietet ein permanentes, sortiertes Protokollmodell der Änderungen an einem Blob. Änderungen werden innerhalb weniger Minuten in Ihr Änderungsfeedprotokoll geschrieben und verfügbar gemacht. Wenn Ihre Anwendung wesentlich schneller auf Ereignisse reagieren muss, sollten Sie stattdessen Blob Storage-Ereignisse in Betracht ziehen. Blob Storage-Ereignisse bieten einmalige Echtzeitereignisse, mit denen Ihre Azure Functions-Lösung oder Ihre Anwendungen schnell auf Blobänderungen reagieren können.

Aktivieren und Deaktivieren des Änderungsfeeds

Sie müssen den Änderungsfeed in Ihrem Speicherkonto aktivieren, damit Änderungen erfasst und aufgezeichnet werden. Deaktivieren Sie den Änderungsfeed, um die Erfassung von Änderungen zu beenden. Sie können Änderungen mithilfe von Azure Resource Manager-Vorlagen im Portal oder in PowerShell aktivieren und deaktivieren.

Folgende Aspekte müssen Sie berücksichtigen, wenn Sie den Änderungsfeed aktivieren.

  • In jedem Speicherkonto gibt es nur einen Änderungsfeed für den Blobdienst. Einträge im Änderungsfeed werden im Container $blobchangefeed gespeichert.

  • Erstellungen, Aktualisierungen und Löschungen werden nur auf der Blobdienstebene erfasst.

  • Der Änderungsfeed zeichnet alle Änderungen für alle verfügbaren Ereignisse auf, die im Konto auftreten. Clientanwendungen können Ereignistypen nach Bedarf herausfiltern. (Informationen hierzu finden Sie in den Bedingungen für das aktuelle Release.)

  • Nur Konten vom Typ „Standard Universell V2“, „Premium Blockblob“ und Blob-Speicherkonten können den Änderungsfeed aktivieren. Konten mit einem aktivierten hierarchischen Namespace werden derzeit nicht unterstützt. Speicherkonten vom Typ „Universell V1“ werden zwar nicht unterstützt, können aber ohne Downtime auf „Universell V2“ aktualisiert werden. Weitere Informationen finden Sie unter Durchführen eines Upgrades auf ein Speicherkonto vom Typ „Universell V2“.

So aktivieren Sie den Änderungsfeed für Ihr Speicherkonto über das Azure-Portal:

  1. Wählen Sie im Azure-Portal Ihr Speicherkonto aus.

  2. Navigieren Sie unter Datenverwaltung zur Option Datenschutz.

  3. Wählen Sie unter Überwachung die Option Blobänderungsfeed aktivieren aus.

  4. Wählen Sie die Schaltfläche Speichern, um Ihre Datenschutzeinstellungen zu bestätigen.

    Screenshot, der anzeigt, wie man die Feed-Änderung im Azure-Portal aktiviert

Nutzen des Änderungsfeeds

Der Änderungsfeed erzeugt verschiedene Metadaten- und Protokolldateien. Diese Dateien befinden sich im Container $blobchangefeed des Speicherkontos.

Hinweis

Im aktuellen Release ist der Container „$blobchangefeed“ nur im Azure-Portal, aber nicht im Azure Storage-Explorer sichtbar. Der Container „$blobchangefeed“ kann zurzeit nicht angezeigt werden, wenn Sie die ListContainers-API aufrufen. Sie können aber die ListBlobs-API direkt im Container aufrufen, um die Blobs anzuzeigen.

Ihre Clientanwendungen können den Änderungsfeed nutzen, indem sie die Prozessorbibliothek für den Änderungsfeed im Blob verwenden, die mit dem Change Feed Processor SDK bereitgestellt wird.

Informationen dazu finden Sie unter Verarbeiten von Änderungsfeedprotokollen in Azure Blob Storage.

Segmente im Änderungsfeed

Beim Änderungsfeed handelt es sich um ein Protokoll von Änderungen, das zwar in stündlicheSegmente unterteilt ist, aber alle paar Minuten erweitert und aktualisiert wird. Diese Segmente werden nur erstellt, wenn in dieser Stunde Änderungsereignisse für den Blob auftreten. So kann Ihre Clientanwendung Änderungen nutzen, die innerhalb bestimmter Zeiträume auftreten, ohne das gesamte Protokoll durchsuchen zu müssen. Weitere Informationen finden Sie in den Spezifikationen.

Ein verfügbares stündliches Segment des Änderungsfeeds wird in einer Manifestdatei beschrieben, die die Pfade zu den Änderungsfeeddateien für dieses Segment angibt. Die Auflistung des virtuellen Verzeichnisses $blobchangefeed/idx/segments/ zeigt diese Segmente nach Uhrzeit geordnet an. Der Pfad des Segments beschreibt den Start des stündlichen Zeitbereichs, den das Segment repräsentiert. Sie können diese Liste verwenden, um die Protokollsegmente herauszufiltern, die für Sie von Interesse sind.

Name                                                                    Blob Type    Blob Tier      Length  Content Type    
----------------------------------------------------------------------  -----------  -----------  --------  ----------------
$blobchangefeed/idx/segments/1601/01/01/0000/meta.json                  BlockBlob                      584  application/json
$blobchangefeed/idx/segments/2019/02/22/1810/meta.json                  BlockBlob                      584  application/json
$blobchangefeed/idx/segments/2019/02/22/1910/meta.json                  BlockBlob                      584  application/json
$blobchangefeed/idx/segments/2019/02/23/0110/meta.json                  BlockBlob                      584  application/json

Hinweis

Die Datei $blobchangefeed/idx/segments/1601/01/01/0000/meta.json wird automatisch erstellt, wenn Sie den Änderungsfeed aktivieren. Sie können diese Datei unbesorgt ignorieren. Dabei handelt es sich um eine immer leere Initialisierungsdatei.

Die Segmentmanifestdatei (meta.json) zeigt den Pfad der Änderungsfeeddateien für dieses Segment in der Eigenschaft chunkFilePaths an. Beispiel für eine Segmentmanifestdatei:

{
    "version": 0,
    "begin": "2019-02-22T18:10:00.000Z",
    "intervalSecs": 3600,
    "status": "Finalized",
    "config": {
        "version": 0,
        "configVersionEtag": "0x8d698f0fba563db",
        "numShards": 2,
        "recordsFormat": "avro",
        "formatSchemaVersion": 1,
        "shardDistFnVersion": 1
    },
    "chunkFilePaths": [
        "$blobchangefeed/log/00/2019/02/22/1810/",
        "$blobchangefeed/log/01/2019/02/22/1810/"
    ],
    "storageDiagnostics": {
        "version": 0,
        "lastModifiedTime": "2019-02-22T18:11:01.187Z",
        "data": {
            "aid": "55e507bf-8006-0000-00d9-ca346706b70c"
        }
    }
}

Hinweis

Der Container $blobchangefeed wird erst angezeigt, wenn Sie das Änderungsfeedfeature für Ihr Konto aktiviert haben. Nach dem Aktivieren des Änderungsfeeds dauert es ein paar Minuten, bis die Blobs im Container aufgelistet werden können.

Ändern von Ereignisdatensätzen

Die Änderungsfeeddateien enthalten eine Reihe von Datensätzen mit Änderungsereignissen. Jeder Änderungsereignis-Datensatz entspricht einer Änderung an einem einzelnen Blob. Die Datensätze werden mithilfe der Apache Avro-Formatspezifikation serialisiert und in die Datei geschrieben. Die Datensätze können mithilfe der Avro-Dateiformatspezifikation gelesen werden. Zum Verarbeiten von Dateien in diesem Format stehen verschiedene Bibliotheken zur Verfügung.

Änderungsfeeddateien werden im virtuellen Verzeichnis $blobchangefeed/log/ als Anfügeblobs gespeichert. Die erste Änderungsfeeddatei in jedem Pfad weist einen Zähler 00000 im Dateinamen auf (z. B. 00000.avro). Dieser Zähler wird bei jeder Protokolldatei, die dem Pfad danach hinzugefügt wird, um 1 erhöht (z. B. 00001.avro).

Ereignisdatensatzschemas

Eine ausführliche Beschreibung der einzelnen Eigenschaften finden Sie unter Azure Event Grid-Ereignisschema für Blob Storage. Die Ereignisse „BlobPropertiesUpdated“ und „BlobSnapshotCreated“ gibt es zurzeit exklusiv für den Änderungsfeed, und sie werden für Blob Storage-Ereignisse noch nicht unterstützt.

Hinweis

Die Änderungsfeeddateien für ein Segment werden nicht sofort nach dem Erstellen eines Segments angezeigt. Die Verzögerung bewegt sich im normalen Intervall der Veröffentlichungslatenz des Änderungsfeeds, die wenige Minuten nach der Änderung beträgt.

Schemaversion 1

Die folgenden Ereignistypen können in den Änderungsfeedeinträgen mit Schemaversion 1 erfasst werden:

  • BlobCreated
  • BlobDeleted
  • BlobPropertiesUpdated
  • BlobSnapshotCreated

Das folgende Beispiel zeigt einen Eintrag für ein Änderungsereignis im JSON-Format, bei dem die Ereignisschemaversion 1 verwendet wird:

{
    "schemaVersion": 1,
    "topic": "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "subject": "/blobServices/default/containers/<container>/blobs/<blob>",
    "eventType": "BlobCreated",
    "eventTime": "2022-02-17T12:59:41.4003102Z",
    "id": "322343e3-8020-0000-00fe-233467066726",
    "data": {
        "api": "PutBlob",
        "clientRequestId": "f0270546-168e-4398-8fa8-107a1ac214d2",
        "requestId": "322343e3-8020-0000-00fe-233467000000",
        "etag": "0x8D9F2155CBF7928",
        "contentType": "application/octet-stream",
        "contentLength": 128,
        "blobType": "BlockBlob",
        "url": "https://www.myurl.com",
        "sequencer": "00000000000000010000000000000002000000000000001d",
        "storageDiagnostics": {
            "bid": "9d725a00-8006-0000-00fe-233467000000",
            "seq": "(2,18446744073709551615,29,29)",
            "sid": "4cc94e71-f6be-75bf-e7b2-f9ac41458e5a"
        }
    }
}

Schemaversion 3

Die folgenden Ereignistypen können in den Änderungsfeedeinträgen mit Schemaversion 3 erfasst werden:

  • BlobCreated
  • BlobDeleted
  • BlobPropertiesUpdated
  • BlobSnapshotCreated

Das folgende Beispiel zeigt einen Eintrag für ein Änderungsereignis im JSON-Format, bei dem die Ereignisschemaversion 3 verwendet wird:

{
    "schemaVersion": 3,
    "topic": "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "subject": "/blobServices/default/containers/<container>/blobs/<blob>",
    "eventType": "BlobCreated",
    "eventTime": "2022-02-17T13:05:19.6798242Z",
    "id": "eefe8fc8-8020-0000-00fe-23346706daaa",
    "data": {
        "api": "PutBlob",
        "clientRequestId": "00c0b6b7-bb67-4748-a3dc-86464863d267",
        "requestId": "eefe8fc8-8020-0000-00fe-233467000000",
        "etag": "0x8D9F216266170DC",
        "contentType": "application/octet-stream",
        "contentLength": 128,
        "blobType": "BlockBlob",
        "url": "https://www.myurl.com",
        "sequencer": "00000000000000010000000000000002000000000000001d",
        "previousInfo": {
            "SoftDeleteSnapshot": "2022-02-17T13:08:42.4825913Z",
            "WasBlobSoftDeleted": "true",
            "BlobVersion": "2024-02-17T16:11:52.0781797Z",
            "LastVersion" : "2022-02-17T16:11:52.0781797Z",
            "PreviousTier": "Hot"
        },
        "snapshot": "2022-02-17T16:09:16.7261278Z",
        "blobPropertiesUpdated" : {
            "ContentLanguage" : {
                "current" : "pl-Pl",
                "previous" : "nl-NL"
            },
            "CacheControl" : {
                "current" : "max-age=100",
                "previous" : "max-age=99"
            },
            "ContentEncoding" : {
                "current" : "gzip, identity",
                "previous" : "gzip"
            },
            "ContentMD5" : {
                "current" : "Q2h1Y2sgSW51ZwDIAXR5IQ==",
                "previous" : "Q2h1Y2sgSW="
            },
            "ContentDisposition" : {
                "current" : "attachment",
                "previous" : ""
            },
            "ContentType" : {
                "current" : "application/json",
                "previous" : "application/octet-stream"
            }
        },
        "storageDiagnostics": {
            "bid": "9d726370-8006-0000-00ff-233467000000",
            "seq": "(2,18446744073709551615,29,29)",
            "sid": "4cc94e71-f6be-75bf-e7b2-f9ac41458e5a"
        }
    }
}

Schemaversion 4

Die folgenden Ereignistypen können in den Änderungsfeedeinträgen mit Schemaversion 4 erfasst werden:

  • BlobCreated
  • BlobDeleted
  • BlobPropertiesUpdated
  • BlobSnapshotCreated
  • BlobTierChanged
  • BlobAsyncOperationInitiated
  • RestorePointMarkerCreated

Das folgende Beispiel zeigt einen Eintrag für ein Änderungsereignis im JSON-Format, bei dem die Ereignisschemaversion 4 verwendet wird:

{
    "schemaVersion": 4,
    "topic": "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "subject": "/blobServices/default/containers/<container>/blobs/<blob>",
    "eventType": "BlobCreated",
    "eventTime": "2022-02-17T13:08:42.4835902Z",
    "id": "ca76bce1-8020-0000-00ff-23346706e769",
    "data": {
        "api": "PutBlob",
        "clientRequestId": "58fbfee9-6cf5-4096-9666-c42980beee65",
        "requestId": "ca76bce1-8020-0000-00ff-233467000000",
        "etag": "0x8D9F2169F42D701",
        "contentType": "application/octet-stream",
        "contentLength": 128,
        "blobType": "BlockBlob",
        "blobVersion": "2022-02-17T16:11:52.5901564Z",
        "containerVersion": "0000000000000001",
        "blobTier": "Archive",
        "url": "https://www.myurl.com",
        "sequencer": "00000000000000010000000000000002000000000000001d",
        "previousInfo": {
            "SoftDeleteSnapshot": "2022-02-17T13:08:42.4825913Z",
            "WasBlobSoftDeleted": "true",
            "BlobVersion": "2024-02-17T16:11:52.0781797Z",
            "LastVersion" : "2022-02-17T16:11:52.0781797Z",
            "PreviousTier": "Hot"
        },
        "snapshot": "2022-02-17T16:09:16.7261278Z",
        "blobPropertiesUpdated" : {
            "ContentLanguage" : {
                "current" : "pl-Pl",
                "previous" : "nl-NL"
            },
            "CacheControl" : {
                "current" : "max-age=100",
                "previous" : "max-age=99"
            },
            "ContentEncoding" : {
                "current" : "gzip, identity",
                "previous" : "gzip"
            },
            "ContentMD5" : {
                "current" : "Q2h1Y2sgSW51ZwDIAXR5IQ==",
                "previous" : "Q2h1Y2sgSW="
            },
            "ContentDisposition" : {
                "current" : "attachment",
                "previous" : ""
            },
            "ContentType" : {
                "current" : "application/json",
                "previous" : "application/octet-stream"
            }
        },
        "asyncOperationInfo": {
            "DestinationTier": "Hot",
            "WasAsyncOperation": "true",
            "CopyId": "copyId"
        },
        "storageDiagnostics": {
            "bid": "9d72687f-8006-0000-00ff-233467000000",
            "seq": "(2,18446744073709551615,29,29)",
            "sid": "4cc94e71-f6be-75bf-e7b2-f9ac41458e5a"
        }
    }
}

Schemaversion 5

Die folgenden Ereignistypen können in den Änderungsfeedeinträgen mit Schemaversion 5 erfasst werden:

  • BlobCreated
  • BlobDeleted
  • BlobPropertiesUpdated
  • BlobSnapshotCreated
  • BlobTierChanged
  • BlobAsyncOperationInitiated

Das folgende Beispiel zeigt einen Eintrag für ein Änderungsereignis im JSON-Format, bei dem die Ereignisschemaversion 5 verwendet wird:

{
    "schemaVersion": 5,
    "topic": "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "subject": "/blobServices/default/containers/<container>/blobs/<blob>",
    "eventType": "BlobCreated",
    "eventTime": "2022-02-17T13:12:11.5746587Z",
    "id": "62616073-8020-0000-00ff-233467060cc0",
    "data": {
        "api": "PutBlob",
        "clientRequestId": "b3f9b39a-ae5a-45ac-afad-95ac9e9f2791",
        "requestId": "62616073-8020-0000-00ff-233467000000",
        "etag": "0x8D9F2171BE32588",
        "contentType": "application/octet-stream",
        "contentLength": 128,
        "blobType": "BlockBlob",
        "blobVersion": "2022-02-17T16:11:52.5901564Z",
        "containerVersion": "0000000000000001",
        "blobTier": "Archive",
        "url": "https://www.myurl.com",
        "sequencer": "00000000000000010000000000000002000000000000001d",
        "previousInfo": {
            "SoftDeleteSnapshot": "2022-02-17T13:12:11.5726507Z",
            "WasBlobSoftDeleted": "true",
            "BlobVersion": "2024-02-17T16:11:52.0781797Z",
            "LastVersion" : "2022-02-17T16:11:52.0781797Z",
            "PreviousTier": "Hot"
        },
        "snapshot" : "2022-02-17T16:09:16.7261278Z",
        "blobPropertiesUpdated" : {
            "ContentLanguage" : {
                "current" : "pl-Pl",
                "previous" : "nl-NL"
            },
            "CacheControl" : {
                "current" : "max-age=100",
                "previous" : "max-age=99"
            },
            "ContentEncoding" : {
                "current" : "gzip, identity",
                "previous" : "gzip"
            },
            "ContentMD5" : {
                "current" : "Q2h1Y2sgSW51ZwDIAXR5IQ==",
                "previous" : "Q2h1Y2sgSW="
            },
            "ContentDisposition" : {
                "current" : "attachment",
                "previous" : ""
            },
            "ContentType" : {
                "current" : "application/json",
                "previous" : "application/octet-stream"
            }
        },
        "asyncOperationInfo": {
            "DestinationTier": "Hot",
            "WasAsyncOperation": "true",
            "CopyId": "copyId"
        },
        "blobTagsUpdated": {
            "previous": {
                "Tag1": "Value1_3",
                "Tag2": "Value2_3"
            },
            "current": {
                "Tag1": "Value1_4",
                "Tag2": "Value2_4"
            }
        },
        "restorePointMarker": {
            "rpi": "cbd73e3d-f650-4700-b90c-2f067bce639c",
            "rpp": "cbd73e3d-f650-4700-b90c-2f067bce639c",
            "rpl": "test-restore-label",
            "rpt": "2022-02-17T13:56:09.3559772Z"
        },
        "storageDiagnostics": {
            "bid": "9d726db1-8006-0000-00ff-233467000000",
            "seq": "(2,18446744073709551615,29,29)",
            "sid": "4cc94e71-f6be-75bf-e7b2-f9ac41458e5a"
        }
    }
}

Spezifikationen

  • Änderungsereignis-Datensätze werden an den Änderungsfeed nur angefügt. Nachdem diese Datensätze angefügt wurden, sind sie unveränderlich und ihre Position bleibt stabil. Clientanwendungen können einen eigenen Prüfpunkt an der Leseposition des Änderungsfeeds verwalten.

  • Änderungsereignis-Datensätze werden innerhalb weniger Minuten nach der Änderung angefügt. Clientanwendungen können Datensätze per Streamingzugriff direkt nach deren Anfügung oder zu jedem anderen Zeitpunkt per Massenzugriff nutzen.

  • Änderungsereignis-Datensätze werden pro Blob in der Reihenfolge des Auftretens der Änderung sortiert. Die Reihenfolge von Änderungen über mehrere Blobs hinweg ist in Azure Blob Storage nicht definiert. Alle Änderungen an einem Segment sind vor allen Änderungen an nachfolgenden Segmenten aufgetreten.

  • Änderungsereignis-Datensätze werden mithilfe der Formatspezifikation Apache Avro 1.8.2 in die Protokolldatei serialisiert.

  • Änderungsereignis-Datensätze, bei denen der eventType den Wert Control aufweist, sind interne Systemdatensätze und spiegeln keine Änderung an Objekten in Ihrem Konto wider. Sie können diese Datensätze unbesorgt ignorieren.

  • Werte im Eigenschaftenbehälter storageDiagnostics dienen nur zur internen Verwendung und sind nicht für die Verwendung durch Ihre Anwendung konzipiert. Ihre Anwendungen sollten keine vertragliche Abhängigkeit von diesen Daten aufweisen. Sie können diese Eigenschaften unbesorgt ignorieren.

  • Die vom Segment dargestellte Uhrzeit ist ein ungefährer Wert mit einem Spielraum von 15 Minuten vorher und nachher. Um also sicherzustellen, dass alle Datensätze einer angegebenen Uhrzeit genutzt werden, schließen Sie auch das vorherige und das nachfolgende Stundensegment ein.

  • Jedes Segment kann eine andere Anzahl von chunkFilePaths aufweisen. Das liegt an der internen Partitionierung des Protokollstreams zur Verwaltung des Durchsatzes bei der Veröffentlichung. Die Protokolldateien in jedem chunkFilePath enthalten garantiert sich gegenseitig ausschließende Blobs und können parallel genutzt und verarbeitet werden, ohne dass dabei die Reihenfolge der Änderungen pro Blob während der Iteration verändert wird.

  • Die Segmente beginnen im Status Publishing. Nachdem das Anfügen der Datensätze an das Segment abgeschlossen ist, lautet der Status Finalized. Protokolldateien in einem Segment, das nach dem Datum der LastConsumable-Eigenschaft in der Datei $blobchangefeed/meta/Segments.json datiert ist, sollten von Ihrer Anwendung nicht genutzt werden. Im Folgenden sehen Sie ein Beispiel der LastConsumable-Eigenschaft in einer $blobchangefeed/meta/Segments.json-Datei:

{
    "version": 0,
    "lastConsumable": "2019-02-23T01:10:00.000Z",
    "storageDiagnostics": {
        "version": 0,
        "lastModifiedTime": "2019-02-23T02:24:00.556Z",
        "data": {
            "aid": "55e551e3-8006-0000-00da-ca346706bfe4",
            "lfz": "2019-02-22T19:10:00.000Z"
        }
    }
}

Bedingungen und bekannte Probleme

Dieser Abschnitt enthält Informationen zu bekannten Problemen und Bedingungen im aktuellen Release des Änderungsfeeds.

  • Die Eigenschaft url der Protokolldatei ist aktuell immer leer.
  • Die LastConsumable-Eigenschaft der segments.json-Datei listet das allererste Segment, das vom Änderungsfeed abgeschlossen wird, nicht auf. Dieses Problem tritt nur nach Abschluss des ersten Segments auf. Alle nachfolgenden Segmente nach der ersten Stunde werden ordnungsgemäß in der LastConsumable-Eigenschaft aufgezeichnet.
  • Der Container $blobchangefeed kann zurzeit nicht angezeigt werden, wenn Sie die ListContainers-API aufrufen, und er wird auch nicht im Azure-Portal oder im Speicher-Explorer angezeigt. Sie können den Inhalt anzeigen, indem Sie die ListBlobs-API für den $blobchangefeed-Container direkt aufrufen.
  • Bei Speicherkonten, für die zuvor ein Kontofailover initiiert wurde, kann es vorkommen, dass die Protokolldatei nicht angezeigt wird. Auch bei zukünftigen Kontofailovern kann es zu Problemen mit der Protokolldatei kommen.

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.

Häufig gestellte Fragen

Worin besteht der Unterschied zwischen dem Änderungsfeed und Storage Analytics-Protokollierung?

In Analytics-Protokollen werden alle Lese-, Schreib-, Auflistungs- und Löschvorgänge mit erfolgreichen und nicht erfolgreichen Anforderungen für alle Vorgänge erfasst. Analytics-Protokolle werden bestmöglich erstellt und es wird keine Reihenfolge garantiert.

Der Änderungsfeed ist eine Lösung, die Transaktionsprotokolle von erfolgreichen Mutationen oder Änderungen an Ihrem Konto bereitstellt, z B. die Erstellung, Änderung und Löschung von Blobs. Beim Änderungsfeed werden alle Ereignisse garantiert in der Reihenfolge von erfolgreichen Änderungen pro Blob aufgezeichnet und angezeigt. Deshalb müssen keine überflüssigen Daten aus einer großen Menge von Lesevorgängen oder fehlerhaften Anforderungen herausgefiltert werden. Der Änderungsfeed ist grundsätzlich für die Entwicklung von Anwendungen konzipiert und optimiert, die bestimmte Garantien erfordern.

Sollte ich den Änderungsfeed oder Storage-Ereignisse verwenden?

Sie können beide Features nutzen, da der Änderungsfeed und Blob Storage-Ereignisse dieselben Informationen mit derselben garantierten Zuverlässigkeit bei der Übermittlung liefern. Der Hauptunterschied besteht in der Wartezeit, Sortierung und Speicherung von Ereignisdatensätzen. Der Änderungsfeed veröffentlicht Datensätze wenige Minuten nach der Änderung im Protokoll und garantiert außerdem die Reihenfolge von Änderungsvorgängen pro Blob. Blob Storage-Ereignisse werden in Echtzeit per Pushübertragung übermittelt und sind möglicherweise nicht geordnet. Änderungsfeedereignisse werden in Ihrem Speicherkonto dauerhaft als schreibgeschützte, stabile Protokolle gespeichert. Storage-Ereignisse sind dagegen kurzlebig und für die Nutzung durch den Ereignishandler vorgesehen (es sei denn, sie werden explizit gespeichert). Beim Änderungsfeed können die Protokolle von einer beliebigen Anzahl Ihrer Anwendungen nach Bedarf über Blob-APIs oder -SDKs genutzt werden.

Nächste Schritte