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à.
# Risolvi gli errori in Amazon Data Firehose
Se Firehose riscontra errori durante la consegna o l'elaborazione dei dati, riprova fino alla scadenza della durata del nuovo tentativo configurata. Se la durata del nuovo tentativo termina prima che i dati vengano consegnati correttamente, Firehose esegue il backup dei dati nel bucket di backup S3 configurato. Se la destinazione è Amazon S3 e la consegna non riesce o se la consegna al bucket S3 di backup fallisce, Firehose continua a riprovare fino al termine del periodo di conservazione.
Per informazioni sul tracciamento degli errori di consegna utilizzando, consulta. CloudWatch [Monitora Amazon Data Firehose utilizzando i log CloudWatch](monitoring-with-cloudwatch-logs.md)
------
#### [ Direct PUT ]
Per gli stream `DirectPut` Firehose, Firehose conserva i record per 24 ore. Per uno stream Firehose la cui origine dati è un flusso di dati Kinesis, è possibile modificare il periodo di conservazione come descritto in [Modifica del periodo di conservazione dei](https://docs.aws.amazon.com/streams/latest/dev/kinesis-extended-retention.html) dati. In questo caso, Firehose riprova le seguenti operazioni all'infinito:`DescribeStream`,, e. `GetRecords` `GetShardIterator`
Se lo stream Firehose utilizza`DirectPut`, controlla le `IncomingRecords` metriche `IncomingBytes` and per vedere se c'è traffico in entrata. Se utilizzi `PutRecord` o `PutRecordBatch`, assicurati di rilevare le eccezioni e riprova. Consigliamo una policy di tentativi con back-off esponenziale con jitter e diversi tentativi. Inoltre, se utilizzi l'`PutRecordBatch`API, assicurati che il codice controlli il valore di [FailedPutCount](https://docs.aws.amazon.com/firehose/latest/APIReference/API_PutRecordBatch.html#Firehose-PutRecordBatch-response-FailedPutCount)nella risposta anche quando la chiamata API ha esito positivo.
------
#### [ Kinesis Data Stream ]
Se il flusso Firehose utilizza un flusso di dati Kinesis come origine, controlla le `IncomingRecords` metriche `IncomingBytes` e per il flusso di dati di origine. Inoltre, assicuratevi che le `DataReadFromKinesisStream.Records` metriche `DataReadFromKinesisStream.Bytes` and vengano emesse per lo stream Firehose.
------
# 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](monitoring-with-cloudwatch-metrics.md).
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](https://docs.aws.amazon.com/lambda/latest/dg/resource-model.html) delle funzioni Lambda.
+ Si sono verificati errori durante la distribuzione dei dati. Per informazioni su come monitorare gli errori utilizzando Amazon CloudWatch Logs, consulta[Monitora Amazon Data Firehose utilizzando i log CloudWatch](monitoring-with-cloudwatch-logs.md).
+ 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:listshards`autorizzazione al ruolo configurato in. [KinesisStreamSourceConfiguration](https://docs.aws.amazon.com/firehose/latest/APIReference/API_CreateDeliveryStream.html#Firehose-CreateDeliveryStream-request-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](https://docs.aws.amazon.com/firehose/latest/APIReference/API_BufferingHints.html).
+ 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, consulta[Monitora Amazon Data Firehose utilizzando i log CloudWatch](monitoring-with-cloudwatch-logs.md).
+ 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` `SET` `SET` 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/](https://console.aws.amazon.com/glue/).
1. Nel riquadro a sinistra, sotto l'intestazione **Data catalog (Catalogo dati)**, scegliere **Tables (Tabelle)**.
1. 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.
1. Scegli il pulsante **Modifica schema** nell'angolo in alto a destra della pagina dei dettagli.
1. Nella colonna **Data type (Tipo di dati)** scegliere il primo tipo di dati `set`.
1. Nell'elenco a discesa **Column type (Tipo di colonna)**, modificare il tipo da `set` a `array`.
1. Nel **ArraySchema**campo, inserisci o `array` `array``array`, a seconda del tipo di dati appropriato per lo scenario.
1. Scegliere **Aggiorna**.
1. Ripetere i passaggi precedenti per convertire altri tipi `set` in tipi `array`.
1. 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 ha lettere maiuscole e la distinzione tra maiuscole e minuscole è impostata su`false`, 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.
# Risoluzione dei problemi Amazon S3
Controlla quanto segue se i dati non vengono distribuiti al bucket Amazon Simple Storage Service (Amazon S3).
+ Controlla Firehose `IncomingBytes` e le `IncomingRecords` metriche per assicurarti che i dati vengano inviati correttamente al tuo stream Firehose. Per ulteriori informazioni, consulta [Monitora Amazon Data Firehose con parametri CloudWatch](monitoring-with-cloudwatch-metrics.md).
+ Se la trasformazione dei dati con Lambda è abilitata, controlla la `ExecuteProcessingSuccess` metrica Firehose per assicurarti che Firehose abbia provato a richiamare la tua funzione Lambda. Per ulteriori informazioni, consulta [Monitora Amazon Data Firehose con parametri CloudWatch](monitoring-with-cloudwatch-metrics.md).
+ Controlla la `DeliveryToS3.Success` metrica Firehose per assicurarti che Firehose abbia provato a inserire dati nel tuo bucket Amazon S3. Per ulteriori informazioni, consulta [Monitora Amazon Data Firehose con parametri CloudWatch](monitoring-with-cloudwatch-metrics.md).
+ Abilitare la registrazione degli errori, se non è già attivata, e controllare i log di errore per gli errori di distribuzione. Per ulteriori informazioni, consulta [Monitora Amazon Data Firehose utilizzando i log CloudWatch](monitoring-with-cloudwatch-logs.md).
+ Se nel registro viene visualizzato un messaggio di errore che dice *«Firehose si è verificato un problema InternalServerError durante la chiamata al servizio Amazon S3. L'operazione verrà ritentata; se l'errore persiste, contatta S3 per la risoluzione.»* , potrebbe essere dovuto al significativo aumento dei tassi di richiesta su una singola partizione in S3. Puoi ottimizzare i modelli di progettazione dei prefissi S3 per mitigare il problema. Per ulteriori informazioni, consulta [Modelli di progettazione basati sulle best practice: ottimizzazione delle prestazioni di Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html). Se il problema persiste, contatta il AWS Supporto per ulteriore assistenza.
+ Assicurati che il bucket Amazon S3 specificato nel tuo stream Firehose esista ancora.
+ Se la trasformazione dei dati con Lambda è abilitata, assicuratevi che la funzione Lambda specificata nel flusso Firehose esista ancora.
+ Assicurati che il ruolo IAM specificato nel tuo stream Firehose abbia accesso al tuo bucket S3 e alla funzione Lambda (se la trasformazione dei dati è abilitata). Inoltre, assicurati che il ruolo IAM abbia accesso al gruppo di log e ai flussi di CloudWatch log per controllare i log degli errori. Per ulteriori informazioni, consulta [Concedi a Firehose l'accesso a una destinazione Amazon S3](controlling-access.md#using-iam-s3).
+ Se utilizzi la trasformazione dei dati, verifica che la funzione Lambda non restituisca mai risposte con dimensioni del payload che superino i 6 MB. Per ulteriori informazioni, consulta [Amazon Data FirehoseData Transformation](data-transformation.md).
# Risoluzione dei problemi di Amazon Redshift
Controlla quanto segue se i dati non vengono distribuiti al cluster con provisioning Amazon Redshift o al gruppo di lavoro Amazon Redshift serverless.
Prima di essere caricati in Amazon Redshift, i dati vengono distribuiti al bucket S3. Se i dati non sono stati distribuiti sul bucket S3, consulta [Risoluzione dei problemi Amazon S3](data-not-delivered-to-s3.md).
+ Controlla la `DeliveryToRedshift.Success` metrica Firehose per assicurarti che Firehose abbia provato a copiare i dati dal tuo bucket S3 al cluster con provisioning di Amazon Redshift o al gruppo di lavoro Amazon Redshift Serverless. Per ulteriori informazioni, consulta [Monitora Amazon Data Firehose con parametri CloudWatch](monitoring-with-cloudwatch-metrics.md).
+ Abilitare la registrazione degli errori, se non è già attivata, e controllare i log di errore per gli errori di distribuzione. Per ulteriori informazioni, consulta [Monitora Amazon Data Firehose utilizzando i log CloudWatch](monitoring-with-cloudwatch-logs.md).
+ Consulta la `STL_CONNECTION_LOG` tabella Amazon Redshift per vedere se Firehose è in grado di effettuare connessioni di successo. In questa tabella si dovrebbero poter vedere le connessioni e il loro stato in base a un nome utente. Per ulteriori informazioni, consulta [https://docs.aws.amazon.com/redshift/latest/dg/r_STL_CONNECTION_LOG.html](https://docs.aws.amazon.com/redshift/latest/dg/r_STL_CONNECTION_LOG.html) nella *Guida per gli sviluppatori di database di Amazon Redshift*.
+ Se il controllo precedente mostra che le connessioni sono state stabilite, controlla la tabella `STL_LOAD_ERRORS` di Amazon Redshift per verificare il motivo dell'errore COPY. Per ulteriori informazioni, consulta [https://docs.aws.amazon.com/redshift/latest/dg/r_STL_LOAD_ERRORS.html](https://docs.aws.amazon.com/redshift/latest/dg/r_STL_LOAD_ERRORS.html) nella *Guida per gli sviluppatori di database di Amazon Redshift*.
+ Assicurati che la configurazione di Amazon Redshift nel tuo stream Firehose sia accurata e valida.
+ Assicurati che il ruolo IAM specificato nel tuo stream Firehose possa accedere al bucket S3 da cui Amazon Redshift copia i dati e anche alla funzione Lambda per la trasformazione dei dati (se la trasformazione dei dati è abilitata). Inoltre, assicurati che il ruolo IAM abbia accesso al gruppo di log e ai flussi di CloudWatch log per controllare i log degli errori. Per ulteriori informazioni, consulta [Concedi a Firehose l'accesso a una destinazione Amazon Redshift](controlling-access.md#using-iam-rs).
+ Se il cluster con provisioning di Amazon Redshift o il gruppo di lavoro Serverless Amazon Redshift si trova in un cloud privato virtuale (VPC), assicurati che il cluster consenta l'accesso dagli indirizzi IP Firehose. Per ulteriori informazioni, consulta [Concedi a Firehose l'accesso a una destinazione Amazon Redshift](controlling-access.md#using-iam-rs).
+ Assicurati che il cluster con provisioning Amazon Redshift o il gruppo di lavoro Amazon Redshift serverless sia disponibile pubblicamente.
+ Se utilizzi la trasformazione dei dati, verifica che la funzione Lambda non restituisca mai risposte con dimensioni del payload che superino i 6 MB. Per ulteriori informazioni, consulta [Amazon Data FirehoseData Transformation](data-transformation.md).
# Risoluzione dei problemi con Amazon OpenSearch Service
Controlla quanto segue se i dati non vengono consegnati al tuo dominio OpenSearch di servizio.
È possibile eseguire simultaneamente il backup dei dati sul bucket Amazon S3. Se i dati non sono stati distribuiti sul bucket S3, consulta [Risoluzione dei problemi Amazon S3](data-not-delivered-to-s3.md).
+ Controlla Firehose `IncomingBytes` e le `IncomingRecords` metriche per assicurarti che i dati vengano inviati correttamente al tuo stream Firehose. Per ulteriori informazioni, consulta [Monitora Amazon Data Firehose con parametri CloudWatch](monitoring-with-cloudwatch-metrics.md).
+ Se la trasformazione dei dati con Lambda è abilitata, controlla la `ExecuteProcessingSuccess` metrica Firehose per assicurarti che Firehose abbia provato a richiamare la tua funzione Lambda. Per ulteriori informazioni, consulta [Monitora Amazon Data Firehose con parametri CloudWatch](monitoring-with-cloudwatch-metrics.md).
+ Controllate la `DeliveryToAmazonOpenSearchService.Success` metrica Firehose per assicurarvi che Firehose abbia provato a indicizzare i dati nel cluster di servizi. OpenSearch Per ulteriori informazioni, consulta [Monitora Amazon Data Firehose con parametri CloudWatch](monitoring-with-cloudwatch-metrics.md).
+ Abilitare la registrazione degli errori, se non è già attivata, e controllare i log di errore per gli errori di distribuzione. Per ulteriori informazioni, consulta [Monitora Amazon Data Firehose utilizzando i log CloudWatch](monitoring-with-cloudwatch-logs.md).
+ Assicurati che la configurazione del OpenSearch servizio nel tuo stream Firehose sia accurata e valida.
+ Se la trasformazione dei dati con Lambda è abilitata, assicuratevi che la funzione Lambda specificata nel flusso Firehose esista ancora. Inoltre, assicurati che il ruolo IAM abbia accesso al gruppo di log e ai flussi di CloudWatch log per controllare i log degli errori. Per ulteriori informazioni, consulta [Concessione FirehoseAccess a una destinazione di OpenSearch servizio pubblico](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-es).
+ Assicurati che il ruolo IAM specificato nel tuo stream Firehose possa accedere al cluster di OpenSearch servizio, al bucket di backup S3 e alla funzione Lambda (se la trasformazione dei dati è abilitata). Inoltre, assicurati che il ruolo IAM abbia accesso al gruppo di log e ai flussi di CloudWatch log per controllare i log degli errori. Per ulteriori informazioni, consulta [Concedi a Firehose l'accesso a una destinazione di servizio pubblico OpenSearch](controlling-access.md#using-iam-es).
+ Se utilizzi la trasformazione dei dati, verifica che la funzione Lambda non restituisca mai risposte con dimensioni del payload che superino i 6 MB. Per ulteriori informazioni, consulta [Amazon Data FirehoseData Transformation](data-transformation.md).
+ Amazon Data Firehose attualmente non supporta l'invio di CloudWatch log alla destinazione di Amazon Service perché OpenSearch CloudWatch Amazon combina più eventi di registro in un unico record Firehose e OpenSearch Amazon Service non può accettare più eventi di log in un unico record. In alternativa, puoi prendere in considerazione [l'utilizzo del filtro di abbonamento per Amazon OpenSearch Service in CloudWatch Logs.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_OpenSearch_Stream.html)
# Risoluzione dei problemi di Splunk
Controlla quanto segue se i dati non vengono distribuiti sull'endpoint Splunk.
+ Se la tua piattaforma Splunk è in un VPC, assicurati che Firehose possa accedervi. Per ulteriori informazioni, consulta [Accesso a Splunk in VPC](controlling-access.md#using-iam-splunk-vpc).
+ Se utilizzi un AWS load balancer, assicurati che sia un Classic Load Balancer o un Application Load Balancer. Inoltre, abilita sessioni permanenti basate sulla durata con la scadenza dei cookie disabilitata per Classic Load Balancer e la scadenza è impostata al massimo (7 giorni) per Application Load Balancer. [Per informazioni su come eseguire questa operazione, consulta Duration-Based Session Stickiness for [Classic Load Balancer o un Application Load](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html#enable-sticky-sessions-duration) Balancer.](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/sticky-sessions.html)
+ Riesaminare i requisiti della piattaforma Splunk. Il componente aggiuntivo Splunk per Firehose richiede la versione 6.6.X o successiva della piattaforma Splunk. Per ulteriori informazioni, consulta [Estensione Splunk per Amazon Kinesis Firehose](http://docs.splunk.com/Documentation/AddOns/released/Firehose/Hardwareandsoftwarerequirements).
+ Se disponete di un proxy (Elastic Load Balancing o altro) tra Firehose e il nodo HTTP Event Collector (HEC), abilitate le sessioni permanenti per supportare i riconoscimenti HEC (). ACKs
+ Verificare che si stia utilizzando un token HEC valido.
+ Verificare che il token HEC sia abilitato.
+ Controllare se i dati che si sta inviando a Splunk sono formattati correttamente. Per ulteriori informazioni, consulta [Formattare eventi per HTTP Event Collector](http://docs.splunk.com/Documentation/Splunk/7.0.3/Data/FormateventsforHTTPEventCollector).
+ Verificare che il token HEC e l'evento di input siano configurati con un indice valido.
+ Quando un caricamento su Splunk non va a buon fine a causa di un errore del server dal nodo HEC, la richiesta viene automaticamente ripetuta. Se tutti i nuovi tentativi non riescono, viene eseguito il backup dei dati su Amazon S3. Controlla se i dati appaiono in Amazon S3, il che è un'indicazione di un errore di questo tipo.
+ Verificare di aver abilitato il riconoscimento dell'indicizzatore sul token HEC.
+ Aumenta il valore della configurazione `HECAcknowledgmentTimeoutInSeconds` di destinazione Splunk del tuo stream Firehose.
+ Aumenta il valore di `DurationInSeconds` under `RetryOptions` nella configurazione di destinazione Splunk del tuo stream Firehose.
+ Verificare lo stato di HEC. L'abilitazione del controllo dello stato è un prerequisito per il trasferimento dei dati a Splunk.
+ Se utilizzi la trasformazione dei dati, verifica che la funzione Lambda non restituisca mai risposte con dimensioni del payload che superino i 6 MB. Per ulteriori informazioni, consulta [Amazon Data Firehose Data Transformation](data-transformation.md#data-transformation.title).
+ Verificare che il parametro Splunk denominato `ackIdleCleanup` sia impostato su `true`. Per impostazione predefinita, è impostato su false. Per impostare questo parametro su `true`, procedi nel seguente modo:
+ Per una [distribuzione gestita Splunk Cloud](http://docs.splunk.com/Documentation/AddOns/released/Firehose/RequestFirehose), inviare un caso tramite il portale di supporto Splunk. In questo caso, chiedere al supporto Splunk di abilitare HTTP event collector, di impostare `ackIdleCleanup` su `true` in `inputs.conf` e di creare o modificare il sistema di bilanciamento del carico da utilizzare con questa estensione.
+ Per una [distribuzione Splunk Enterprise distribuita](http://docs.splunk.com/Documentation/AddOns/released/Firehose/ConfigureHECdistributed), impostare il parametro `ackIdleCleanup` su true nel file `inputs.conf`. Per gli utenti \$1nix, questo file si trova in `$SPLUNK_HOME/etc/apps/splunk_httpinput/local/`. Per gli utenti Windows, si trova in `%SPLUNK_HOME%\etc\apps\splunk_httpinput\local\`.
+ Per una [distribuzione Splunk Enterprise a istanza singola](http://docs.splunk.com/Documentation/AddOns/released/Firehose/ConfigureHECsingle), impostare il parametro `ackIdleCleanup` su `true` nel file `inputs.conf`. Per gli utenti \$1nix, questo file si trova in `$SPLUNK_HOME/etc/apps/splunk_httpinput/local/`. Per gli utenti Windows, si trova in `%SPLUNK_HOME%\etc\apps\splunk_httpinput\local\`.
+ Assicurati che il ruolo IAM specificato nel tuo stream Firehose possa accedere al bucket di backup S3 e alla funzione Lambda per la trasformazione dei dati (se la trasformazione dei dati è abilitata). Inoltre, assicurati che il ruolo IAM abbia accesso al gruppo CloudWatch Logs e ai flussi di log per controllare i log degli errori. Per maggiori informazioni, consulta [Grant FirehoseAccess to a Splunk Destination](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-splunk).
+ [Per reindirizzare i dati che sono stati consegnati al bucket di errore S3 (backup S3) su Splunk, 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)
+ Consulta [Risoluzione dei problemi dell'estensione Splunk per Amazon Kinesis Firehose](http://docs.splunk.com/Documentation/AddOns/released/Firehose/Troubleshoot).
# Risoluzione dei problemi relativi a Snowflake
Questa sezione descrive i passaggi più comuni per la risoluzione dei problemi relativi all'utilizzo di Snowflake come destinazione
## La creazione dello stream Firehose non riesce
Se la creazione di un flusso Firehose non riesce per uno stream che fornisce dati a un cluster Snowflake PrivateLink abilitato, significa che il VPCE-ID non è raggiungibile da Firehose. Ciò può essere dovuto a uno dei seguenti motivi:
+ VPCE-ID errato. Verificare che non vi siano errori tipografici.
+ Firehose non supporta Snowflake senza regione in anteprima. URLs Fornisci l'URL utilizzando Snowflake Account Locator. Consulta la documentazione di [Snowflake per maggiori dettagli.](https://docs.snowflake.com/en/user-guide/admin-account-identifier#format-2-legacy-account-locator-in-a-region)
+ Verificate che lo stream Firehose sia stato creato nella stessa AWS regione della regione Snowflake.
+ Se il problema persiste, contatta l'assistenza. AWS
### Errori di consegna
Controlla quanto segue se i dati non vengono recapitati alla tua tabella Snowflake. I dati con consegna non riuscita di Snowflake verranno recapitati al bucket di errore S3 insieme a un codice di errore e a un messaggio di errore corrispondenti al payload. Di seguito sono riportati alcuni scenari di errore comuni. Per l'elenco completo dei codici di errore, vedere[Errori di consegna dei dati Snowflake](monitoring-with-cloudwatch-logs.md#monitoring-snowflake-errors).
+ **Codice di errore: Snowflake. DefaultRoleMissing**: indica che il ruolo snowflake non è configurato durante la creazione del flusso Firehose. Se il ruolo Snowflake non è configurato, assicurati di impostare un ruolo predefinito per l'utente Snowflake specificato.
+ **Codice di errore: Snowflake. ExtraColumns**: indica che l'inserimento in Snowflake viene rifiutato a causa di colonne aggiuntive nel payload di input. Le colonne non presenti nella tabella non devono essere specificate. Nota che i nomi delle colonne Snowflake fanno distinzione tra maiuscole e minuscole. Se la consegna non riesce con questo errore nonostante la colonna sia presente nella tabella, assicuratevi che il nome della colonna nel payload di input corrisponda al nome della colonna dichiarato nella definizione della tabella.
+ **Codice di errore: Snowflake. MissingColumns**: Indica che l'inserimento in Snowflake viene rifiutato a causa della mancanza di colonne nel payload di input. Assicuratevi che i valori siano specificati per tutte le colonne che non possono essere annullate.
+ **Codice di errore: Snowflake. InvalidInput**: Questo può accadere quando Firehose non riesce ad analizzare il payload di input fornito in un formato JSON valido. Assicurati che il payload json sia ben formato, che non contenga virgolette doppie, virgolette, caratteri di escape, ecc. Attualmente Firehose supporta solo un singolo elemento JSON come payload di record, gli array JSON non sono supportati.
+ **Codice di errore: Snowflake. InvalidValue**: indica che la consegna non è riuscita a causa di un tipo di dati errato nel payload di input. Assicurati che i valori JSON specificati nel payload di input aderiscano al tipo di dati dichiarato nella definizione della tabella Snowflake.
+ **Codice di errore: Snowflake. InvalidTableType**: indica che il tipo di tabella configurato nel flusso Firehose non è supportato. Fai riferimento alle [limitazioni (in Limitazioni](https://docs.snowflake.com/en/user-guide/data-load-snowpipe-streaming-overview#limitations)) dello streaming snowpipe per le tabelle, le colonne e i tipi di dati supportati.
**Nota**
Per qualsiasi motivo, se la definizione della tabella o i permessi dei ruoli vengono modificati nella destinazione Snowflake dopo aver creato lo stream Firehose, Firehose può impiegare diversi minuti per rilevare tali modifiche. Se riscontri errori di consegna a causa di ciò, prova a eliminare e ricreare lo stream Firehose.
# Risoluzione dei problemi di raggiungibilità degli endpoint Firehose
Se l'API Firehose rileva un timeout, effettuate le seguenti operazioni per testare la raggiungibilità degli endpoint:
+ Controlla se le richieste API vengono effettuate da un host in un VPC. Tutto il traffico proveniente da un VPC richiede la configurazione di un endpoint VPC Firehose. Per ulteriori informazioni, vedere [Utilizzo di Firehose](https://docs.aws.amazon.com/firehose/latest/dev/vpc.html) con. AWS PrivateLink
+ Se il traffico proviene da una rete pubblica o da un VPC con l'endpoint VPC Firehose configurato in una particolare sottorete, esegui i seguenti comandi dall'host per verificare la connettività di rete. L'endpoint Firehose è disponibile negli endpoint e nelle quote [Firehose](https://docs.aws.amazon.com/general/latest/gr/fh.html).
+ Usa strumenti come **traceroute** o **tcping** per verificare se la configurazione di rete è corretta. Se fallisce, controlla le impostazioni di rete:
Esempio:
```
traceroute firehose.us-east-2.amazonaws.com
```
or
```
tcping firehose.us-east-2.amazonaws.com 443
```
+ Se sembra che l'impostazione di rete sia corretta e il seguente comando fallisce, controlla se [Amazon CA (Certificate Authority)](https://docs.aws.amazon.com//acm/latest/userguide/acm-overview.html) è nella catena di fiducia.
Esempio:
```
curl firehose.us-east-2.amazonaws.com
```
Se i comandi precedenti hanno esito positivo, riprova a utilizzare l'API per verificare se l'API restituisce una risposta.
# Risoluzione dei problemi degli endpoint HTTP
Questa sezione descrive le procedure di risoluzione dei problemi più comuni quando si ha a che fare con Amazon Data Firehose che fornisce dati a destinazioni endpoint HTTP generiche e a destinazioni partner, tra cui Datadog, Dynatrace, LogicMonitor MongoDB, New Relic, Splunk o Sumo Logic. Ai fini di questa sezione, tutte le destinazioni applicabili sono indicate come endpoint HTTP. Assicurati che il ruolo IAM specificato nel tuo stream Firehose possa accedere al bucket di backup S3 e alla funzione Lambda per la trasformazione dei dati (se la trasformazione dei dati è abilitata). Inoltre, assicurati che il ruolo IAM abbia accesso al gruppo di log e ai flussi di CloudWatch log per controllare i log degli errori. Per ulteriori informazioni, vedere [Concedere l'accesso a Firehose a una destinazione di endpoint HTTP](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-http).
**Nota**
Le informazioni contenute in questa sezione non si applicano alle seguenti destinazioni: Splunk, OpenSearch Service, S3 e Redshift.
## CloudWatch Registri
Si consiglia vivamente di abilitare la [CloudWatch registrazione per.](monitoring-with-cloudwatch-logs.md) I log vengono pubblicati solo in caso di errori durante la distribuzione alla destinazione.
### Eccezioni di destinazione
**ErrorCode: HttpEndpoint.DestinationException**
```
{
"deliveryStreamARN": "arn:aws:firehose:us-east-1:123456789012:deliverystream/ronald-test",
"destination": "custom.firehose.endpoint.com...",
"deliveryStreamVersionId": 1,
"message": "The following response was received from the endpoint destination. 413: {\"requestId\": \"43b8e724-dbac-4510-adb7-ef211c6044b9\", \"timestamp\": 1598556019164, \"errorMessage\": \"Payload too large\"}",
"errorCode": "HttpEndpoint.DestinationException",
"processor": "arn:aws:lambda:us-east-1:379522611494:function:httpLambdaProcessing"
}
```
Le eccezioni di destinazione indicano che Firehose **è** in grado di stabilire una connessione all'endpoint ed effettuare una richiesta HTTP, ma **non ha** ricevuto un codice di risposta 200. Anche le risposte 2xx che non sono 200 genereranno un'eccezione di destinazione. Amazon Data Firehose registra il codice di risposta e un payload di risposta troncato ricevuto dall'endpoint configurato in Logs. CloudWatch Poiché Amazon Data Firehose registra il codice di risposta e il payload senza modifiche o interpretazioni, spetta all'endpoint fornire il motivo esatto per cui ha rifiutato la richiesta di consegna HTTP di Amazon Data Firehose. Di seguito sono riportati i suggerimenti per la risoluzione dei problemi più comuni per queste eccezioni:
+ **400**: indica che stai inviando una richiesta errata a causa di un'errata configurazione di Amazon Data Firehose. Assicurati di avere [URL](https://docs.aws.amazon.com/firehose/latest/APIReference/API_HttpEndpointConfiguration.html#Firehose-Type-HttpEndpointConfiguration-Url), [attributi comuni](https://docs.aws.amazon.com/firehose/latest/APIReference/API_HttpEndpointRequestConfiguration.html#Firehose-Type-HttpEndpointRequestConfiguration-CommonAttributes), [codifica del contenuto](https://docs.aws.amazon.com/firehose/latest/APIReference/API_HttpEndpointRequestConfiguration.html#Firehose-Type-HttpEndpointRequestConfiguration-ContentEncoding), [chiave di accesso](https://docs.aws.amazon.com/firehose/latest/APIReference/API_HttpEndpointConfiguration.html#Firehose-Type-HttpEndpointConfiguration-AccessKey) e [suggerimenti di buffering](https://docs.aws.amazon.com/firehose/latest/APIReference/API_HttpEndpointDestinationConfiguration.html#Firehose-Type-HttpEndpointDestinationConfiguration-BufferingHints) corretti per la destinazione. Consulta la documentazione specifica della destinazione sulla configurazione richiesta.
+ **401**: indica che la chiave di accesso configurata per lo stream Firehose è errata o mancante.
+ **403**: indica che la chiave di accesso configurata per lo stream Firehose non dispone delle autorizzazioni per fornire dati all'endpoint configurato.
+ **413**: indica che il payload della richiesta che Amazon Data Firehose invia all'endpoint è troppo grande per essere gestito dall'endpoint. Prova a [ridurre il suggerimento di buffering](https://docs.aws.amazon.com/firehose/latest/APIReference/API_HttpEndpointBufferingHints.html#Firehose-Type-HttpEndpointBufferingHints-SizeInMBs) alla dimensione consigliata per la destinazione.
+ **429**: indica che Amazon Data Firehose invia richieste a una velocità superiore a quella gestita dalla destinazione. Ottimizza il suggerimento per il buffering aumentando il tempo di buffering e and/or aumentando la dimensione del buffering (ma sempre entro il limite della destinazione).
+ **5xx**: indica che esiste un problema con la destinazione. Il servizio Amazon Data Firehose funziona ancora correttamente.
**Importante**
Importante: sebbene questi siano i suggerimenti più comuni per la risoluzione dei problemi, endpoint specifici possono avere diversi motivi per fornire i codici di risposta e i suggerimenti specifici per gli endpoint devono essere seguiti per primi.
### Risposta non valida
**ErrorCode: HttpEndpoint.InvalidResponseFromDestination**
```
{
"deliveryStreamARN": "arn:aws:firehose:us-east-1:123456789012:deliverystream/ronald-test",
"destination": "custom.firehose.endpoint.com...",
"deliveryStreamVersionId": 1,
"message": "The response received from the specified endpoint is invalid. Contact the owner of the endpoint to resolve the issue. Response for request 2de9e8e9-7296-47b0-bea6-9f17b133d847 is not recognized as valid JSON or has unexpected fields. Raw response received: 200 {\"requestId\": null}",
"errorCode": "HttpEndpoint.InvalidResponseFromDestination",
"processor": "arn:aws:lambda:us-east-1:379522611494:function:httpLambdaProcessing"
}
```
Le eccezioni di risposta non valida indicano che Amazon Data Firehose ha ricevuto una risposta non valida dalla destinazione dell'endpoint. La risposta deve essere conforme alle [specifiche di risposta](httpdeliveryrequestresponse.md), altrimenti Amazon Data Firehose considererà il tentativo di consegna un fallimento e riconsegnerà nuovamente gli stessi dati fino al superamento della durata del nuovo tentativo configurata. Amazon Data Firehose considera le risposte che non rispettano le specifiche di risposta come errori, anche se la risposta ha lo stato 200. Se stai sviluppando un endpoint compatibile con Amazon Data Firehose, segui le specifiche di risposta per assicurarti che i dati vengano consegnati correttamente.
Di seguito sono riportati alcuni dei tipi comuni di risposte non valide e come risolverli:
+ **JSON non valido o campi imprevisti**: indica che la risposta non può essere deserializzata correttamente come JSON o contiene campi imprevisti. Assicurati che la risposta non sia codificata nel contenuto.
+ **Mancante RequestId**: indica che la risposta non contiene un RequestId.
+ **RequestId not match**: indica che il RequestID nella risposta non corrisponde al RequestID in uscita.
+ **Timestamp mancante**: indica che la risposta non contiene un campo timestamp. Il campo timestamp deve essere un numero e non una stringa.
+ **Intestazione Content-Type mancante**: indica che la risposta non contiene un'intestazione "content-type: application/json". Non sono accettati altri content-type.
**Importante**
[Importante: Amazon Data Firehose può fornire dati solo agli endpoint che seguono le specifiche di richiesta e risposta di Firehose.](httpdeliveryrequestresponse.md) Se stai configurando la tua destinazione con un servizio di terze parti, assicurati di utilizzare l'endpoint compatibile con Amazon Data Firehose corretto, che probabilmente sarà diverso dall'endpoint di ingestione pubblico. Ad esempio, l'endpoint Amazon Data Firehose di Datadog è `https://aws-kinesis-http-intake.logs.datadoghq.com/` mentre l'endpoint pubblico lo è. `https://api.datadoghq.com/`
### Altri errori comuni
Di seguito sono elencati codici di errore e definizioni aggiuntivi.
+ **Codice HttpEndpoint di errore:. RequestTimeout** - Indica che l'endpoint ha impiegato più di 3 minuti per rispondere. Se sei il proprietario della destinazione, riduci il tempo di risposta dell'endpoint di destinazione. Se non sei il proprietario della destinazione, contatta il proprietario e chiedi può ridurre il tempo di risposta (ad esempio ridurre il suggerimento di buffering in modo che la quantità di dati elaborati per richiesta sia inferiore).
+ **Codice di errore: HttpEndpoint. ResponseTooLarge** - Indica che la risposta è troppo grande. La risposta deve essere inferiore a 1 MiB incluse le intestazioni.
+ **Codice di errore: HttpEndpoint. ConnectionFailed** - Indica che non è stato possibile stabilire una connessione con l'endpoint configurato. Ciò potrebbe essere dovuto a un errore di battitura nell'URL configurato, all'inaccessibilità dell'endpoint ad Amazon Data Firehose o al fatto che l'endpoint impiega troppo tempo a rispondere alla richiesta di connessione.
+ **Codice di errore:. HttpEndpoint ConnectionReset** - Indica che è stata effettuata una connessione ma è stata ripristinata o chiusa prematuramente dall'endpoint.
+ **Codice di errore:. HttpEndpoint SSLHandshake**Errore: indica che non è stato possibile completare correttamente un handshake SSL con l'endpoint configurato.
# Risoluzione dei problemi relativi a MSK come origine
Questa sezione descrive le fasi comuni per la risoluzione dei problemi relativi all'utilizzo di MSK come origine
**Nota**
Per la risoluzione dei problemi di elaborazione, trasformazione o distribuzione di S3, consulta le sezioni precedenti
## Creazione di hose non riuscita
Controllate quanto segue se la creazione del tubo con MSK As Source non funziona:
+ Verifica che lo stato del cluster MSK di origine sia attivo.
+ Se utilizzi la connettività privata, assicurati che [Private Link sul cluster sia attivato](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access-mult-vpc.html).
Se utilizzi la connettività pubblica, assicurati che [l'accesso pubblico sul cluster sia attivato](https://docs.aws.amazon.com/msk/latest/developerguide/public-access.html).
+ Se utilizzi la connettività privata, assicurati di aggiungere una [policy basata sulle risorse che consenta a Firehose di creare Private Link](controlling-access.md#access-to-msk). Consultate anche: [Autorizzazioni MSK per più account](https://docs.aws.amazon.com/msk/latest/developerguide/mvpc-cross-account-permissions.html).
+ Assicurati che il ruolo nella configurazione del codice sorgente sia [autorizzato a importare dati dall'argomento del cluster](controlling-access.md#firehose-assume-role).
+ Assicurati che i tuoi gruppi di sicurezza VPC consentano il traffico in entrata sulle [porte utilizzate dai server bootstrap del cluster](https://docs.aws.amazon.com/msk/latest/developerguide/port-info.html).
## Hose sospeso
Controlla quanto segue se l'hose è in stato SOSPESO
+ Verifica che lo stato del cluster MSK di origine sia attivo.
+ Verifica che l'argomento di origine esista. Nel caso in cui l'argomento sia stato eliminato e ricreato, sarà necessario eliminare e ricreare anche lo stream Firehose.
## Hose in contropressione
Il valore di DataReadFromSource .Backpressured sarà 1 quando BytesPerSecondLimit per partizione viene superato o se il normale flusso di distribuzione è lento o interrotto.
+ Se stai raggiungendo, controlla la metrica DataReadFromSource .Bytes e BytesPerSecondLimit richiedi un aumento del limite.
+ Controlla CloudWatch i log, le metriche di destinazione, le metriche di trasformazione dei dati e le metriche di conversione del formato per identificare i colli di bottiglia.
## Aggiornamento dei dati non corretto
L'aggiornamento dei dati sembra errato
+ Firehose calcola l'aggiornamento dei dati in base al timestamp del record utilizzato. Per garantire che questo timestamp venga registrato correttamente quando il record del produttore viene mantenuto nei log del broker di Kafka, imposta la configurazione del tipo di timestamp dell'argomento Kafka su `message.timestamp.type=LogAppendTime`.
## Problemi di connessione al cluster MSK
La procedura seguente spiega come convalidare la connettività ai cluster MSK. Per informazioni dettagliate sulla configurazione del client Amazon MSK, consulta la [Guida introduttiva all'uso di Amazon MSK nella Amazon](https://docs.aws.amazon.com/msk/latest/developerguide/getting-started.html) *Managed Streaming for Apache Kafka Developer Guide*.
**Per convalidare la connettività ai cluster MSK**
1. Crea un'istanza Amazon EC2 basata su UNIX (preferibilmente AL2). Se sul cluster è abilitata solo la connettività VPC, assicurati che l'istanza EC2 venga eseguita sullo stesso VPC. Accedi tramite SSH all'istanza una volta che è disponibile. Per ulteriori informazioni, consulta [questo tutorial](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) nella *Amazon EC2 User* Guide.
1. Installa Java utilizzando il gestore di pacchetti Yum eseguendo il comando seguente. Per ulteriori informazioni, consulta le [istruzioni di installazione](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) nella Guida per l'utente di Amazon Corretto 8.
```
sudo yum install java-1.8.0
```
1. Installa il [AWS client](https://aws.amazon.com/cli/) eseguendo il comando seguente.
```
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
```
1. Scarica la versione 2.6\$1 del client Apache Kafka eseguendo il comando seguente.
```
wget https://archive.apache.org/dist/kafka/2.6.2/kafka_2.12-2.6.2.tgz
tar -xzf kafka_2.12-2.6.2.tgz
```
1. Vai alla directory `kafka_2.12-2.6.2/libs`, quindi esegui il comando per scaricare il file JAR IAM di Amazon MSK.
```
wget https://github.com/aws/aws-msk-iam-auth/releases/download/v1.1.3/aws-msk-iam-auth-1.1.3-all.jar
```
1. Crea il `client.properties` file nella cartella bin di Kafka.
1. Sostituiscilo `awsRoleArn` con il ruolo ARN che hai usato nel tuo Firehose `SourceConfiguration` e verifica la posizione del certificato. Consenti all'utente AWS client di assumere il ruolo. `awsRoleArn` AWS l'utente client tenterà di assumere il ruolo che hai specificato qui.
```
[ec2-user@ip-xx-xx-xx-xx bin]$ cat client.properties
security.protocol=SASL_SSL
sasl.mechanism=AWS_MSK_IAM
sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required awsRoleArn="" awsStsRegion="";
sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler
awsDebugCreds=true
ssl.truststore.location=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.342.b07-1.amzn2.0.1.x86_64/jre/lib/security/cacerts
ssl.truststore.password=changeit
```
1. Esegui il seguente comando Kafka per elencare gli argomenti. Se la tua connessione è pubblica, usa i server Bootstrap degli endpoint pubblici. Se la tua connessione è privata, usa i server Bootstrap endpoint privati.
```
bin/kafka-topics.sh --list --bootstrap-server --command-config bin/client.properties
```
Se la richiesta ha esito positivo, dovresti vedere un output simile all'esempio seguente.
```
[ec2-user@ip-xx-xx-xx-xx kafka_2.12-2.6.2]$ bin/kafka-topics.sh --list --bootstrap-server --command-config bin/client.properties
[xxxx-xx-xx 05:49:50,877] WARN The configuration 'awsDebugCreds' was supplied but isn't a known config. (org.apache.kafka.clients.admin.AdminClientConfig)
[xxxx-xx-xx 05:49:50,878] WARN The configuration 'ssl.truststore.location' was supplied but isn't a known config. (org.apache.kafka.clients.admin.AdminClientConfig)
[xxxx-xx-xx 05:49:50,878] WARN The configuration 'sasl.jaas.config' was supplied but isn't a known config. (org.apache.kafka.clients.admin.AdminClientConfig)
[xxxx-xx-xx 05:49:50,878] WARN The configuration 'sasl.client.callback.handler.class' was supplied but isn't a known config. (org.apache.kafka.clients.admin.AdminClientConfig)
[xxxx-xx-xx 05:49:50,878] WARN The configuration 'ssl.truststore.password' was supplied but isn't a known config. (org.apache.kafka.clients.admin.AdminClientConfig)
[xxxx-xx-xx 05:50:21,629] WARN [AdminClient clientId=adminclient-1] Connection to node...
__amazon_msk_canary
__consumer_offsets
```
1. In caso di problemi durante l'esecuzione dello script precedente, verifica che i server di bootstrap forniti siano raggiungibili sulla porta specificata. A tale scopo, è possibile scaricare e utilizzare **telnet** o un'utilità simile, come illustrato nel comando seguente.
```
sudo yum install telnet
telnet
```
Se la richiesta ha esito positivo, si otterrà il seguente risultato. Ciò significa che puoi connetterti al tuo cluster MSK all'interno del tuo VPC locale e che i server di bootstrap sono integri sulla porta specificata.
```
Connected to ..
```
1. [Se la richiesta non va a buon fine, controlla le regole in entrata sul tuo gruppo di sicurezza VPC.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html) Ad esempio, è possibile utilizzare le seguenti proprietà sulla regola in entrata.
```
Type: All traffic
Port: Port used by the bootstrap server (e.g. 14001)
Source: 0.0.0.0/0
```
Riprova la connessione **telnet** come mostrato nel passaggio precedente. [Se non riesci ancora a connetterti o se la connessione Firehose continua a fallire, contatta l'assistenza.AWS](https://aws.amazon.com/contact-us/)