Problemi comuni - Amazon Data Firehose
Stream Firehose non disponibileNessun dato a destinazioneLa metrica di freschezza dei dati aumenta o non viene emessaLa conversione del formato di registrazione in Apache Parquet non riesceCampi mancanti per l'oggetto trasformato per Lambda

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à.

Problemi comuni

Di seguito sono riportati alcuni suggerimenti per la risoluzione dei problemi più comuni durante l'utilizzo di uno stream Firehose.

Stream Firehose non disponibile

Lo stream Firehose non è disponibile come destinazione per CloudWatch Logs, CloudWatch Events o AWS IoT poiché alcuni AWS servizi possono inviare messaggi ed eventi solo a un flusso Firehose che si trova nello stesso. Regione AWS Verifica che lo stream di Firehose si trovi nella stessa regione degli altri servizi.

Nessun dato a destinazione

Se non ci sono problemi di inserimento dei dati e le metriche emesse per lo stream Firehose sembrano buone, ma non vedi i dati nella destinazione, controlla la logica del lettore. Assicurati che il lettore stia analizzando correttamente tutti i dati.

La metrica di freschezza dei dati aumenta o non viene emessa

La freschezza dei dati è una misura dell'attualità dei dati all'interno del flusso Firehose. È l'epoca del record di dati più vecchio del flusso Firehose, misurato dal momento in cui Firehose ha ingerito i dati fino ai giorni nostri. Firehose fornisce metriche che è possibile utilizzare per monitorare l'aggiornamento dei dati. Per identificare il parametro di aggiornamento dei dati per una determinata destinazione, consulta Monitora Amazon Data Firehose con parametri CloudWatch .

Se abiliti il backup per tutti gli eventi o tutti i documenti, monitora due parametri distinti dell'aggiornamento dei dati: uno per la destinazione principale e uno per il backup.

Se la metrica di aggiornamento dei dati non viene emessa, significa che non esiste una distribuzione attiva per il flusso Firehose. Ciò accade quando la distribuzione dei dati è completamente bloccata o quando non ci sono dati in entrata.

Se il parametro di aggiornamento dei dati è in costante aumento significa che la distribuzione dei dati è in ritardo. Questo può accadere per uno dei seguenti motivi.

  • La destinazione non può gestire il tasso di distribuzione. Se Firehose riscontra errori transitori dovuti all'elevato traffico, la consegna potrebbe subire ritardi. Questo può accadere per destinazioni diverse da Amazon S3 (può succedere per OpenSearch Service, Amazon Redshift o Splunk). Assicurati che la destinazione abbia una capacità sufficiente per gestire il traffico in entrata.

  • La destinazione è lenta. La consegna dei dati potrebbe subire ritardi se Firehose riscontra una latenza elevata. Monitora il parametro di latenza della destinazione.

  • La funzione Lambda è lenta. Ciò potrebbe portare a una velocità di consegna dei dati inferiore alla velocità di ingestione dei dati per il flusso Firehose. Se possibile, migliora l'efficienza della funzione Lambda. Ad esempio, se la funzione esegue l'IO di rete, utilizza più thread o l'IO asincrono per aumentare il parallelismo. Inoltre, valuta l'opportunità di aumentare la dimensione della memoria della funzione Lambda in modo che l'allocazione della CPU possa incrementare di conseguenza. Questo potrebbe portare a invocazioni Lambda più veloci. Per informazioni sulla configurazione delle funzioni Lambda, consulta Configurazione AWS delle funzioni Lambda.

  • Si sono verificati errori durante la distribuzione dei dati. Per informazioni su come monitorare gli errori utilizzando Amazon CloudWatch Logs, consultaMonitora Amazon Data Firehose utilizzando i log CloudWatch .

  • Se l'origine dati del flusso Firehose è un flusso di dati Kinesis, è possibile che si verifichi una limitazione. Controlla i parametri ThrottledGetRecords, ThrottledGetShardIterator e ThrottledDescribeStream. Se al flusso di dati Kinesis sono associati più utenti, considera quanto segue:

    • Se i parametri ThrottledGetRecords e ThrottledGetShardIterator sono elevati, è consigliabile aumentare il numero di partizioni allestite per il flusso di dati.

    • Se il valore ThrottledDescribeStream è elevato, ti consigliamo di aggiungere l'kinesis:listshardsautorizzazione al ruolo configurato in. KinesisStreamSourceConfiguration

  • Hint di buffering insufficienti per la destinazione. Ciò potrebbe aumentare il numero di viaggi di andata e ritorno che Firehose deve effettuare verso la destinazione, il che potrebbe causare ritardi nella consegna. Valuta l'opportunità di aumentare il valore degli hint di buffering. Per ulteriori informazioni, consulta BufferingHints.

  • Una durata elevata per i tentativi potrebbe causare un ritardo nella destinazione quando gli errori sono frequenti. Valuta l'opportunità di ridurre la durata dei tentativi. Inoltre, monitora gli errori e cerca di ridurli. Per informazioni su come monitorare gli errori utilizzando Amazon CloudWatch Logs, consultaMonitora Amazon Data Firehose utilizzando i log CloudWatch .

  • Se la destinazione è Splunk e DeliveryToSplunk.DataFreshness è alto ma DeliveryToSplunk.Success sembra buono, il cluster Splunk potrebbe essere occupato. Libera il cluster Splunk, se possibile. In alternativa, contatta AWS Support e richiedi un aumento del numero di canali utilizzati da Firehose per comunicare con il cluster Splunk.

