Domande frequenti su Amazon Data Firehose

L'API Firehose è disponibile nei kit SDK di Amazon Web Services. Per un elenco di piattaforme e linguaggi di programmazione per i kit SDK di Amazon Web Services, consulta Strumenti per Amazon Web Services.

Kinesis Agent è un'applicazione Java preinstallata che offre un modo semplice per raccogliere e inviare dati in un flusso Firehose. È possibile installare l'agente su ambienti server basati su Linux quali server Web, server di log e server di database. L'agente monitora determinati file e invia in modo continuo dati nel flusso Firehose. Attualmente, Amazon Kinesis Agent supporta Amazon Linux, Red Hat Enterprise Linux e Microsoft Windows. Per ulteriori informazioni, consulta Scrivere con gli agenti.

Per scaricare e installare Kinesis Agent, utilizza i seguenti comandi e collegamenti:

• In Amazon Linux: sudo yum install –y aws-kinesis-agent
• In Red Hat Enterprise Linux: sudo yum install –y https://s3.amazonaws.com/streaming-data-agent/aws-kinesis-agent-latest.amzn1.noarch.rpm
• Da GitHub: awlabs/amazon-kinesis-agent
• Su Windows: https://docs.aws.amazon.com/kinesis-agent-windows/latest/userguide/getting-started.html#getting-started-installation

Per aggiungere dati a un flusso Firehose, è possibile utilizzare Kinesis Agent oppure le operazioni di Firehose PutRecord e PutRecordBatch. L'operazione PutRecord consente un solo record di dati per chiamata API, mentre l'operazione PutRecordBatch ne consente più di uno. Per ulteriori informazioni, vedi PutRecord e PutRecordBatch.

Al momento della creazione o dell'aggiornamento di un flusso Firehose tramite la Console AWS o le API Firehose, è possibile configurare un cluster/argomento Amazon MSK come origine del flusso Firehose. Una volta completata tale configurazione, Firehose leggerà automaticamente i dati provenienti dall'argomento MSK e caricherà i dati nel bucket o nei bucket S3 indicati.

È possibile ridurre la complessità operativa e il sovraccarico dell'applicazione trasformando e caricando i dati in streaming provenienti dagli argomenti Amazon MSK su Amazon S3 senza bisogno di codice. Ad esempio, con Amazon MSK e Firehose, è possibile lavorare senza codice e ottenere funzionalità integrate di conversione e trasformazione dei dati come la conversione del formato Parquet/ORC, il buffering dei dati e la convalida dei dati lato servizio. Inoltre, si ottengono nuovi tentativi di consegna automatici, conservazione dei dati, dimensionamento automatico e ridondanza, affinché i dati vengano consegnati in modo affidabile.

Per utilizzare questa funzionalità, è necessario che gli endpoint pubblici o i link privati dei cluster MSK siano abilitati.

Sì, Firehose può connettersi ai cluster Amazon MSK disponibili in diversi account AWS. Firehose è in grado di effettuare consegne anche a bucket S3 che appartengono a diversi account.

Il tempo limite per iniziare a consumare i dati dall'argomento Amazon MSK è il momento della creazione dello stream Firehose. Firehose non legge i valori di offset personalizzati.

Al momento della creazione o dell'aggiornamento di un flusso Firehose tramite la console AWS o le API Firehose, è possibile configurare il flusso Firehose come origine del flusso Firehose. Una volta configurato, Firehose leggerà automaticamente i dati provenienti dal flusso Firehose e li caricherà nella destinazione specificata.

Firehose richiama l'operazione GetRecords() di Kinesis Data Streams una volta al secondo per ogni partizione di Kinesis.

Firehose inizia a leggere i dati dalla posizione PIÙ RECENTE del flusso di dati Kinesis quando è configurato come sorgente di un flusso Firehose. Per ulteriori informazioni sulle posizioni del flusso di dati Kinesis, consulta la sezione GetShardIterator nella documentazione di riferimento delle API del servizio Kinesis Data Streams.

