Gestisci gli errori di consegna dei dati

Modalità Focus

Gestisci gli errori di consegna dei dati - Amazon Data Firehose

Amazon S3 Amazon Redshift Amazon OpenSearch Service e OpenSearch Serverless Splunk Destinazione endpoint HTTP Snowflake

Ogni destinazione Amazon Data Firehose dispone di una propria gestione degli errori di consegna dei dati.

Quando si configura uno stream Firehose, per molte destinazioni come OpenSearch gli endpoint Splunk e HTTP, si configura anche un bucket S3 in cui è possibile eseguire il backup dei dati che non vengono consegnati. Per ulteriori informazioni su come Firehose esegue il backup dei dati in caso di mancate consegne, consultate le sezioni relative alla destinazione in questa pagina. Per ulteriori informazioni su come concedere l'accesso ai bucket S3 in cui è possibile eseguire il backup dei dati che non vengono consegnati, consulta Concedere l'accesso a Firehose a una destinazione Amazon S3. Quando Firehose (a) non riesce a consegnare i dati alla destinazione dello stream e (b) non riesce a scrivere i dati nel bucket S3 di backup in caso di consegne non riuscite, di fatto sospende la consegna dello stream fino al momento in cui i dati possono essere consegnati alla destinazione o scritti nella posizione di backup S3.

Amazon S3

La distribuzione dei dati sul bucket S3 potrebbe non riuscire per diversi motivi. Ad esempio, il bucket potrebbe non esistere più, il ruolo IAM che Amazon Data Firehose presuppone potrebbe non avere accesso al bucket, il problema di rete o eventi simili. In queste condizioni, Amazon Data Firehose continua a riprovare per un massimo di 24 ore fino al completamento della consegna. Il tempo massimo di archiviazione dei dati di Amazon Data Firehose è di 24 ore. Se la distribuzione dei dati non va a buon fine per più di 24 ore, i dati vengono persi.

La consegna dei dati al bucket S3 può fallire per vari motivi, ad esempio:

Il bucket non esiste più.
Il ruolo IAM assunto da Amazon Data Firehose non ha accesso al bucket.
Problemi di rete.
Errori S3, come HTTP 500 o altri errori dell'API.

In questi casi, Amazon Data Firehose riproverà la consegna:

DirectPut fonti: i tentativi continuano per un massimo di 24 ore.
Sorgenti Kinesis Data Streams o Amazon MSK: i nuovi tentativi continuano a tempo indeterminato, fino alla politica di conservazione definita nello stream.

Amazon Data Firehose invia i record non riusciti a un bucket di errore S3 solo quando l'elaborazione Lambda o la conversione del parquet falliscono. Altri scenari di errore comporteranno continui tentativi di riprovare S3 fino al raggiungimento del periodo di conservazione. Quando Firehose invia correttamente i record a S3, crea un file oggetto S3 e, in caso di errori parziali dei record, riprova automaticamente il recapito e aggiorna lo stesso file oggetto S3 con i record elaborati correttamente.

Amazon Redshift

Per una destinazione Amazon Redshift, puoi specificare una durata dei tentativi (0—7200 secondi) durante la creazione di uno stream Firehose.

La distribuzione dei dati sul cluster con provisioning Amazon Redshift o sul gruppo di lavoro Amazon Redshift serverless potrebbe non riuscire per diversi motivi. Ad esempio, potresti avere una configurazione cluster errata del tuo flusso Firehose, un cluster o un gruppo di lavoro in manutenzione o un errore di rete. In queste condizioni, Amazon Data Firehose riprova per il periodo di tempo specificato e salta quel particolare batch di oggetti Amazon S3. Le informazioni relative agli oggetti non elaborati vengono inviate al bucket S3 sotto forma di file manifest nella cartella errors/, che potrai utilizzare per recuperare le informazioni manualmente. Per ulteriori informazioni su come copiare manualmente i file manifest, consulta Utilizzo di un manifest per specificare i file di dati.

Amazon OpenSearch Service e OpenSearch Serverless

Per la destinazione OpenSearch Service e OpenSearch Serverless, è possibile specificare una durata del nuovo tentativo (0—7200 secondi) durante la creazione del flusso Firehose.

