Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Comprendi la distribuzione dei dati in Amazon Data Firehose Quando invii dati al tuo stream Firehose, questi vengono consegnati automaticamente alla destinazione prescelta. La tabella seguente spiega la consegna dei dati a diverse destinazioni. | Destinazione | Informazioni | | --- | --- | | Simple Storage Service (Amazon S3) | Per la distribuzione dei dati ad Amazon S3, Firehose concatena più record in entrata in base alla configurazione di buffering del flusso Firehose. Quindi distribuisce i record ad Amazon S3 come oggetto Amazon S3. Per impostazione predefinita, Firehose concatena i dati senza delimitatori. [Se si desidera disporre di nuovi delimitatori di riga tra i record, è possibile aggiungere nuovi delimitatori di riga abilitando la funzionalità nella configurazione della console [Firehose](https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html#create-destination-s3) o nel parametro API.](https://docs.aws.amazon.com/firehose/latest/APIReference/API_Processor.html) La consegna dei dati tra Firehose e la destinazione Amazon S3 è crittografata con TLS (HTTPS). | | Amazon Redshift | Per la distribuzione dei dati ad Amazon Redshift, Firehose invia innanzitutto i dati in entrata al bucket S3 nel formato descritto in precedenza. Firehose emette quindi un comando Amazon **COPY** Redshift per caricare i dati dal bucket S3 al cluster con provisioning di Amazon Redshift o al gruppo di lavoro Serverless Amazon Redshift. Assicurati che, dopo che Amazon Data Firehose ha concatenato più record in entrata in un oggetto Amazon S3, l'oggetto Amazon S3 possa essere copiato nel cluster con provisioning di Amazon Redshift o nel gruppo di lavoro Amazon Redshift Serverless. Per ulteriori informazioni, vedi i [parametri del formato dati del comando COPY di Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-format.html). | | OpenSearch OpenSearch Service e Serverless | Per la distribuzione dei dati a OpenSearch Service e OpenSearch Serverless, Amazon Data Firehose memorizza nel buffer i record in entrata in base alla configurazione di buffering del flusso Firehose. Quindi genera una richiesta in blocco di OpenSearch Service o OpenSearch Serverless per indicizzare più record nel cluster di servizio o nella raccolta Serverless. OpenSearch OpenSearch Assicurati che il record sia codificato in UTF-8 e appiattito in un oggetto JSON a riga singola prima di inviarlo ad Amazon Data Firehose. Inoltre, l'rest.action.multi.allow\$1explicit\$1indexopzione per il cluster di OpenSearch servizio deve essere impostata su true (impostazione predefinita) per accettare richieste in blocco con un indice esplicito impostato per record. Per ulteriori informazioni, consulta [OpenSearch Service Configure Advanced Options](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/es-createupdatedomains.html#es-createdomain-configure-advanced-options) nella Amazon OpenSearch Service Developer Guide. | | Splunk | Per la consegna dei dati a Splunk, Amazon Data Firehose concatena i byte inviati. Se nei dati vuoi dei delimitatori, come un carattere di nuova riga, devi inserirli manualmente. Verifica che Splunk sia configurato per analizzare questo tipo di delimitatori. [Per reindirizzare a Splunk i dati che sono stati consegnati al bucket di errore S3 (backup S3), segui i passaggi indicati nella documentazione di Splunk.](https://www.splunk.com/en_us/blog/tips-and-tricks/aws-technical-add-on-simplifying-error-data-re-ingestion.html) | | Endpoint HTTP | Per la consegna dei dati a un endpoint HTTP di proprietà di un fornitore di servizi terzo supportato, puoi utilizzare il servizio integrato Amazon Lambda per creare una funzione per trasformare i record in entrata nel formato che corrisponde al formato previsto dall'integrazione del fornitore di servizi. Contatta il fornitore di servizi di terze parti di cui hai scelto l'endpoint HTTP come destinazione per saperne di più sul formato di record accettato. | | Snowflake | Per la consegna dei dati a Snowflake, Amazon Data Firehose memorizza internamente i dati nel buffer per un secondo e utilizza le operazioni dell'API di streaming Snowflake per inserire dati in Snowflake. Per impostazione predefinita, i record inseriti vengono cancellati e trasferiti nella tabella Snowflake ogni secondo. Dopo aver effettuato la chiamata di inserimento, Firehose emette una CloudWatch metrica che misura il tempo impiegato per il commit dei dati su Snowflake. Attualmente Firehose supporta solo un singolo elemento JSON come payload di record e non supporta gli array JSON. Assicurati che il payload di input sia un oggetto JSON valido e che sia ben formato senza virgolette, virgolette o caratteri di escape aggiuntivi. | Ogni destinazione Firehose ha una propria frequenza di consegna dei dati. Per ulteriori informazioni, consulta [Configura i suggerimenti per il buffering](create-configure-backup.md#buffering-hints). **Duplicazione di record** Amazon Data Firehose utilizza la at-least-once semantica per la distribuzione dei dati. In alcune circostanze, ad esempio quando scadono i tempi di consegna dei dati, i nuovi tentativi di consegna da parte di Amazon Data Firehose potrebbero creare duplicati se la richiesta originale di consegna dei dati alla fine viene accolta. Questo vale per tutti i tipi di destinazione supportati da Amazon Data Firehose, ad eccezione delle destinazioni Amazon S3, Apache Iceberg Tables e Snowflake. **Topics** + [Comprendi la distribuzione tra account e regioni AWS](across.md) + [Comprendi le specifiche di richiesta e risposta di consegna degli endpoint HTTP](httpdeliveryrequestresponse.md) + [Gestisci gli errori di consegna dei dati](retry.md) + [Configurazione del formato dei nomi degli oggetti Amazon S3](s3-object-name.md) + [Configura la rotazione dell'indice per Service OpenSearch](es-index-rotation.md) + [Sospendere e riprendere la consegna dei dati](pause-restart-stream.md) # Comprendi la distribuzione tra account e regioni AWS Amazon Data Firehose supporta la distribuzione di dati verso destinazioni endpoint HTTP tra diversi account. AWS Lo stream Firehose e l'endpoint HTTP che scegli come destinazione possono appartenere a diversi account. AWS Amazon Data Firehose supporta anche la distribuzione di dati verso destinazioni endpoint HTTP in tutte le regioni. AWS È possibile inviare dati da un flusso Firehose in una AWS regione a un endpoint HTTP in un'altra regione. AWS È inoltre possibile inviare dati da un flusso Firehose a una destinazione endpoint HTTP al di fuori delle AWS regioni, ad esempio al proprio server locale impostando l'URL dell'endpoint HTTP sulla destinazione desiderata. Per questi scenari, ai costi di distribuzione si aggiungono ulteriori costi di trasferimento dati. Per ulteriori informazioni, consulta la sezione [Trasferimento dati](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer) della pagina "Prezzi on demand". # Comprendi le specifiche di richiesta e risposta di consegna degli endpoint HTTP Affinché Amazon Data Firehose fornisca correttamente i dati agli endpoint HTTP personalizzati, questi endpoint devono accettare richieste e inviare risposte utilizzando determinati formati di richiesta e risposta di Amazon Data Firehose. Questa sezione descrive le specifiche di formato delle richieste HTTP che il servizio Amazon Data Firehose invia agli endpoint HTTP personalizzati, nonché le specifiche di formato delle risposte HTTP che il servizio Amazon Data Firehose si aspetta. Gli endpoint HTTP dispongono di 3 minuti per rispondere a una richiesta prima che Amazon Data Firehose effettui il timeout della richiesta. Amazon Data Firehose considera le risposte che non rispettano il formato corretto come errori di consegna. ## Formato della richiesta **Parametri relativi al percorso e all'URL** Questi parametri sono configurati direttamente dall'utente come parte di un singolo campo URL. Amazon Data Firehose li invia così come configurati senza modifiche. Sono supportate solo le destinazioni https. Le restrizioni relative agli URL vengono applicate durante la configurazione del flusso di distribuzione. Attualmente, solo la porta 443 è supportata per la distribuzione dei dati degli endpoint HTTP. **Intestazioni HTTP - -Versione X-Amz-Firehose-Protocol** Questa intestazione viene utilizzata per indicare la versione dei formati di richiesta/risposta. Attualmente, l'unica versione consentita è 1.0. **Intestazioni HTTP - -Id X-Amz-Firehose-Request** Il valore di questa intestazione è un GUID opaco che può essere utilizzato per scopi di debug e deduplicazione. Le implementazioni degli endpoint devono registrare il valore di questa intestazione, se possibile, sia per le richieste riuscite che per quelle non riuscite. L'ID della richiesta viene mantenuto invariato tra più tentativi della stessa richiesta. **Intestazioni HTTP: Content-Type** Il valore dell'intestazione Content-Type è sempre `application/json`. **Intestazioni HTTP: Content-Encoding** Uno stream Firehose può essere configurato per utilizzare GZIP per comprimere il body durante l'invio delle richieste. Quando questa compressione è abilitata, il valore dell'intestazione Content-Encoding è impostato su gzip, come da prassi standard. Se la compressione non è abilitata, l'intestazione Content-Encoding è del tutto assente. **Intestazioni HTTP: Content-Length** Viene utilizzato nel modo standard. **Intestazioni HTTP - -Arn: X-Amz-Firehose-Source** L'ARN del flusso Firehose rappresentato in formato stringa ASCII. L'ARN codifica la regione, l'ID AWS dell'account e il nome dello stream. Ad esempio, `arn:aws:firehose:us-east-1:123456789:deliverystream/testStream`. **Intestazioni HTTP - -Key X-Amz-Firehose-Access** Questa intestazione contiene una chiave API o altre credenziali. Hai la possibilità di creare o aggiornare la chiave API (nota anche come token di autorizzazione) durante la creazione o l'aggiornamento del flusso di distribuzione. Amazon Data Firehose limita la dimensione della chiave di accesso a 4096 byte. Amazon Data Firehose non tenta di interpretare questa chiave in alcun modo. La chiave configurata viene copiata letteralmente nel valore di questa intestazione. Tuttavia, se si utilizza Secrets Manager per configurare la chiave, il segreto deve seguire un formato oggetto JSON specifico:`{"api_key": "..."}`. I contenuti possono essere arbitrari e possono potenzialmente rappresentare un token JWT o un ACCESS\$1KEY. Se un endpoint richiede credenziali multi-campo (ad esempio nome utente e password), i valori di tutti i campi devono essere memorizzati insieme in un'unica chiave di accesso in un formato comprensibile all'endpoint (JSON o CSV). Questo campo può essere codificato in base 64 se i contenuti originali sono binari. Amazon Data Firehose non modifica, and/or codifica il valore configurato e utilizza i contenuti così come sono. **Intestazioni HTTP - -Attributi X-Amz-Firehose-Common** Questa intestazione contiene gli attributi comuni (metadati) relativi all'intera richiesta, a tutti i record and/or all'interno della richiesta. Questi vengono configurati direttamente dall'utente durante la creazione di uno stream Firehose. Il valore di questo attributo è codificato come oggetto JSON con il seguente schema: ``` "$schema": http://json-schema.org/draft-07/schema# properties: commonAttributes: type: object minProperties: 0 maxProperties: 50 patternProperties: "^.{1,256}$": type: string minLength: 0 maxLength: 1024 ``` Ecco un esempio: ``` "commonAttributes": { "deployment -context": "pre-prod-gamma", "device-types": "" } ``` **Corpo: dimensione massima** La dimensione massima del corpo è configurata dall'utente e può arrivare fino a un massimo di 64 MiB, prima della compressione. **Corpo: schema** Il corpo contiene un singolo documento JSON con il seguente schema JSON (scritto in YAML): ``` "$schema": http://json-schema.org/draft-07/schema# title: FirehoseCustomHttpsEndpointRequest description: > The request body that the Firehose service sends to custom HTTPS endpoints. type: object properties: requestId: description: > Same as the value in the X-Amz-Firehose-Request-Id header, duplicated here for convenience. type: string timestamp: description: > The timestamp (milliseconds since epoch) at which the Firehose server generated this request. type: integer records: description: > The actual records of the Firehose stream, carrying the customer data. type: array minItems: 1 maxItems: 10000 items: type: object properties: data: description: > The data of this record, in Base64. Note that empty records are permitted in Firehose. The maximum allowed size of the data, before Base64 encoding, is 1024000 bytes; the maximum length of this field is therefore 1365336 chars. type: string minLength: 0 maxLength: 1365336 required: - requestId - records ``` Ecco un esempio: ``` { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": 1578090901599 "records": [ { "data": "aGVsbG8=" }, { "data": "aGVsbG8gd29ybGQ=" } ] } ``` ## Formato della risposta **Comportamento predefinito in caso di errore** Se una risposta non è conforme ai requisiti seguenti, il server Firehose la considera come se avesse un codice di stato 500 senza corpo. **Codice di stato** Il codice di stato HTTP DEVE essere compreso nell'intervallo 2XX, 4XX o 5XX. Il server Amazon Data Firehose NON segue i reindirizzamenti (codici di stato 3XX). Solo il codice di risposta 200 viene considerato come una distribuzione riuscita dei record a HTTP/EP. Il codice di risposta 413 (dimensione superata) è considerato un errore permanente e il batch di record non viene inviato al bucket di errori se configurato. Tutti gli altri codici di risposta sono considerati errori recuperabili e sono soggetti all'algoritmo di back-off relativo ai nuovi tentativi illustrato più avanti. **Intestazioni: tipo di contenuto** L'unico tipo di contenuto accettabile è application/json. **Intestazioni HTTP: Content-Encoding** La codifica del contenuto NON DEVE essere utilizzata. Il corpo DEVE essere decompresso. **Intestazioni HTTP: Content-Length** L'intestazione Content-Length DEVE essere presente se la risposta ha un corpo. **Corpo: dimensione massima** Il corpo della risposta deve avere dimensioni pari o inferiori a 1 MiB. ``` "$schema": http://json-schema.org/draft-07/schema# title: FirehoseCustomHttpsEndpointResponse description: > The response body that the Firehose service sends to custom HTTPS endpoints. type: object properties: requestId: description: > Must match the requestId in the request. type: string timestamp: description: > The timestamp (milliseconds since epoch) at which the server processed this request. type: integer errorMessage: description: > For failed requests, a message explaining the failure. If a request fails after exhausting all retries, the last Instance of the error message is copied to error output S3 bucket if configured. type: string minLength: 0 maxLength: 8192 required: - requestId - timestamp ``` Ecco un esempio: ``` Failure Case (HTTP Response Code 4xx or 5xx) { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": "1578090903599", "errorMessage": "Unable to deliver records due to unknown error." } Success case (HTTP Response Code 200) { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": 1578090903599 } ``` **Gestione delle risposte di errore** In tutti i casi di errore, il server Amazon Data Firehose ritenta la consegna dello stesso batch di record utilizzando un algoritmo di back-off esponenziale. Il backup dei tentativi viene eseguito utilizzando un tempo di back-off iniziale (1 secondo) con un fattore di jitter del (15%) e ogni tentativo successivo viene bloccato utilizzando la formula (initial-backoff-time \$1 (multiplier (2) ^ retry\$1count)) con jitter aggiunto. Il tempo di back-off è limitato a un intervallo massimo di 2 minuti. Ad esempio, al 'n'-esimo tentativo, il tempo di annullamento è = MAX (120, 2^n) \$1 casuale (0,85, 1,15). I parametri specificati nell'equazione precedente sono soggetti a modifiche. Fate riferimento alla documentazione di AWS Firehose per il tempo esatto di backoff iniziale, il tempo massimo di backoff, i moltiplicatori e le percentuali di jitter utilizzate nell'algoritmo di backoff esponenziale. In ogni tentativo successivo, la and/or destinazione della chiave di accesso a cui vengono consegnati i record potrebbe cambiare in base alla configurazione aggiornata del flusso Firehose. Il servizio Amazon Data Firehose utilizza lo stesso ID di richiesta per tutti i tentativi nel miglior modo possibile. Quest'ultima funzionalità può essere utilizzata per scopi di deduplicazione dal server endpoint HTTP. Se la richiesta non viene ancora consegnata dopo il tempo massimo consentito (in base alla configurazione del flusso Firehose), il batch di record può essere facoltativamente inviato a un bucket di errori basato sulla configurazione del flusso. ## Esempi Esempio di richiesta proveniente dall'origine CWLog . ``` { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": 1578090901599, "records": [ { "data": { "messageType": "DATA_MESSAGE", "owner": "123456789012", "logGroup": "log_group_name", "logStream": "log_stream_name", "subscriptionFilters": [ "subscription_filter_name" ], "logEvents": [ { "id": "0123456789012345678901234567890123456789012345", "timestamp": 1510109208016, "message": "log message 1" }, { "id": "0123456789012345678901234567890123456789012345", "timestamp": 1510109208017, "message": "log message 2" } ] } } ] } ``` # Gestisci gli errori di consegna dei dati 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](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-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 a quando i dati non possono essere consegnati alla destinazione o scritti nella posizione di backup S3. ## Simple Storage Service (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](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-files-using-manifest.html). ## 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 del nuovo tentativo. 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](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html#monitoring-splunk-errors). 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](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html#monitoring-http-errors) 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. La consegna 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" } ``` # Configurazione del formato dei nomi degli oggetti Amazon S3 Quando Firehose fornisce dati ad Amazon S3, il nome della chiave dell'oggetto S3 segue il** formato, dove il suffisso ha il *formato - - - - - - - -* inizia con 1 e aumenta di 1 per ogni modifica di configurazione del flusso Firehose. È possibile modificare le configurazioni dei flussi Firehose (ad esempio, il nome del bucket S3, i suggerimenti di buffering, la compressione e la crittografia). È possibile farlo utilizzando la console Firehose o l'operazione [UpdateDestination](https://docs.aws.amazon.com/firehose/latest/APIReference/API_UpdateDestination.html)API. Perché**, Firehose aggiunge un prefisso orario predefinito nel formato. `YYYY/MM/dd/HH` Questo prefisso crea una gerarchia logica nel bucket, in cui ogni barra (/) crea un livello nella gerarchia. È possibile modificare questa struttura specificando un prefisso personalizzato che include espressioni valutate in fase di esecuzione. Per informazioni su come specificare un prefisso personalizzato, consulta [Prefissi personalizzati per Amazon Simple Storage](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html) Service Objects. Per impostazione predefinita, il fuso orario utilizzato per il prefisso e il suffisso orario è in UTC, ma puoi modificarlo con il fuso orario che preferisci. Ad esempio, per utilizzare l'ora solare del Giappone anziché l'UTC, puoi configurare il fuso Asia/Tokyo orario in o [nell'impostazione Console di gestione AWS del parametro API CustomTimeZone ()](https://docs.aws.amazon.com/firehose/latest/APIReference/API_ExtendedS3DestinationConfiguration.html). L'elenco seguente contiene i fusi orari supportati da Firehose per la configurazione del prefisso S3. ## Fusi orari supportati Di seguito è riportato un elenco di fusi orari supportati da Firehose per la configurazione del prefisso S3. ------ #### [ Africa ] ``` Africa/Abidjan Africa/Accra Africa/Addis_Ababa Africa/Algiers Africa/Asmera Africa/Bangui Africa/Banjul Africa/Bissau Africa/Blantyre Africa/Bujumbura Africa/Cairo Africa/Casablanca Africa/Conakry Africa/Dakar Africa/Dar_es_Salaam Africa/Djibouti Africa/Douala Africa/Freetown Africa/Gaborone Africa/Harare Africa/Johannesburg Africa/Kampala Africa/Khartoum Africa/Kigali Africa/Kinshasa Africa/Lagos Africa/Libreville Africa/Lome Africa/Luanda Africa/Lubumbashi Africa/Lusaka Africa/Malabo Africa/Maputo Africa/Maseru Africa/Mbabane Africa/Mogadishu Africa/Monrovia Africa/Nairobi Africa/Ndjamena Africa/Niamey Africa/Nouakchott Africa/Ouagadougou Africa/Porto-Novo Africa/Sao_Tome Africa/Timbuktu Africa/Tripoli Africa/Tunis Africa/Windhoek ``` ------ #### [ America ] ``` America/Adak America/Anchorage America/Anguilla America/Antigua America/Aruba America/Asuncion America/Barbados America/Belize America/Bogota America/Buenos_Aires America/Caracas America/Cayenne America/Cayman America/Chicago America/Costa_Rica America/Cuiaba America/Curacao America/Dawson_Creek America/Denver America/Dominica America/Edmonton America/El_Salvador America/Fortaleza America/Godthab America/Grand_Turk America/Grenada America/Guadeloupe America/Guatemala America/Guayaquil America/Guyana America/Halifax America/Havana America/Indianapolis America/Jamaica America/La_Paz America/Lima America/Los_Angeles America/Managua America/Manaus America/Martinique America/Mazatlan America/Mexico_City America/Miquelon America/Montevideo America/Montreal America/Montserrat America/Nassau America/New_York America/Noronha America/Panama America/Paramaribo America/Phoenix America/Port_of_Spain America/Port-au-Prince America/Porto_Acre America/Puerto_Rico America/Regina America/Rio_Branco America/Santiago America/Santo_Domingo America/Sao_Paulo America/Scoresbysund America/St_Johns America/St_Kitts America/St_Lucia America/St_Thomas America/St_Vincent America/Tegucigalpa America/Thule America/Tijuana America/Tortola America/Vancouver America/Winnipeg ``` ------ #### [ Antarctica ] ``` Antarctica/Casey Antarctica/DumontDUrville Antarctica/Mawson Antarctica/McMurdo Antarctica/Palmer ``` ------ #### [ Asia ] ``` Asia/Aden Asia/Almaty Asia/Amman Asia/Anadyr Asia/Aqtau Asia/Aqtobe Asia/Ashgabat Asia/Ashkhabad Asia/Baghdad Asia/Bahrain Asia/Baku Asia/Bangkok Asia/Beirut Asia/Bishkek Asia/Brunei Asia/Calcutta Asia/Colombo Asia/Dacca Asia/Damascus Asia/Dhaka Asia/Dubai Asia/Dushanbe Asia/Hong_Kong Asia/Irkutsk Asia/Jakarta Asia/Jayapura Asia/Jerusalem Asia/Kabul Asia/Kamchatka Asia/Karachi Asia/Katmandu Asia/Krasnoyarsk Asia/Kuala_Lumpur Asia/Kuwait Asia/Macao Asia/Magadan Asia/Manila Asia/Muscat Asia/Nicosia Asia/Novosibirsk Asia/Phnom_Penh Asia/Pyongyang Asia/Qatar Asia/Rangoon Asia/Riyadh Asia/Saigon Asia/Seoul Asia/Shanghai Asia/Singapore Asia/Taipei Asia/Tashkent Asia/Tbilisi Asia/Tehran Asia/Thimbu Asia/Thimphu Asia/Tokyo Asia/Ujung_Pandang Asia/Ulaanbaatar Asia/Ulan_Bator Asia/Vientiane Asia/Vladivostok Asia/Yakutsk Asia/Yekaterinburg Asia/Yerevan ``` ------ #### [ Atlantic ] ``` Atlantic/Azores Atlantic/Bermuda Atlantic/Canary Atlantic/Cape_Verde Atlantic/Faeroe Atlantic/Jan_Mayen Atlantic/Reykjavik Atlantic/South_Georgia Atlantic/St_Helena Atlantic/Stanley ``` ------ #### [ Australia ] ``` Australia/Adelaide Australia/Brisbane Australia/Broken_Hill Australia/Darwin Australia/Hobart Australia/Lord_Howe Australia/Perth Australia/Sydney ``` ------ #### [ Europe ] ``` Europe/Amsterdam Europe/Andorra Europe/Athens Europe/Belgrade Europe/Berlin Europe/Brussels Europe/Bucharest Europe/Budapest Europe/Chisinau Europe/Copenhagen Europe/Dublin Europe/Gibraltar Europe/Helsinki Europe/Istanbul Europe/Kaliningrad Europe/Kiev Europe/Lisbon Europe/London Europe/Luxembourg Europe/Madrid Europe/Malta Europe/Minsk Europe/Monaco Europe/Moscow Europe/Oslo Europe/Paris Europe/Prague Europe/Riga Europe/Rome Europe/Samara Europe/Simferopol Europe/Sofia Europe/Stockholm Europe/Tallinn Europe/Tirane Europe/Vaduz Europe/Vienna Europe/Vilnius Europe/Warsaw Europe/Zurich ``` ------ #### [ Indian ] ``` Indian/Antananarivo Indian/Chagos Indian/Christmas Indian/Cocos Indian/Comoro Indian/Kerguelen Indian/Mahe Indian/Maldives Indian/Mauritius Indian/Mayotte Indian/Reunion ``` ------ #### [ Pacific ] ``` Pacific/Apia Pacific/Auckland Pacific/Chatham Pacific/Easter Pacific/Efate Pacific/Enderbury Pacific/Fakaofo Pacific/Fiji Pacific/Funafuti Pacific/Galapagos Pacific/Gambier Pacific/Guadalcanal Pacific/Guam Pacific/Honolulu Pacific/Kiritimati Pacific/Kosrae Pacific/Majuro Pacific/Marquesas Pacific/Nauru Pacific/Niue Pacific/Norfolk Pacific/Noumea Pacific/Pago_Pago Pacific/Palau Pacific/Pitcairn Pacific/Ponape Pacific/Port_Moresby Pacific/Rarotonga Pacific/Saipan Pacific/Tahiti Pacific/Tarawa Pacific/Tongatapu Pacific/Truk Pacific/Wake Pacific/Wallis ``` ------ Non è possibile modificare il campo del suffisso tranne.** Quando si abilita la conversione o la compressione del formato dei dati, Firehose aggiungerà un'estensione di file in base alla configurazione. La tabella seguente illustra l'estensione di file predefinita aggiunta da Firehose: | Configurazione | Estensione di file | | --- | --- | | Conversione del formato dei dati: Parquet | .parquet | | Conversione del formato dei dati: ORC | .orc | | Compressione: Gzip | .gz | | Compressione: Zip | .zip | | Compressione: Snappy | .snappy | | Compressione: Hadoop-Snappy | .hsnappy | È inoltre possibile specificare l'estensione di file che si preferisce nella console o nell'API Firehose. L'estensione del file deve iniziare con un punto (.) e può contenere caratteri consentiti: 0-9a-z\$1 -\$1.\$1' (). L'estensione del file non può superare i 128 caratteri. **Nota** Quando si specifica un'estensione di file, questa sostituirà l'estensione di file predefinita aggiunta da Firehose [quando è abilitata la conversione o la compressione del formato dei dati](https://docs.aws.amazon.com/firehose/latest/dev/record-format-conversion.html). # Comprendi i prefissi personalizzati per gli oggetti Amazon S3 Gli oggetti consegnati ad Amazon S3 seguono il [formato del nome](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-namekey) di. Puoi specificare il tuo prefisso personalizzato che include espressioni che vengono valutate in fase di esecuzione. Il prefisso personalizzato specificato sostituirà il prefisso predefinito di. `yyyy/MM/dd/HH` Puoi utilizzare le seguenti forme di espressione nel prefisso personalizzato: `!{namespace:value}`, dove `namespace` può essere uno dei seguenti, come descritto nelle sezioni successive. + `firehose` + `timestamp` + `partitionKeyFromQuery` + `partitionKeyFromLambda` Se un prefisso termina con una barra, viene visualizzato come cartella nel bucket Amazon S3. Per ulteriori informazioni, consulta [Amazon S3 Object Name Format](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-name) nella *Amazon Data FirehoseDeveloper* Guide. ## Spazio dei nomi `timestamp` [I valori validi per questo spazio dei nomi sono stringhe che sono stringhe Java valide. DateTimeFormatter](https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html) Ad esempio, nell'anno 2018, l'espressione `!{timestamp:yyyy}` restituisce `2018`. Durante la valutazione dei timestamp, Firehose utilizza il timestamp di arrivo approssimativo del record più vecchio contenuto nell'oggetto Amazon S3 in fase di scrittura. Per impostazione predefinita, il timestamp è in UTC. Tuttavia, puoi specificare il fuso orario che preferisci. Ad esempio, puoi configurare il fuso orario in Console di gestione AWS o Asia/Tokyo nell'impostazione del parametro API ([CustomTimeZone](https://docs.aws.amazon.com/firehose/latest/APIReference/API_ExtendedS3DestinationConfiguration.html)) se desideri utilizzare l'ora solare del Giappone anziché l'UTC. Per visualizzare l'elenco dei fusi orari supportati, consulta [Amazon S3 Object Name](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-name) Format. Se utilizzi lo spazio dei nomi `timestamp` più di una volta nella stessa espressione del prefisso, ogni istanza restituisce lo stesso istante temporale. ## Spazio dei nomi `firehose` Con questo spazio dei nomi puoi utilizzare due valori: `error-output-type` e `random-string`. La tabella seguente spiega come utilizzarli. **Valori dello spazio dei nomi `firehose`** | Conversione | Description | Input di esempio | Output di esempio | Note | | --- | --- | --- | --- | --- | | error-output-type | Restituisce una delle seguenti stringhe, a seconda della configurazione del flusso Firehose e del motivo dell'errore: \$1processing-failed, AmazonOpenSearchService -failed, splunk-failed,,\$1. format-conversion-failed http-endpoint-failedSe lo utilizzi più di una volta nella stessa espressione, ogni istanza restituisce la stessa stringa di errore. | myPrefix/result=\$1\$1firehose:error-output-type\$1/\$1\$1timestamp:yyyy/MM/dd\$1 | myPrefix/result=processing-failed/2018/08/03 | Il valore può essere utilizzato solo nel campo. error-output-type ErrorOutputPrefix | | random-string | Restituisce una stringa casuale di 11 caratteri. Se lo utilizzi più di una volta nella stessa espressione, ogni istanza restituisce una nuova stringa casuale. | myPrefix/\$1\$1firehose:random-string\$1/ | myPrefix/046b6c7f-0b/ | Puoi utilizzarlo con entrambi i tipi di prefisso.Puoi posizionarlo all'inizio della stringa di formato per ottenere un prefisso randomizzato, che talvolta è necessario per ottenere una velocità di trasmissione effettiva estremamente elevata con Amazon S3. | ## Spazi dei nomi `partitionKeyFromLambda` e `partitionKeyFromQuery` Per il [partizionamento dinamico](dynamic-partitioning.md), è necessario utilizzare il seguente formato di espressione nel prefisso del bucket S3: `!{namespace:value}`, dove lo spazio dei nomi può essere `partitionKeyFromQuery` o `partitionKeyFromLambda` o entrambi. Se si utilizza l'analisi in linea per creare le chiavi di partizionamento per i dati di origine, è necessario specificare un valore del prefisso del bucket S3 costituito da espressioni specificate nel seguente formato: `"partitionKeyFromQuery:keyID"`. Se si utilizza una funzione AWS Lambda per creare chiavi di partizionamento per i dati di origine, è necessario specificare un valore di prefisso del bucket S3 costituito da espressioni specificate nel seguente formato: `"partitionKeyFromLambda:keyID"`. Per ulteriori informazioni, consulta «Scegli Amazon S3 per la tua destinazione» in [Creazione di uno stream Amazon Firehose](basic-create.md#basic-create.title). ## Regole semantiche Le seguenti regole si applicano alle espressioni `Prefix` e `ErrorOutputPrefix`. + Per lo spazio dei nomi `timestamp`, vengono restituiti tutti i caratteri che non sono tra virgolette singole. In altre parole, tutte le stringhe precedute da virgolette singole nel campo dei valori vengono prese alla lettera. + Se si specifica un prefisso che non contiene un'espressione dello spazio dei nomi con timestamp, Firehose aggiunge l'espressione al valore nel `!{timestamp:yyyy/MM/dd/HH/}` campo. `Prefix` + La sequenza `!{` può comparire solo nelle espressioni `!{namespace:value}`. + `ErrorOutputPrefix` può essere null solo `Prefix` non contiene espressioni. In questo caso, `Prefix` valuta `yyyy/MM/DDD/HH/` e `ErrorOutputPrefix` valuta `yyyy/MM/DDD/HH/`. `DDD` rappresenta il giorno dell'anno. + Se specifichi un'espressione per `ErrorOutputPrefix`, devi includere almeno un'istanza di `!{firehose:error-output-type}`. + `Prefix` non può contenere `!{firehose:error-output-type}`. + Né `Prefix` né `ErrorOutputPrefix` possono contenere più di 512 dopo la restituzione. + Se la destinazione è Amazon Redshift, `Prefix` non deve contenere espressioni e `ErrorOutputPrefix` deve essere null. + Quando la destinazione è Amazon OpenSearch Service o Splunk e non `ErrorOutputPrefix` viene specificato alcun valore, Firehose utilizza `Prefix` il campo per i record non riusciti. + Quando la destinazione è Amazon S3, `Prefix` e `ErrorOutputPrefix` nella configurazione di destinazione di Amazon S3 vengono utilizzati rispettivamente per record riusciti e record non riusciti. Con l' AWS CLI o l'API, puoi utilizzare `ExtendedS3DestinationConfiguration` per specificare una configurazione di *backup* di Amazon S3 con `Prefix` e `ErrorOutputPrefix`. + Quando si utilizza Console di gestione AWS e si imposta la destinazione su Amazon S3, Firehose utilizza la `Prefix` e `ErrorOutputPrefix` nella configurazione di destinazione rispettivamente per i record riusciti e per i record con esito negativo. Se si specifica un prefisso utilizzando espressioni, è necessario specificare il prefisso di errore comprensivo di. `!{firehose:error-output-type}` + Quando si utilizza `ExtendedS3DestinationConfiguration` con AWS CLI, l'API o CloudFormation, se si specifica un`S3BackupConfiguration`, Firehose non fornisce un valore predefinito. `ErrorOutputPrefix` + Non è possibile utilizzare gli `partitionKeyFromQuery` spazi `partitionKeyFromLambda` dei nomi and durante la creazione di espressioni. ErrorOutputPrefix ## Esempi di prefisso **Esempi di `Prefix` e `ErrorOutputPrefix`** | Input | Prefisso restituito (alle 10:30 UTC in data 27 ago 2018) | | --- | --- | | `Prefix`: non specificato `ErrorOutputPrefix`: `myFirehoseFailures/!{firehose:error-output-type}/` | `Prefix`: `2018/08/27/10` `ErrorOutputPrefix`: `myFirehoseFailures/processing-failed/` | | `Prefix`: `!{timestamp:yyyy/MM/dd}` `ErrorOutputPrefix`: non specificato | Input non valido: ErrorOutputPrefix non può essere null se Prefix contiene espressioni | | `Prefix`: `myFirehose/DeliveredYear=!{timestamp:yyyy}/anyMonth/rand=!{firehose:random-string}` `ErrorOutputPrefix`: `myFirehoseFailures/!{firehose:error-output-type}/!{timestamp:yyyy}/anyMonth/!{timestamp:dd}` | `Prefix`: `myFirehose/DeliveredYear=2018/anyMonth/rand=5abf82daaa5` `ErrorOutputPrefix`: `myFirehoseFailures/processing-failed/2018/anyMonth/10` | | `Prefix`: `myPrefix/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/` `ErrorOutputPrefix`: `myErrorPrefix/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/!{firehose:error-output-type}` | `Prefix`: `myPrefix/year=2018/month=07/day=06/hour=23/` `ErrorOutputPrefix`: `myErrorPrefix/year=2018/month=07/day=06/hour=23/processing-failed` | | `Prefix`: `myFirehosePrefix/` `ErrorOutputPrefix`: non specificato | `Prefix`: `myFirehosePrefix/2018/08/27/` `ErrorOutputPrefix`: `myFirehosePrefix/processing-failed/2018/08/27/` | # Configura la rotazione dell'indice per Service OpenSearch Per la destinazione del OpenSearch servizio, è possibile specificare un'opzione di rotazione dell'indice basata sul tempo tra una delle cinque opzioni seguenti:**NoRotation**,,**OneHour**, **OneDay** o. **OneWeek** **OneMonth** A seconda dell'opzione di rotazione scelta, Amazon Data Firehose aggiunge una parte del timestamp UTC di arrivo al nome di indice specificato. Ruota il timestamp aggiunto di conseguenza. L'esempio seguente mostra il nome dell'indice risultante in OpenSearch Service per ogni opzione di rotazione dell'indice, dove si trova il nome dell'indice specificato **myindex** e il timestamp di arrivo è. `2016-02-25T13:00:00Z` | RotationPeriod | IndexName | | --- | --- | | NoRotation | myindex | | OneHour | myindex-2016-02-25-13 | | OneDay | myindex-2016-02-25 | | OneWeek | myindex-2016-w08 | | OneMonth | myindex-2016-02 | **Nota** Con l'opzione `OneWeek`, Data Firehose crea automaticamente gli indici utilizzando il formato -w (ad esempio, `2020-w33`), in cui il numero della settimana viene calcolato utilizzando il tempo UTC e secondo le seguenti convenzioni statunitensi: Una settimana inizia di domenica La prima settimana dell'anno è la prima settimana che contiene un sabato dell'anno in corso # Sospendere e riprendere la consegna dei dati Dopo aver configurato uno stream Firehose, i dati disponibili nella sorgente del flusso vengono continuamente consegnati alla destinazione. In situazioni in cui la destinazione del flusso è temporaneamente non disponibile (ad esempio, durante operazioni di manutenzione programmate), potresti voler sospendere temporaneamente la distribuzione dei dati e riprenderla quando la destinazione sarà nuovamente disponibile. **Importante** Quando utilizzi l'approccio descritto di seguito per mettere in pausa e riprendere uno stream, dopo averlo ripreso, vedrai che pochi record vengono consegnati al bucket di errori in Amazon S3 mentre il resto dello stream continua a essere recapitato alla destinazione. Questa è una limitazione nota dell'approccio e si verifica perché un numero limitato di record, che non era possibile consegnare in precedenza alla destinazione dopo più tentativi, vengono considerati falliti. ## Mettere in pausa uno stream Firehose Per sospendere la distribuzione dello stream in Firehose, rimuovete innanzitutto le autorizzazioni che consentono a Firehose di scrivere nella posizione di backup S3 per le consegne non riuscite. Ad esempio, se desideri mettere in pausa lo stream Firehose con OpenSearch una destinazione, puoi farlo aggiornando le autorizzazioni. Per ulteriori informazioni, vedere [Concedere a Firehose l'accesso a una destinazione di OpenSearch servizio pubblico](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-es). Rimuovi l'autorizzazione `"Effect": "Allow"` per l'azione `s3:PutObject` e aggiungi esplicitamente un'istruzione che applichi l'autorizzazione `Effect": "Deny"` all'azione `s3:PutObject` per il bucket S3 utilizzato per il backup delle distribuzioni non riuscite. Quindi, disattiva la destinazione dello stream (ad esempio, disattivando il OpenSearch dominio di destinazione) o rimuovi le autorizzazioni per Firehose di scrivere nella destinazione. Per aggiornare le autorizzazioni per altre destinazioni, consulta la sezione relativa alla tua destinazione in [Controlling Access with Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html). Dopo aver completato queste due azioni, Firehose interromperà la distribuzione degli stream e potrai monitorarla utilizzando le [CloudWatch metriche](https://docs.aws.amazon.com/firehose/latest/dev/cloudwatch-metrics.html) per Firehose. **Importante** Quando si sospende la distribuzione dello stream in Firehose, è necessario assicurarsi che l'origine dello stream (ad esempio, in Kinesis Data Streams o in Managed Service for Kafka) sia configurata per conservare i dati fino alla ripresa della distribuzione dello stream e alla consegna dei dati alla destinazione. Se la fonte è DirectPut, Firehose conserverà i dati per 24 ore. Se la distribuzione del flusso non riprende e i dati non vengono distribuiti prima della scadenza del periodo di conservazione dei dati, potrebbe verificarsi una perdita di dati. ## Riprendere uno stream Firehose Per riprendere la consegna, ripristina innanzitutto la modifica apportata in precedenza alla destinazione dello stream attivando la destinazione e assicurandoti che Firehose disponga delle autorizzazioni per consegnare lo stream alla destinazione. Successivamente, ripristina le modifiche apportate in precedenza alle autorizzazioni applicate al bucket S3 per il backup delle distribuzioni non riuscite. Vale a dire, applica l'autorizzazione `"Effect": "Allow"` per l'azione `s3:PutObject` e rimuovi l'autorizzazione `"Effect": "Deny"` sull'azione `s3:PutObject` per il bucket S3 utilizzato per il backup delle distribuzioni non riuscite. Infine, monitorate utilizzando le [CloudWatch metriche di Firehose per](https://docs.aws.amazon.com/firehose/latest/dev/cloudwatch-metrics.html) confermare che lo stream venga recapitato alla destinazione. Per visualizzare e risolvere gli errori, usa il monitoraggio di [Amazon CloudWatch Logs per](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html) Firehose.