R: Sì, è possibile. Tuttavia, la chiamata GetRecords() da Firehose è inclusa nel calcolo della limitazione totale della larghezza di banda della rete della partizione di Kinesis. È dunque necessario pianificare il flusso Firehose insieme alle altre applicazioni Kinesis per accertarsi di non superare le restrizioni impostate. Per ulteriori informazioni, consulta la sezione Limiti di Kinesis Data Streams nella Guida per gli sviluppatori di Kinesis Data Streams.

No. Quando un flusso di dati Kinesis è configurato come origine di un flusso Firehose, le operazioni PutRecord e PutRecordBatch vengono disabilitate. Per aggiungere dati al flusso di dati Kinesis, sarà necessario utilizzare le operazioni PutRecord e PutRecords di Kinesis Data Streams.

Per aggiungere dati da AWS IoT a un flusso Firehose, è necessario creare un'operazione di AWS IoT che vi inoltri gli eventi. Per ulteriori informazioni, consulta la sezione Writing to Amazon Firehose Using AWS IoT nella guida agli sviluppatori di Firehose.

Al momento della creazione o dell'aggiornamento di un flusso Firehose tramite la console AWS o le API Firehose, è possibile configurare il PUT Diretto come origine del flusso Firehose. Dopo la creazione del flusso, è possibile configurare il flusso Firehose creato come flusso Firehose nella sezione Log venduti della console Log di flusso VPC.

Per aggiungere dati provenienti da CloudWatch Logs a un flusso Firehose è necessario creare un filtro di sottoscrizione CloudWatch Logs che vi inoltri gli eventi. Per ulteriori informazioni, consulta la sezione Utilizzo di filtri di sottoscrizione di CloudWatch Logs nella Guida per l'utente di Amazon CloudWatch.

Per aggiungere dati da CloudWatch Events a un flusso di distribuzione Firehose è necessario creare una regola CloudWatch Events impostando come destinazione il flusso Firehose. Per ulteriori informazioni, consulta la sezione Writing to Amazon Firehose Using CloudWatch Events nella guida agli sviluppatori di Firehose.

È possibile aggiungere dati al flusso Firehose dalla console AWS EventBridge. Per ulteriori informazioni, consulta la documentazione di AWS EventBridge.

Firehose consente di crittografare i dati dopo la consegna al bucket Amazon S3. Al momento della creazione del flusso Firehose, è possibile scegliere di crittografare i dati con una chiave AWS Key Management Service (KMS) già in uso. Per ulteriori informazioni su KMS, consulta il Servizio AWS di gestione delle chiavi.

Firehose presuppone che sia specificato un ruolo IAM per accedere a risorse quali bucket Amazon S3 e dominio Amazon OpenSearch. Per ulteriori informazioni, consulta la sezione Controllo degli accessi con Firehose nella guida per sviluppatori di Firehose.

Sì, Firehose utilizza AWS PrivateLink per connettersi ai database che si trovano all'interno di VPC.

Sì, quando configuri un flusso di distribuzione Firehose, puoi selezionare tabelle e colonne specifiche nel database di origine. Firehose fornisce aggiornamenti CDC solo per le tabelle e le colonne selezionate.

Sì, quando configuri Firehose per distribuire flussi CDC in tabelle Apache Iceberg su Amazon S3, puoi configurare il flusso per distribuire record da diverse tabelle di origine in diverse tabelle Apache Iceberg.

Firehose supporta la conversione del formato di dati integrati da dati grezzi o Json in formati come Apache Parquet e Apache ORC, richiesti dai datastore di destinazione senza la necessità di creare una pipeline di elaborazione apposita. Inoltre, Firehose permette di suddividere in maniera dinamica i dati in streaming prima della consegna ad S3 tramite chiavi definite in modo statico o dinamico, quali "customer_id" o "transaction_id". Firehose raggruppa i dati sulla base di tali chiavi e li consegna tramite prefissi S3 unici, consentendo di effettuare analisi dei dati migliori ed economicamente vantaggiose in maniera semplice su S3 con Athena, EMR e Redshift Spectrum.