La consegna dei dati al cluster di OpenSearch servizio o alla raccolta OpenSearch Serverless potrebbe non riuscire per diversi motivi. Ad esempio, si potrebbe avere una configurazione errata del cluster di OpenSearch servizio o della raccolta OpenSearch Serverless del flusso Firehose, OpenSearch un cluster di servizio OpenSearch o una raccolta Serverless in manutenzione, un errore di rete o eventi simili. In queste condizioni, Amazon Data Firehose riprova per la durata specificata e quindi salta quella particolare richiesta di indice. I documenti non elaborati vengono distribuiti sul bucket S3 nella cartella AmazonOpenSearchService_failed/, che potrai utilizzare per recuperare le informazioni manualmente.

Per OpenSearch Service, ogni documento ha il seguente formato JSON:


{
    "attemptsMade": "(number of index requests attempted)",
    "arrivalTimestamp": "(the time when the document was received by Firehose)",
    "errorCode": "(http error code returned by OpenSearch Service)",
    "errorMessage": "(error message returned by OpenSearch Service)",
    "attemptEndingTimestamp": "(the time when Firehose stopped attempting index request)",
    "esDocumentId": "(intended OpenSearch Service document ID)",
    "esIndexName": "(intended OpenSearch Service index name)",
    "esTypeName": "(intended OpenSearch Service type name)",
    "rawData": "(base64-encoded document data)"
}

Per OpenSearch Serverless, ogni documento ha il seguente formato JSON:



{
    "attemptsMade": "(number of index requests attempted)",
    "arrivalTimestamp": "(the time when the document was received by Firehose)",
    "errorCode": "(http error code returned by OpenSearch Serverless)",
    "errorMessage": "(error message returned by OpenSearch Serverless)",
    "attemptEndingTimestamp": "(the time when Firehose stopped attempting index request)",
    "osDocumentId": "(intended OpenSearch Serverless document ID)",
    "osIndexName": "(intended OpenSearch Serverless index name)",
    "rawData": "(base64-encoded document data)"
}

Splunk

Quando Amazon Data Firehose invia dati a Splunk, attende una conferma da parte di Splunk. Se si verifica un errore o la conferma non arriva entro il periodo di timeout del riconoscimento, Amazon Data Firehose avvia il contatore della durata dei nuovi tentativi. Continua a riprovare fino alla scadenza della durata dei nuovi tentativi. Successivamente, Amazon Data Firehose lo considera un errore di consegna dei dati ed esegue il backup dei dati nel bucket Amazon S3.

Ogni volta che Amazon Data Firehose invia dati a Splunk, che si tratti del tentativo iniziale o di un nuovo tentativo, riavvia il contatore del timeout di conferma. Attende quindi il riconoscimento che deve arrivare da Splunk. Anche se la durata del nuovo tentativo scade, Amazon Data Firehose attende comunque il riconoscimento fino a quando non lo riceve o non viene raggiunto il timeout di conferma. Se la conferma scade, Amazon Data Firehose verifica se è rimasto del tempo nel contatore dei tentativi. Se rimane del tempo, riprova ancora e ripete la logica fino a quando non riceve un riconoscimento o stabilisce che il tempo dei nuovi tentativi è scaduto.

Una mancata ricezione di un riconoscimento non è l'unico tipo di errore di distribuzione dei dati che si può verificare. Per informazioni sugli altri tipi di errori di distribuzione dei dati, consulta Errori di distribuzione dei dati Splunk. Qualunque errore di distribuzione dei dati attiva la logica di ripetizione se la durata dei nuovi tentativi è maggiore di 0.

Di seguito è riportato un esempio di record degli errori.


{
  "attemptsMade": 0,
  "arrivalTimestamp": 1506035354675,
  "errorCode": "Splunk.AckTimeout",
  "errorMessage": "Did not receive an acknowledgement from HEC before the HEC acknowledgement timeout expired. Despite the acknowledgement timeout, it's possible the data was indexed successfully in Splunk. Amazon Data Firehose backs up in Amazon S3 data for which the acknowledgement timeout expired.",
  "attemptEndingTimestamp": 13626284715507,
  "rawData": "MiAyNTE2MjAyNzIyMDkgZW5pLTA1ZjMyMmQ1IDIxOC45Mi4xODguMjE0IDE3Mi4xNi4xLjE2NyAyNTIzMyAxNDMzIDYgMSA0MCAxNTA2MDM0NzM0IDE1MDYwMzQ3OTQgUkVKRUNUIE9LCg==",
  "EventId": "49577193928114147339600778471082492393164139877200035842.0"
}