La conversione del formato di registrazione in Apache Parquet non riesce

Ciò accade se si prendono dati DynamoDB che includono Set il tipo, li si trasmette tramite Lambda a un flusso Firehose e si utilizza AWS Glue Data Catalog an per convertire il formato di record in Apache Parquet.

Quando il AWS Glue crawler indicizza i tipi di dati del set DynamoDB StringSet (NumberSet,, BinarySet and), li archivia nel catalogo dati rispettivamente come, e. SET<STRING> SET<BIGINT> SET<BINARY> Tuttavia, per convertire i record di dati nel formato Apache Parquet, Firehose richiede i tipi di dati Apache Hive. Poiché i tipi di set non sono tipi di dati Apache Hive validi, la conversione ha esito negativo. Per ottenere la conversione in modo che funzioni, aggiorna il catalogo dati con i tipi di dati Apache Hive. È possibile svolgere questa operazione modificando set in array nel catalogo dati.

Per modificare uno o più tipi di dati da set a array in un catalogo di dati AWS Glue

  1. Accedi a Console di gestione AWS e apri la AWS Glue console all'indirizzo https://console.aws.amazon.com/glue/.

  2. Nel riquadro a sinistra, sotto l'intestazione Data catalog (Catalogo dati), scegliere Tables (Tabelle).

  3. Nell'elenco delle tabelle, scegliere il nome della tabella in cui è necessario modificare uno o più tipi di dati. In questo modo si accede alla pagina dei dettagli per il backup.

  4. Scegli il pulsante Modifica schema nell'angolo in alto a destra della pagina dei dettagli.

  5. Nella colonna Data type (Tipo di dati) scegliere il primo tipo di dati set.

  6. Nell'elenco a discesa Column type (Tipo di colonna), modificare il tipo da set a array.

  7. Nel ArraySchemacampo, inserisci o array<string> array<int>array<binary>, a seconda del tipo di dati appropriato per lo scenario.

  8. Scegliere Aggiorna.

  9. Ripetere i passaggi precedenti per convertire altri tipi set in tipi array.

  10. Scegli Save (Salva).

Campi mancanti per l'oggetto trasformato per Lambda

Quando si utilizza la trasformazione dei dati Lambda per modificare i dati JSON in un oggetto Parquet, alcuni campi potrebbero mancare dopo la trasformazione. Ciò accade se l'oggetto JSON contiene lettere maiuscole e la distinzione tra maiuscole e minuscole è impostata sufalse, il che può portare a una mancata corrispondenza delle chiavi JSON dopo la trasformazione dei dati, causando la mancanza di dati nell'oggetto Parquet risultante nel bucket s3.

Per risolvere questo problema, assicuratevi che la configurazione del tubo sia deserializationOption: case.insensitive impostata su in true modo che le chiavi JSON corrispondano dopo la trasformazione.