Oltre all'opzione di conversione del formato integrata su Amazon Data Firehose, è possibile utilizzare una funzione AWS Lambda per preparare e trasformare i dati grezzi in ingresso nel flusso Firehose prima del caricamento a destinazione. È possibile configurare una funzione AWS Lambda per operare la trasformazione dei dati al momento della creazione di un nuovo flusso Firehose, oppure quando ne viene modificato uno esistente. Amazon ha creato numerose planimetrie Lambda tra cui scegliere per iniziare rapidamente. Per un elenco completo, consulta la guida per gli sviluppatori di Amazon Data Firehose.

Amazon Data Firehose consente di comprimere i dati prima di inoltrarli in Amazon S3. Al momento, il servizio supporta i formati di compressione GZIP, ZIP e SNAPPY. Se i dati vengono successivamente caricati in Amazon Redshift, è supportato solo il format GZIP.

La funzionalità di abbonamento a CloudWatch Logs permette di inoltrare dati in streaming da CloudWatch Logs su Firehose. Tutti i log eventi provenienti da CloudWatch Logs sono già compressi in formato gzip, perciò è necessario disabilitare la funzione di compressione di Firehose per evitare che venga applicata due volte. Per ulteriori informazioni sulla funzionalità di abbonamento di CloudWatch Logs, consulta la sezione Subscription Filters with Amazon Data Firehose nella guida per l'utente di Amazon CloudWatch Logs.

Tutti i record trasformati da Lambda devono essere reindirizzati in Firehose con i tre parametri elencati di seguito; in caso contrario, Firehose rifiuterà i record e li elaborerà come errori.

• recordId: durante la chiamata, Firehose inoltra a Lambda un recordId con ciascun record. Ogni record sottoposto a trasformazione deve tornare con lo stesso recordId. Eventuali corrispondenze errate tra il recordId originale e il recordId restituito saranno elaborate come errori di trasformazione.
   
• result: lo stato della trasformazione di ciascun record. I valori consentiti per questo parametro sono i seguenti: "Ok" se il record è stato sottoposto correttamente a trasformazione. "Dropped" se la logica di elaborazione prevede che il record non venga elaborato. "ProcessingFailed" se il record non può essere sottoposto correttamente a trasformazione. Quando genera i parametri SucceedProcessing.Records e SucceedProcessing.Bytes, Firehose elencherà i record con valori "Ok" e "Dropped" tra quelli elaborati correttamente, mentre i record con stato "ProcessingFailed" saranno elencati tra gli errori.
   
• data: il payload di dati trasformati post-codifica con Base64.

Se la trasformazione dei dati con Lambda è stata attivata, Firehose può registrare i log di tutte le chiamate Lambda e di tutti gli errori di inoltro dei dati in Amazon CloudWatch Logs, per esaminare gli eventuali errori verificatisi durante una chiamata Lambda o la distribuzione dei dati. Per ulteriori informazioni, consulta Monitoraggio tramite log Amazon CloudWatch.

Utilizzando la trasformazione dei dati di Lambda, è anche possibile configurare il backup dei record di origine; Amazon Data Firehose distribuirà i dati in ingresso non trasformati in un bucket S3 separato. Sarà possibile specificare un prefisso secondario che si aggiungerà al prefisso "AAAA/MM/GG/HH" generato da Firehose, che indica la data e l'ora nel fuso orario UTC.