Destinazione endpoint HTTP

Quando Amazon Data Firehose invia dati a una destinazione endpoint HTTP, attende una risposta da tale destinazione. Se si verifica un errore o la risposta non arriva entro il periodo di timeout della risposta, Amazon Data Firehose avvia il contatore della durata dei nuovi tentativi. Continua a riprovare fino alla scadenza della durata dei nuovi tentativi. Successivamente, Amazon Data Firehose lo considera un errore di consegna dei dati ed esegue il backup dei dati nel bucket Amazon S3.

Ogni volta che Amazon Data Firehose invia dati a una destinazione endpoint HTTP, che si tratti del tentativo iniziale o di un nuovo tentativo, riavvia il contatore del timeout di risposta. Quindi attende che arrivi una risposta dalla destinazione endpoint HTTP. Anche se la durata del nuovo tentativo scade, Amazon Data Firehose attende comunque la risposta finché non la riceve o non viene raggiunto il timeout di risposta. Se il timeout di risposta scade, Amazon Data Firehose verifica se è rimasto del tempo nel contatore dei tentativi. Se rimane del tempo, riprova ancora e ripete la logica fino a quando non riceve una risposta o stabilisce che il tempo per i nuovi tentativi è scaduto.

Una mancata ricezione di una risposta non è l'unico tipo di errore di distribuzione dei dati che si può verificare. Per informazioni sugli altri tipi di errori di distribuzione dei dati, consulta Errori di distribuzione dei dati dell'endpoint HTTP

Di seguito è riportato un esempio di record degli errori.


{
	"attemptsMade":5,
	"arrivalTimestamp":1594265943615,
	"errorCode":"HttpEndpoint.DestinationException",
	"errorMessage":"Received the following response from the endpoint destination. {"requestId": "109777ac-8f9b-4082-8e8d-b4f12b5fc17b", "timestamp": 1594266081268, "errorMessage": "Unauthorized"}", 
	"attemptEndingTimestamp":1594266081318,
	"rawData":"c2FtcGxlIHJhdyBkYXRh",
	"subsequenceNumber":0,
	"dataId":"49607357361271740811418664280693044274821622880012337186.0"
}

Snowflake

Per la destinazione Snowflake, quando si crea uno stream Firehose, è possibile specificare una durata del nuovo tentativo opzionale (0-7200 secondi). Il valore predefinito per la durata dei nuovi tentativi è 60 secondi.

L'invio dei dati alla tabella Snowflake potrebbe non riuscire per diversi motivi, ad esempio una configurazione errata della destinazione Snowflake, un'interruzione di Snowflake, un errore di rete, ecc. La politica sui nuovi tentativi non si applica agli errori non recuperabili. Ad esempio, se Snowflake rifiuta il payload JSON perché nella tabella manca una colonna aggiuntiva, Firehose non tenterà di consegnarla nuovamente. Al contrario, crea un backup di tutti gli errori di inserimento dovuti a problemi di payload JSON nel bucket di errori S3.

Allo stesso modo, se la consegna non riesce a causa di un ruolo, una tabella o un database errati, Firehose non riprova e scrive i dati nel bucket S3. La durata del nuovo tentativo si applica solo in caso di errore dovuto a un problema del servizio Snowflake, problemi temporanei di rete, ecc. In queste condizioni, Firehose riprova per il periodo di tempo specificato prima di consegnarli a S3. I record con errori vengono inviati nella cartella snowflake-failed/, che è possibile utilizzare per il riempimento manuale.

Di seguito è riportato un esempio di JSON per ogni record che invii a S3.


{
    "attemptsMade": 3,
    "arrivalTimestamp": 1594265943615,
    "errorCode": "Snowflake.InvalidColumns",
    "errorMessage": "Snowpipe Streaming does not support columns of type AUTOINCREMENT, IDENTITY, GEO, or columns with a default value or collation",
    "attemptEndingTimestamp": 1712937865543,
    "rawData": "c2FtcGxlIHJhdyBkYXRh"
}