Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Lo scopo del feed di modifiche consiste nel fornire i log delle transazioni di tutte le modifiche che si verificano nei BLOB e nei metadati del BLOB nell'account di archiviazione. Il feed di modifiche fornisce un log ordinato, garantito, durevole, non modificabile e di sola lettura di queste modifiche. Le applicazioni client possono leggere questi log in qualsiasi momento, in streaming o in modalità batch. Ogni modifica genera esattamente una voce del log delle transazioni, quindi non è necessario gestire più voci di log per la stessa modifica. Il feed di modifiche consente di creare a basso costo soluzioni efficienti e scalabili che elaborano gli eventi di modifica che si verificano nell'account di Archiviazione BLOB.
Per informazioni su come elaborare i record nel feed di modifiche, vedere Elaborare il feed di modifiche in Archiviazione BLOB di Azure.
Funzionamento del feed di modifiche
I record dei feed di modifiche vengono archiviati come BLOB in un contenitore speciale nell'account di archiviazione al costo standard indicato nel prezzi dei BLOB. È possibile controllare il periodo di conservazione di questi file in base alle proprie esigenze. Vedere le condizioni della versione corrente. Gli eventi di modifica vengono aggiunti al feed di modifiche come record nella specifica del formato Apache Avro: un formato binario compatto e veloce che fornisce strutture di dati avanzate con schema inline. Questo formato è largamente usato nell'ecosistema Hadoop, dall'analisi di flusso e da Azure Data Factory.
È possibile elaborare questi log in modo asincrono, incrementale o completo. Qualsiasi numero di applicazioni client può leggere in modo indipendente il feed di modifiche, in parallelo e in base al proprio ritmo. Le applicazioni di analisi, ad esempio Apache Drill o Apache Spark, possono usare i log direttamente come file Avro, che possono essere elaborati a basso costo, con larghezza di banda elevata e senza dover scrivere un'applicazione personalizzata.
Il diagramma seguente mostra il modo in cui i record vengono aggiunti al feed di modifiche:
Il supporto del feed di modifiche è particolarmente adatto per gli scenari che elaborano i dati in base agli oggetti modificati. Ad esempio, le applicazioni possono:
- Aggiornare un indice secondario ed eseguire la sincronizzazione con una cache, un motore di ricerca o qualsiasi altro scenario di gestione dei contenuti.
- Estrarre informazioni dettagliate e metriche sulle analisi di business basate sulle modifiche apportate agli oggetti in modalità flusso o batch.
- Archiviare, controllare e analizzare le modifiche apportate agli oggetti, in qualsiasi intervallo di tempo, per la gestione dei dati sulla sicurezza, la conformità o l'intelligenza a livello aziendale.
- Creare soluzioni per eseguire il backup, il mirroring o replicare lo stato dell'oggetto nell'account per la gestione delle emergenze o la conformità.
- Creare pipeline di applicazioni connesse che reagiscono agli eventi di modifica o pianificano le esecuzioni in base all'oggetto creato o modificato.
Il feed di modifiche è una funzionalità prerequisita per la Replica di oggetti e il Ripristino temporizzato per i BLOB in blocchi.
Nota
Il feed di modifiche fornisce un modello di log ordinato e durevole delle modifiche apportate a un BLOB. Le modifiche vengono scritte e rese disponibili nel log del feed di modifiche entro pochi minuti dalla modifica. Se l'applicazione deve reagire agli eventi in modo molto più rapido, è consigliabile usare invece gli eventi di Archiviazione BLOB. Gli eventi di Archiviazione BLOB forniscono eventi monouso in tempo reale che consentono alle funzioni o alle applicazioni di Azure di reagire rapidamente alle modifiche apportate a un BLOB.
Abilitare e disabilitare il feed di modifiche
È necessario abilitare il feed di modifiche nell'account di archiviazione per avviare l'acquisizione e la registrazione delle modifiche. Disabilitare il feed di modifiche per interrompere l'acquisizione delle modifiche. È possibile abilitare e disabilitare le modifiche usando i modelli di Azure Resource Manager nel portale o in PowerShell.
Ecco alcuni aspetti da tenere presenti quando si abilita il feed di modifiche.
In ogni account di archiviazione è presente un solo feed di modifiche per il servizio BLOB. I record del feed di modifiche vengono archiviati nel contenitore $blobchangefeed.
Le modifiche di tipo creazione, aggiornamento ed eliminazione vengono acquisite solo a livello di servizio BLOB.
Il feed di modifiche acquisisce tutte le modifiche per tutti gli eventi disponibili che si verificano nell'account. Le applicazioni client possono filtrare i tipi di evento in base alle esigenze. Vedere le condizioni della versione corrente.
Solo gli account Standard per utilizzo generico v2, BLOB in blocchi Premium e Archiviazione BLOB possono abilitare il feed di modifiche. Gli account con uno spazio dei nomi gerarchico abilitato non sono attualmente supportati. Gli account di archiviazione per utilizzo generico v1 non sono supportati, ma possono essere aggiornati alla versione per utilizzo generico v2 senza tempi di inattività. Per altre informazioni, vedere Eseguire l'aggiornamento a un account di archiviazione per utilizzo generico v2.
Abilitare il feed di modifiche nell'account di archiviazione usando il portale di Azure:
Selezionare l'account di archiviazione nel portale di Azure.
Passare all'opzione Protezione dati in Gestione dati.
In Rilevamento selezionare Abilita feed di modifiche BLOB.
Scegliere il pulsante Salva per confermare le impostazioni di protezione dei dati.
Utilizzare il feed di modifiche
Il feed di modifiche produce diversi file di metadati e di log. Questi file si trovano nel contenitore $blobchangefeed dell'account di archiviazione. Il contenitore $blobchangefeed può essere visualizzato tramite il portale di Azure o tramite Azure Storage Explorer.
Le applicazioni client possono utilizzare il feed di modifiche usando la libreria del processore dei feed di modifiche BLOB fornita con l'SDK del processore dei feed di modifiche. Per informazioni su come elaborare i record nel feed di modifiche, vedere Elaborare i log del feed di modifiche in Archiviazione BLOB di Azure.
Segmenti di feed di modifiche
Il feed di modifiche è un log delle modifiche organizzate in segmenti orari ma aggiunti a e aggiornati ogni pochi minuti. Questi segmenti vengono creati solo quando si verificano eventi di modifica del BLOB in quell'ora. Ciò consente all'applicazione client di utilizzare le modifiche che si verificano entro intervalli di tempo specifici senza dover eseguire ricerche nell'intero log. Per altre informazioni, vedere le Specifiche.
Un segmento orario disponibile del feed di modifiche viene descritto in un file manifesto che specifica i percorsi dei file del feed di modifiche per tale segmento. L'elenco della directory virtuale $blobchangefeed/idx/segments/ mostra questi segmenti ordinati in base all'ora. Il percorso del segmento descrive l'inizio dell'intervallo di tempo orario rappresentato dal segmento. È possibile usare tale elenco per filtrare i segmenti dei log di interesse.
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
Nota
Il file $blobchangefeed/idx/segments/1601/01/01/0000/meta.json viene creato automaticamente quando si abilita il feed di modifiche. È possibile ignorare senza problemi questo file. Si tratta di un file di inizializzazione sempre vuoto.
Il file manifesto del segmento (meta.json) mostra il percorso dei file del feed di modifiche per tale segmento nella proprietà chunkFilePaths. Di seguito è riportato un esempio di file manifesto di segmento.
{
"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"
}
}
}
Nota
Il contenitore $blobchangefeed viene visualizzato solo dopo l'abilitazione della funzionalità feed di modifiche nell'account. È necessario attendere alcuni minuti dopo aver abilitato il feed di modifiche prima di poter elencare i BLOB nel contenitore.
Record di eventi di modifica
I file del feed di modifiche contengono una serie di record di eventi di modifica. Ogni record di eventi di modifica corrisponde a una modifica a un singolo BLOB. I record vengono serializzati e scritti nel file usando la specifica del formato Apache Avro. I record possono essere letti usando la specifica del formato di file Avro. Sono disponibili diverse librerie per elaborare i file in tale formato.
I file dei feed di modifiche vengono archiviati nella directory virtuale $blobchangefeed/log/ come BLOB di accodamento. Il primo file del feed di modifiche in ogni percorso avrà 00000 nel nome del file ( ad esempio 00000.avro). Il nome di ogni file di log successivo aggiunto a tale percorso verrà incrementato di 1 (ad esempio: 00001.avro).
Schemi dei record di eventi
Per una descrizione di ogni proprietà, vedere Schema di eventi di Griglia di eventi di Azure per Archiviazione BLOB. Gli eventi BlobPropertiesUpdated e BlobSnapshotCreated sono attualmente esclusivi del feed di modifiche e non sono ancora supportati per gli eventi di Archiviazione BLOB.
Nota
I file del feed di modifiche per un segmento non vengono visualizzati immediatamente dopo la creazione di un segmento. La lunghezza del ritardo rientra nell'intervallo normale della latenza di pubblicazione del feed di modifiche, ovvero entro pochi minuti dalla modifica.
Schema versione 1
I tipi di evento seguenti possono essere acquisiti nei record del feed di modifiche con schema versione 1:
- BlobCreated
- BlobDeleted
- BlobPropertiesUpdated
- BlobSnapshotCreated
L'esempio seguente mostra un record di eventi di modifica in formato JSON che usa lo schema eventi versione 1:
{
"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"
}
}
}
Schema versione 3
I tipi di evento seguenti possono essere acquisiti nei record del feed di modifiche con schema versione 3:
- BlobCreated
- BlobDeleted
- BlobPropertiesUpdated
- BlobSnapshotCreated
L'esempio seguente mostra un record di eventi di modifica in formato JSON che usa lo schema eventi versione 3:
{
"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"
}
}
}
Schema versione 4
I tipi di evento seguenti possono essere acquisiti nei record del feed di modifiche con schema versione 4:
- BlobCreated
- BlobDeleted
- BlobPropertiesUpdated
- BlobSnapshotCreated
- BlobTierChanged
- BlobAsyncOperationInitiated
- RestorePointMarkerCreated
L'esempio seguente mostra un record di eventi di modifica in formato JSON che usa lo schema eventi versione 4:
{
"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"
}
}
}
Schema versione 5
I tipi di evento seguenti possono essere acquisiti nei record del feed di modifiche con schema versione 5:
- BlobCreated
- BlobDeleted
- BlobPropertiesUpdated
- BlobSnapshotCreated
- BlobTierChanged
- BlobAsyncOperationInitiated
L'esempio seguente mostra un record di eventi di modifica in formato JSON che usa lo schema eventi versione 5:
{
"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"
}
}
}
Schema versione 6
I tipi di evento seguenti possono essere acquisiti nei record del feed di modifiche con schema versione 6:
- BlobCreated
- BlobDeleted
- BlobPropertiesUpdated
- BlobSnapshotCreated
- BlobTierChanged
- BlobAsyncOperationInitiated
Lo schema versione 6 aggiunge il supporto per livello ad accesso saltuario.
L'esempio seguente mostra un record di eventi di modifica in formato JSON che usa lo schema eventi versione 6:
{
"schemaVersion": 6,
"topic": "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
"subject": "/blobServices/default/containers/<container>/blobs/<blob>",
"eventType": "BlobCreated",
"eventTime": "2023-10-11T13: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": "2023-10-11T16:11:52.5901564Z",
"containerVersion": "0000000000000001",
"blobTier": "Archive",
"url": "https://www.myurl.com",
"sequencer": "00000000000000010000000000000002000000000000001d",
"previousInfo": {
"SoftDeleteSnapshot": "2023-10-11T13:12:11.5726507Z",
"WasBlobSoftDeleted": "true",
"BlobVersion": "2024-02-17T16:11:52.0781797Z",
"LastVersion" : "2023-10-11T16:11:52.0781797Z",
"PreviousTier": "Hot"
},
"snapshot" : "2023-10-11T16: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": "2023-10-11T13:56:09.3559772Z"
},
"storageDiagnostics": {
"bid": "9d726db1-8006-0000-00ff-233467000000",
"seq": "(2,18446744073709551615,29,29)",
"sid": "4cc94e71-f6be-75bf-e7b2-f9ac41458e5a"
}
}
}
Specifiche
I record di eventi di modifica vengono aggiunti solo al feed di modifiche. Dopo l'accodamento, questi record sono non modificabili e la posizione dei record è stabile. Le applicazioni client possono mantenere il proprio checkpoint nella posizione di lettura del feed di modifiche.
I record di eventi di modifica vengono accodati entro pochi minuti dalla modifica. Le applicazioni client possono scegliere di utilizzare i record non appena vengono aggiunti per l'accesso in streaming o in blocco in qualsiasi altro momento.
I record di eventi di modifica vengono ordinati in base all'ordine di modifica per ogni BLOB. L'ordine delle modifiche nei BLOB non è definito in Archiviazione BLOB di Azure. Tutte le modifiche apportate a un segmento precedente vengono visualizzate prima di eventuali modifiche nei segmenti successivi.
I record di eventi di modifica vengono serializzati nel file di log usando la specifica del formato Apache Avro 1.8.2.
I record di eventi di modifica in cui
eventTypeha un valore pari aControlsono record di sistema interni e non riflettono una modifica agli oggetti nell'account. È possibile ignorare senza problemi tali record.I valori nel contenitore delle proprietà
storageDiagnosticssono destinati solo all'uso interno e non sono progettati per l'uso da parte dell'applicazione. Le applicazioni non devono avere una dipendenza contrattuale da tali dati. È possibile ignorare senza problemi tali proprietà.Il tempo rappresentato dal segmento è approssimativo con limiti di 15 minuti. Per garantire l'utilizzo di tutti i record entro un periodo di tempo specificato, utilizzare quindi il segmento di ora precedente e successivo consecutivo.
Ogni segmento può avere un numero diverso di
chunkFilePathsa causa del partizionamento interno del flusso di log per gestire la velocità effettiva di pubblicazione. I file di log in ognichunkFilePathcontengono sempre BLOB che si escludono a vicenda e possono essere utilizzati ed elaborati in parallelo senza violare l'ordinamento delle modifiche per BLOB durante l'iterazione.I segmenti iniziano con lo stato
Publishing. Dopo il completamento dell'aggiunta dei record al segmento, saràFinalized. I file di log in qualsiasi segmento con data successiva alla data della proprietàLastConsumablenel file$blobchangefeed/meta/Segments.jsonnon devono essere utilizzati dall'applicazione. Di seguito è riportato un esempio della proprietàLastConsumablein un file$blobchangefeed/meta/Segments.json:
{
"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"
}
}
}
Condizioni e problemi noti
Questa sezione descrive i problemi noti e le condizioni nella versione corrente del feed di modifiche.
- Se si abilitano le regole del firewall per l'account di archiviazione, le richieste di gestione del ciclo di vita per eliminare i BLOB all'interno del contenitore $blobchangefeed potrebbero essere bloccate. È possibile sbloccarle specificando eccezioni per servizi attendibili di Microsoft. Per altre informazioni, vedere la sezione Eccezioni in Configurare firewall e reti virtuali.
- La proprietà
LastConsumabledel file segments.json non elenca il primo segmento finalizzato dal feed di modifiche. Questo problema si verifica solo dopo la finalizzazione del primo segmento. Tutti i segmenti successivi dopo la prima ora vengono acquisiti accuratamente nella proprietàLastConsumable. - Non è attualmente possibile visualizzare il contenitore $blobchangefeed quando si chiama l'API ListContainers. È possibile visualizzare il contenuto chiamando direttamente l'API ListBlobs nel contenitore $blobchangefeed.
- Il failover dell'account di archiviazione degli account di archiviazione con ridondanza geografica con il feed di modifiche abilitato può comportare incoerenze tra i log del feed di modifiche e i dati e/o i metadati dei BLOB. Per altre informazioni su tali incoerenze, vedere Incoerenze tra feed di modifiche e dati dei BLOB.
- Potrebbero essere visualizzati errori 404 (Non trovato) e 412 (Precondizione non riuscita) segnalati nei contenitori $blobchangefeed e $blobchangefeedsys. È possibile ignorare questi errori.
- Gli eventi BlobDeleted non vengono generati quando vengono eliminate versioni o snapshot di BLOB. Un evento BlobDeleted viene aggiunto solo quando viene eliminato un BLOB di base (radice).
- I record di eventi vengono aggiunti solo per le modifiche ai BLOB risultanti dalle richieste all'endpoint del servizio BLOB (
blob.core.windows.net). Le modifiche risultanti dalle richieste all'endpoint di Data Lake Storage (dfs.core.windows.net) non vengono registrate e non verranno visualizzate nei record di feed di modifiche.
Domande frequenti
Vedere Domande frequenti sul supporto del feed di modifiche.
Supporto funzionalità
Il supporto di questa funzionalità potrebbe essere influenzato dall'abilitazione dei protocolli Data Lake Storage Gen2, NFS (Network File System) 3.0 o SFTP (SSH File Transfer Protocol). Se è stata abilitata una di queste funzionalità, vedere Supporto delle funzionalità di Archiviazione BLOB negli account di Archiviazione di Azure per valutare il supporto per questa funzionalità.