La partizione dinamica di Firehose elimina le complessità e i ritardi tipici della partizione manuale all'origine o dopo l'archiviazione dei dati e consente un'analisi dei dati più veloce per le query di set di dati ottimizzati. Da un lato, questo fa sì che i set di dati siano immediatamente disponibili affinché gli strumenti di analisi dei dati possano eseguire le loro query in maniera efficiente; dall'altro, migliora il controllo granulare degli accessi ai dati. Ad esempio, i clienti dell'automazione del marketing possono suddividere i dati al volo sulla base dell'id del cliente, consentendo alle query specifiche per il cliente di effettuare query su set di dati ottimizzati e di ottenere risultati più velocemente. I clienti delle operazioni IT o del monitoraggio della sicurezza possono creare gruppi sulla base di timestamp di eventi integrati nei log, in modo da effettuare query su set di dati ottimizzati e ottenere risultati più velocemente. Questa funzionalità, insieme a quella esistente di conversione dal formato JSON al formato Parquet di Amazon Data Firehose, rende Amazon Data Firehose uno strumento di streaming ETL ideale per S3.

È possibile impostare la capacità di partizione dei dati di Firehose tramite la console di gestione, le CLI o gli SDK di AWS. Al momento della creazione o dell'aggiornamento di un flusso Firehose, seleziona Amazon S3 come destinazione di consegna per il flusso Firehose e abilita la partizione dinamica. È possibile specificare chiavi o creare un'espressione da valuta al runtime per definire le chiavi utilizzate per la partizione. Ad esempio, è possibile selezionale un campo dati nel flusso in entrata come id cliente e definite un'espressione di prefisso S3 come customer_id=!{partitionKey:customer_id}/, che sarà valutata al tempo di esecuzione sulla base dei record importati per stabilire quale prefisso S3 distribuisce i record.

Firehose supporta la conversione parquet/orc preconfigurata al momento della scrittura dei dati su Amazon S3, integra la funzione Lambda, consentendo di scrivere un codice di trasformazione personale, dispone anche di un supporto integrato per l'estrazione di campi dai dei dati chiave dai record in formato JSON e supporta il linguaggio di analisi JQ per consentire la trasformazione sulla chiavi di partizione. Per ulteriori informazioni, consulta la guida per gli sviluppatori di Firehose.

Sì, Firehose esegue il backup di tutti i record non sottoposti a trasformazione nel bucket S3 nello stesso momento in cui inoltra i record trasformati a destinazione. È possibile abilitare il backup dei record di origine al momento della creazione o dell'aggiornamento di un flusso Firehose.

La frequenza di distribuzione dei dati su Amazon S3 è determinata dalle dimensioni del buffer di S3 e dall'intervallo di buffer configurati per il flusso Firehose. Firehose memorizza nel buffer i dati in entrata prima di inoltrarli in Amazon S3. È possibile configurare le dimensioni (da 1 a 128 MB) o gli intervalli (da 0 a 900 secondi) del buffer di S3; la condizione che si verifica per prima attiverà l'inoltro dei dati ad Amazon S3. Se hai attivato Apache parquet o una partizione dinamica, la dimensione del buffer è espressa in MB e varia tra 64 e 128 MB per le destinazioni Amazon S3; 128 MB è il valore predefinito. In situazioni in cui l'inoltro dei dati alla destinazione è più lento rispetto all'importazione dei dati nel flusso Firehose, Firehose aumenta automaticamente le dimensioni del buffer per assicurarsi che tutti i dati raggiungano la destinazione.

Le dimensioni del buffer si applicano prima della compressione. Di conseguenza, se decidi di comprimere i dati, le dimensioni degli oggetti nel bucket Amazon S3 saranno minori delle dimensioni del buffer specificate.

L'utente Redshift deve disporre del privilegio Redshift INSERT per poter copiare i dati dal bucket Amazon S3 nell'istanza Redshift.

Se l'istanza Redshift si trova all'interno di un VPC, è necessario consentire l'accesso di Amazon Data Firehose all'istanza Redshift sbloccando gli indirizzi IP di Firehose nel VPC. Per ulteriori informazioni su come sbloccare gli IP per un VPC, consulta la sezione Concedi ad Amazon Data Firehose l'accesso a una destinazione Amazon Redshift nella guida per gli sviluppatori di Amazon Data Firehose.

Per le destinazioni Redshift, Amazon Data Firehose distribuisce i dati prima nel bucket Amazon S3, poi esegue un comando Redshift COPY per caricare i dati dal bucket S3 all'istanza Redshift.

Attualmente, un singolo flusso Firehose può fornire dati solo a una tabella Snowflake. Per fornire dati a più tabelle Snowflake, è necessario creare più stream Firehose.

Firehose utilizza la semantica di elaborazione singola per Snowflake. Ciò significa che ogni record viene inviato a Snowflake esattamente una volta, anche in caso di errori o tentativi. Tuttavia, una consegna effettuata una volta sola non garantisce l'assenza di duplicati nei dati dall'inizio alla fine, in quanto i dati possono essere duplicati dal produttore o da altre parti della pipeline ETL.

Prevediamo che la maggior parte dei flussi di dati venga consegnata entro 5 secondi.

Il servizio OpenSearch di Amazon semplifica l'esecuzione di analisi interattive dei dati dei log, il monitoraggio delle applicazioni in tempo reale, la ricerca Web e altro ancora. OpenSearch è una suite di ricerca e analisi dei dati distribuita open source derivata da Elasticsearch. Il servizio OpenSearch di Amazon offre le versioni più recenti di OpenSearch, supporto per 19 versioni di Elasticsearch (versioni da 1.5 a 7.10) e funzionalità di visualizzazione basate su pannelli di controllo OpenSearch e Kibana (versioni da 1.5 a 7.10). Per ulteriori informazioni sul servizio OpenSearch di Amazon, fai clic qui.

Firehose può gestire la rotazione degli indici del servizio OpenSearch di Amazon secondo intervalli di tempo predeterminati. È possibile configurare questi intervalli durante la creazione del flusso Firehose. Per ulteriori informazioni, consulta la sezione Rotazione dell'indice per la destinazione del servizio OpenSearch di Amazon nella guida per gli sviluppatori di Amazon Data Firehose.

Quando i dati vengono caricati nel servizio OpenSearch di Amazon, Firehose può eseguire il backup di tutti i dati o solo dei dati che non è stato possibile distribuire. Per sfruttare al meglio questa funzione ed evitare le perdite di dati, è necessario fornire un bucket Amazon S3 di backup.

È possibile modificare le configurazioni dei flussi Firehose in qualsiasi momento. Per farlo, basta utilizzare la console di Firehose oppure l'operazione UpdateDestination. Il flusso Firehose manterrà lo stato ACTIVE anche durante l'aggiornamento delle configurazioni, perciò sarà possibile continuare a inviarvi dati. La configurazione aggiornata entra in vigore generalmente entro pochi minuti.

Quando si esegue la distribuzione a una destinazione VPC, è possibile modificare l'URL dell'endpoint di destinazione, purché la nuova destinazione sia accessibile all'interno dello stesso VPC, delle stesse sottoreti e degli stessi gruppi di sicurezza, per le cui modifiche è necessario ricreare il flusso Firehose.

La distribuzione di Firehose può essere effettuata su un altro account nel servizio OpenSearch di Amazon solo quando quest'ultimo e Firehose sono connessi tramite un endpoint pubblico.

Se invece sono connessi tramite un VPC privato, è necessario che il VPC del dominio di destinazione del servizio OpenSearch di Amazon e del flusso Firehose si trovino nel medesimo account.

No, è necessario che il flusso Firehose e il dominio di destinazione del servizio OpenSearch di Amazon si trovino nella medesima regione.

La frequenza di distribuzione dei dati nel servizio OpenSearch di Amazon è determinata dai valori dalle dimensioni e dell'intervallo del buffer di OpenSearch configurati per il flusso Firehose. Firehose memorizza nella cache i dati in entrata prima di distribuirli al servizio OpenSearch di Amazon. È possibile configurare le dimensioni (da 1 a 100 MB) o gli intervalli (da 0 a 900 secondi) del buffer di OpenSearch; la condizione che si verifica per prima attiverà l'inoltro dei dati al servizio OpenSearch di Amazon. In situazioni in cui l'inoltro dei dati alla destinazione è più lento rispetto all'importazione dei dati nel flusso Firehose, Amazon Data Firehose aumenta automaticamente le dimensioni del buffer per assicurarsi che tutti i dati raggiungano la destinazione.

Per le destinazioni Redshift, Amazon Data Firehose genera file manifesto per il caricamento in batch di oggetti Amazon S3 su istanze Redshift. Nella cartella manifest vengono salvati i file manifest generati da Firehose.

Utilizzando la modalità "All documents", Amazon Data Firehose concatenerà diversi record in entrata in base alla configurazione del buffer del flusso Firehose e li distribuirà nel bucket S3 come oggetto S3. Indipendentemente dalla modalità di backup configurata, i documenti il cui caricamento non è riuscito verranno distribuiti nel bucket S3 utilizzando un formato JSON che fornisce informazioni aggiuntive quali codice di errore e data e ora del tentativo non riuscito. Per ulteriori informazioni, consulta la sezione Backup di Amazon S3 per la destinazione del servizio OpenSearch di Amazon nella guida per gli sviluppatori di Amazon Data Firehose.

Al momento, un singolo flusso Firehose può distribuire dati in un solo bucket Amazon S3. Per distribuire dati in più bucket S3, è necessario creare più flussi Firehose.

Attualmente, un singolo flusso Firehose può distribuire dati solo a un'istanza e a una tabella Redshift. Per distribuire dati in più istanze o tabelle Redshift, è necessario creare più flussi Firehose.

Attualmente, un singolo flusso Firehose può distribuire dati contemporaneamente in un solo dominio e in un solo indice del servizio OpenSearch di Amazon. Per distribuire dati in più domini o indici del servizio OpenSearch di Amazon, è possibile creare più flussi Firehose.

Abilitando Firehose per la distribuzione dei dati a una destinazione del servizio OpenSearch di Amazon in un VPC, Amazon Data Firehose crea una o più interfacce di rete elastiche (ENI) per più account nel VPC per ciascuna sottorete a scelta. Amazon Data Firehose utilizza queste ENI per distribuire i dati nel VPC. Il numero di ENI si dimensiona automaticamente per soddisfare i requisiti del servizio.

Sì, un flusso Firehose può fornire dati a più tabelle Apache Iceberg.

Sì, Firehose supporta la connessione al Catalogo dati AWS Glue in un account diverso o in una regione AWS diversa.

Sì, è possibile utilizzare la trasformazione dei dati con Lambda per la distribuzione alle tabelle Apache Iceberg. 

Di default, ogni flusso Firehose può ricevere fino a 2.000 transazioni al secondo, 5.000 record al secondo e 5 MB al secondo. È possibile aumentare questi limiti compilando l'apposita richiesta di aumento dei limiti dei servizi.

Per l'invio di dati, Amazon Data Firehose utilizza semantica at-least-once. In alcuni rari casi, ad esempio quando si verifica un timeout della richiesta inseguito ad un tentativo di invio di dati, il nuovo tentativo operato da Firehose potrebbe causare un duplicato, se la richiesta precedente va a buon fine.

Se l'origine dati è PUT Diretto e la loro distribuzione nel bucket Amazon S3 non va a buon fine, Amazon Data Firehose riprova a distribuirli ogni 5 secondi per un massimo di 24 ore, oltre le quali, se il problema persiste, li eliminerà.

Se l'origine dati è Kinesis Data Streams e la loro distribuzione nel bucket Amazon S3 non va a buon fine, Amazon Data Firehose riprova a distribuirli ogni 5 secondi per un periodo massimo equivalente a quello configurato su Kinesis Data Streams.

Se la distribuzione dei dati nell'istanza Redshift non va a buon fine, Amazon Data Firehose riprova a distribuirli ogni 5 minuti per un massimo di 120 minuti, trascorsi i quali salta l'attuale batch di oggetti S3 pronti per il comando COPY e passa a quello successivo. Le informazioni relative agli oggetti non elaborati vengono inviate al bucket S3 sotto forma di file manifesto nella cartella errors, che è possibile utilizzare per recuperare le informazioni manualmente. Per ulteriori informazioni su come eseguire il comando COPY sui dati con un file manifesto, consulta Utilizzo di un manifesto per specificare i file di dati.

Per le destinazioni nel servizio OpenSearch di Amazon, al momento della creazione del flusso Firehose è possibile specificare una durata di tentativi compresa tra 0 e 7200 secondi. Se la distribuzione dei dati verso il dominio del servizio OpenSearch di Amazon non va a buon fine, Amazon Data Firehose riprova a distribuirli per il tempo specificato, trascorso il quale salta l'attuale batch di dati e passa a quello successivo. I dettagli relativi ai documenti non inoltrati vengono memorizzati nella cartella opensearch_failed del bucket S3 e possono essere utilizzati per recuperare le informazioni manualmente.

In caso di errore durante la chiamata di una funzione Lambda per la trasformazione dei dati da parte di Firehose, possono verificarsi due scenari:

• Nel primo scenario, la chiamata alla funzione non viene completata, ad esempio, perché viene raggiunto il timeout di rete e si applicano limitazioni di chiamata Lambda. In questi casi, Firehose prova di default ad eseguire la chiamata per tre volte, quindi salta il batch di record in questione. I record non elaborati vengono elencati tra i record con errori di elaborazione. È possibile configurare un numero di nuovi tentativi compreso tra 0 e 300 tramite le API CreateDeliveryStream e UpdateDeliveryStream. Per questo tipo di errori, è anche possibile utilizzare la funzionalità di Firehose per la registrazione degli errori ed emettere errori di invocazione su CloudWatch Logs. Per ulteriori informazioni, consulta Monitoraggio tramite log Amazon CloudWatch.
   
• Nel secondo scenario, l'errore si verifica quando il parametro result della trasformazione del record restituito dalla funzione Lambda è "ProcessingFailed". Firehose elenca questi record tra quelli non elaborati correttamente. Per questo tipo di errori, è anche possibile utilizzare la funzionalità di Lambda per la registrazione degli errori ed emettere log di errore su CloudWatch Logs. Per ulteriori informazioni, consulta Accesso ad Amazon CloudWatch Logs per AWS Lambda.

In entrambi gli scenari di errore, i record non elaborati correttamente vengono inoltrati al bucket S3 nella cartella processing_failed.

Il più delle volte, le dimensioni degli oggetti S3 consegnati riflettono la dimensione di buffer specificata, purché la condizione della dimensione di buffer venga soddisfatta prima della condizione dell'intervallo di buffer. Tuttavia, quando la consegna dei dati alla destinazione è più lenta rispetto alla scrittura dei dati sul flusso Firehose, Firehose aumenta in modo dinamico le dimensioni del buffer per assicurarsi che tutti i dati vengano distribuiti alla destinazione. In queste circostanze, le dimensioni degli oggetti S3 consegnati potrebbero essere maggiori rispetto alle dimensioni del buffer specificate.

La cartella errors memorizza i file manifesto che contengono le informazioni su tutti gli oggetti S3 che non è stato possibile caricare nell’istanza Redshift. È possibile caricare questi oggetti manualmente tramite il comando Redshift COPY. Per ulteriori informazioni su come eseguire il comando COPY sui dati con un file manifesto, consulta Utilizzo di un manifesto per specificare i file di dati.

La cartella opensearch_failed archivia i documenti il cui caricamento non è riuscito sul tuo Amazon OpenSearch. Cosa succede se la distribuzione dei dati nel mio dominio Amazon OpenSearch fallisce? È possibile reindicizzare questi documenti manualmente per recuperarne le informazioni.

La cartella processing_failed memorizza i record non sottoposti a trasformazione da parte della funzione AWS Lambda a causa di errori. È possibile effettuare nuovi tentativi di elaborazione manualmente.

La console di Firehose mostra i principali parametri operativi e prestazionali, come il volume di dati in entrata e il volume di dati distribuiti. Inoltre, Amazon Data Firehose integra i parametri di Amazon CloudWatch per raccogliere, visualizzare e analizzare i parametri dei flussi Firehose. Per ulteriori informazioni sui parametri di Amazon Data Firehose, consulta la sezione Monitoraggio con metriche Amazon CloudWatch nella guida per gli sviluppatori di Amazon Data Firehose.

Amazon Data Firehose si integra con Amazon CloudWatch Logs, consentendo di aprire log di errore specifici in caso di mancata trasformazione o mancata distribuzione dei dati. È possibile abilitare la registrazione degli errori al momento della creazione del flusso Firehose. Per ulteriori informazioni, consulta la sezione Monitoraggio con Amazon CloudWatch Logs nella guida per gli sviluppatori di Amazon Data Firehose.

Amazon Data Firehose si integra con AWS Identity and Access Management, un servizio che consente di controllare gli accessi degli utenti alle risorse e ai servizi AWS. Ad esempio, è possibile creare una policy che consente solo a un utente o a un gruppo di utenti specifico di immettere dati in un flusso Firehose. Per ulteriori informazioni su gestione e controllo degli accessi dei flussi, consulta Controllo degli accessi tramite Amazon Data Firehose.

Amazon Data Firehose si integra con AWS CloudTrail, un servizio che registra le chiamate API di AWS sull'account e ne distribuisce i file di log. Per ottenere ulteriori informazioni sulla registrazione delle chiamate API e un elenco delle operazioni API di Amazon Data Firehose, consulta Registrazione delle chiamate API Amazon Data Firehose tramite AWS CloudTrail.

No. Attualmente, Firehose non è disponibile nel Piano gratuito di AWS. Il piano gratuito di AWS è un programma che offre prove gratuite per una serie di servizi AWS. Per ulteriori informazioni, consulta la pagina Web relativa al Piano gratuito AWS.

I prezzi di Firehose sono calcolati in base al consumo effettivo. Non sono previsti pagamenti anticipati né tariffe minime: si pagano solo le risorse utilizzate. I prezzi di Amazon Data Firehose si basano sul volume di dati (in GB) importati da Firehose, arrotondando per eccesso le dimensioni di ciascun registro ai 5 KB più vicini per PUT Diretto e Kinesis Data Streams utilizzati come origine. Per Log venduti come origine, i prezzi si basano sul volume di dati (in GB) importati da Firehose. Per ulteriori informazioni sui costi di Amazon Data Firehose, consulta i Prezzi di Amazon Data Firehose.

L'arrotondamento a incrementi di 5 KB viene calcolato a livello di record, non a livello di operazione API. Ad esempio, se la chiamata PutRecordBatch contiene due record da 1 KB, il volume di dati calcolato per quella chiamata sarà di 10 KB (5 KB per record).

No, i costi associati all'utilizzo di Amazon S3, di Amazon Redshift, del servizio OpenSearch di Amazon e di AWS Lambda, inclusi i costi per l'archiviazione e le richieste, saranno fatturati separatamente. Per ulteriori informazioni, consulta le pagine relative ai prezzi di Amazon S3, Amazon Redshift, Servizio OpenSearch di Amazon e AWS Lambda.

Lo SLA di Amazon Data Firehose garantisce una percentuale di tempo di attività mensile di almeno il 99,9% per Amazon Data Firehose.

Hai diritto a un credito di assistenza SLA per Amazon Data Firehose, secondo lo SLA di Amazon Data Firehose, se più di una zona di disponibilità in cui stai eseguendo un'attività, all'interno della stessa regione, ha una percentuale di tempo di attività mensile inferiore al 99,9% durante un qualsiasi ciclo di fatturazione mensile.

Per dettagli completi su termini e condizioni del contratto dello SLA e per indicazioni sulla presentazione di una richiesta, consulta la pagina dei dettagli relativa allo SLA di Amazon Data Firehose.