Risolvi i problemi del tuo cluster Amazon MSK - Amazon Managed Streaming per Apache Kafka

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 i problemi del tuo cluster Amazon MSK

Le seguenti informazioni consentono di semplificare la risoluzione dei problemi che si potrebbero verificare con il cluster Amazon MSK. Puoi anche pubblicare il problema in AWS re:Post. Per la risoluzione dei problemi di Amazon MSK Replicator, consulta. Risolvete i problemi MSK di Replicator

La sostituzione del volume causa la saturazione del disco a causa del sovraccarico della replica

In caso di guasto hardware non pianificato del volume, Amazon MSK può sostituire il volume con una nuova istanza. Kafka ripopola il nuovo volume replicando le partizioni di altri broker del cluster. Una volta che le partizioni sono state replicate e recuperate, sono idonee per l'iscrizione alla leadership e all'In-Sync Replica (ISR).

Problema

In un broker che si sta riprendendo dalla sostituzione dei volumi, alcune partizioni di dimensioni diverse potrebbero tornare online prima di altre. Ciò può essere problematico in quanto tali partizioni possono servire il traffico proveniente dallo stesso broker che sta ancora recuperando (replicando) altre partizioni. Questo traffico di replica a volte può saturare i limiti di throughput del volume sottostanti, che nel caso predefinito sono 250 MiB al secondo. Quando si verifica questa saturazione, tutte le partizioni già interessate ne risentono, con conseguente latenza all'interno del cluster per tutti i broker che condividono ISR con quelle partizioni interessate (non solo le partizioni leader dovute agli ack remoti). acks=all Questo problema è più comune nei cluster più grandi che hanno un numero maggiore di partizioni di dimensioni variabili.

Raccomandazione

Gruppo di consumatori bloccato nello stato PreparingRebalance

Se uno o più gruppi di consumatori sono bloccati in uno stato di ribilanciamento perpetuo, la causa potrebbe essere il problema KAFKA-9752 di Apache Kafka, che riguarda le versioni 2.3.1 e 2.4.1 di Apache Kafka.

Per risolvere questo problema, ti consigliamo di aggiornare il cluster alla versione Versione di correzione dei bug Amazon MSK 2.4.1.1, che contiene una correzione per questo problema. Per informazioni sull'aggiornamento di un cluster esistente alla versione 2.4.1.1 di correzione dei bug di Amazon MSK, consulta la pagina Aggiornare la versione di Apache Kafka.

Le soluzioni alternative per risolvere questo problema senza aggiornare il cluster alla versione di correzione del bug Amazon MSK 2.4.1.1 consistono nell'impostare i client Kafka in modo da utilizzare Protocollo di iscrizione statico oppure Identificazione e riavvio il nodo dei broker di coordinamento del gruppo di consumatori bloccato.

Implementazione del protocollo di iscrizione statico

Per implementare il protocollo di iscrizione statico nei client, procedi come indicato di seguito:

  1. Imposta la proprietà group.instance.id della configurazione dei consumatori Kafka su una stringa statica che identifica il consumatore nel gruppo.

  2. Assicurati che le altre istanze della configurazione siano aggiornate in modo da utilizzare la stringa statica.

  3. Implementa le modifiche ai tuoi consumatori Kafka.

L'utilizzo del protocollo di iscrizione statico è più efficace se il timeout della sessione nella configurazione client è impostato su una durata che consenta al consumatore di ripristinare il sistema senza innescare prematuramente un ribilanciamento del gruppo di consumatori. Ad esempio, se l'applicazione consumatore può tollerare 5 minuti di indisponibilità, un valore ragionevole per il timeout della sessione sarebbe 4 minuti anziché il valore predefinito di 10 secondi.

Nota

L'utilizzo del protocollo di iscrizione statico riduce solamente la probabilità di riscontrare questo problema. È possibile che questo problema si verifichi ancora anche quando si utilizza il protocollo di iscrizione statico.

Riavvio del nodo dei broker di coordinamento

Per riavviare il nodo dei broker di coordinamento, procedi come segue:

  1. Identifica il coordinatore del gruppo utilizzando il comando kafka-consumer-groups.sh.

  2. Riavvia il coordinatore del gruppo di consumatori bloccato utilizzando l'azione RebootBrokerAPI.

Errore nell'invio dei log del broker ad Amazon CloudWatch Logs

Quando provi a configurare il tuo cluster per inviare i log del broker ad Amazon CloudWatch Logs, potresti ottenere una delle due eccezioni.

Se viene restituita un'eccezione InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded, riprova utilizzando i gruppi di log che iniziano con /aws/vendedlogs/. Per ulteriori informazioni, consulta la pagina Enabling Logging from Certain Amazon Web Services.

Se ricevi un'InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceededeccezione, scegli una policy Amazon CloudWatch Logs esistente nel tuo account e aggiungi il seguente codice JSON.

{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}

Se provi ad aggiungere il codice JSON sopra riportato a una policy esistente ma ricevi un errore che indica che hai raggiunto la lunghezza massima per la policy che hai scelto, prova ad aggiungere il codice JSON a un'altra delle tue politiche Amazon Logs. CloudWatch Dopo aver aggiunto il codice JSON a una policy esistente, prova ancora una volta a configurare la distribuzione dei log del broker ad Amazon Logs. CloudWatch

Nessun gruppo di sicurezza predefinito

Se cerchi di creare un cluster e ricevi un errore che indica che non esiste un gruppo di sicurezza predefinito, è possibile che il VPC che stai utilizzando sia stato condiviso con te. Chiedi all'amministratore di concedere l'autorizzazione per descrivere i gruppi di sicurezza in questo VPC e riprova. Per un esempio di policy che consente questa azione, consulta Amazon EC2: consente la gestione dei gruppi di EC2 sicurezza associati a un VPC specifico, a livello di programmazione e nella console.

I cluster sono bloccati nello stato CREATING

A volte la creazione del cluster può richiedere fino a 30 minuti. Attendi 30 minuti e controlla nuovamente lo stato del cluster.

Lo stato del cluster passa da CREATING a FAILED

Prova a creare nuovamente il cluster.

Lo stato del cluster è ACTIVE ma i produttori non possono inviare dati o i consumatori non possono ricevere dati

  • Se la creazione del cluster va a buon fine (lo stato del cluster è ACTIVE), ma non è possibile inviare o ricevere dati, assicurati che le applicazioni produttore e consumatore dispongano dell'accesso al cluster. Per ulteriori informazioni, consulta le linee guida in Passaggio 3: creazione di un computer client.

  • Se i produttori e i consumatori dispongono dell'accesso al cluster ma si verificano ancora problemi nella produzione e nel consumo di dati, è possibile che la causa sia riconducibile a KAFKA-7697, che influenza Apache Kafka versione 2.1.0 e può condurre a un deadlock in uno o più broker. Valuta la possibilità di eseguire la migrazione ad Apache Kafka 2.2.1, che non è influenzato da questo bug. Per informazioni sulla migrazione, consulta Esegui la migrazione a un cluster Amazon MSK.

AWS CLI non riconosce Amazon MSK

Se lo hai AWS CLI installato, ma non riconosce i comandi di Amazon MSK, esegui l'upgrade AWS CLI alla versione più recente. Per istruzioni dettagliate su come aggiornare AWS CLI, consulta Installazione di AWS Command Line Interface. Per informazioni su come utilizzare per AWS CLI eseguire i comandi Amazon MSK, consultaCaratteristiche e concetti chiave di Amazon MSK.

Le partizioni vengono messe offline o le repliche non sono sincronizzate

Questi sintomi possono essere causati da spazio su disco insufficiente. Per informazioni, consulta Lo spazio su disco è insufficiente.

Lo spazio su disco è insufficiente

Vedere le best practice seguenti per gestire lo spazio su disco: Monitoraggio dello spazio su disco e Regolazione dei parametri di conservazione dei dati.

La memoria è insufficiente

Se il parametro MemoryUsed diventa alto o il parametro MemoryFree diventa basso, ciò non significa che ci sia un problema. Apache Kafka è progettato per utilizzare e gestire in maniera ottimale la massima quantità di memoria.

Il produttore ottiene NotLeaderForPartitionException

Questo è spesso un errore temporaneo. Impostare il parametro di configurazione retries del produttore su un valore più alto del valore corrente.

Partizioni sottoreplicate (URP) superiori a zero

Il parametro UnderReplicatedPartitions è importante da monitorare. In un cluster MSK integro, il valore di questo parametro è 0. Se è maggiore di zero, il motivo potrebbe essere uno dei seguenti.

  • Se UnderReplicatedPartitions presenta un picco, è possibile che non sia stato effettuato il provisioning del cluster alle dimensioni corrette per gestire il traffico in entrata e in uscita. Per informazioni, consulta Le migliori pratiche per i broker standard.

  • Se UnderReplicatedPartitions è costantemente maggiore di 0, anche durante i periodi di traffico limitato, il problema potrebbe essere dovuto al fatto che hai impostato delle opzioni restrittive ACLs che non consentono l'accesso all'argomento ai broker. Per replicare le partizioni, i broker devono disporre dell'autorizzazione per gli argomenti READ e DESCRIBE. L'argomento DESCRIBE viene concesso per impostazione predefinita con l'autorizzazione READ. Per informazioni sull'impostazione ACLs, consulta Autorizzazione e ACLs nella documentazione di Apache Kafka.

Il cluster ha argomenti chiamati __amazon_msk_canary e __amazon_msk_canary_state

Potresti notare che il tuo cluster MSK ha un argomento con il nome __amazon_msk_canary e un altro con il nome __amazon_msk_canary_state. Si tratta di argomenti interni che Amazon MSK crea e utilizza per i parametri diagnostici e di salute dei cluster. Questi argomenti sono di dimensioni trascurabili e non possono essere eliminati.

La replica delle partizioni ha esito negativo

Assicurati di non aver impostato ACLs CLUSTER_ACTIONS.

Impossibile accedere al cluster con accesso pubblico attivato

Se il cluster ha attivato l'accesso pubblico, ma non riesci ancora ad accedervi da Internet, esegui i passaggi seguenti:

  1. Assicurati che le regole in entrata del gruppo di sicurezza del cluster consentano il tuo indirizzo IP e la porta del cluster. Per un elenco dei numeri di porta del cluster, consulta la pagina Informazioni sulle porte. Assicurati inoltre che le regole in uscita del gruppo di sicurezza consentano le comunicazioni in uscita. Per ulteriori informazioni sui gruppi di sicurezza e le rispettive regole in entrata e in uscita, consulta la pagina Security groups for your VPC nella Guida per l'utente di Amazon VPC.

  2. Assicurati che il tuo indirizzo IP e la porta del cluster siano consentiti nelle regole in entrata dell'ACL della rete VPC del cluster. A differenza dei gruppi di sicurezza, le reti sono prive di ACLs stato. Ciò significa che è necessario configurarne le regole in entrata e in uscita. Nelle regole in uscita, consenti tutto il traffico (intervallo di porte: 0-65535) verso il tuo indirizzo IP. Per ulteriori informazioni, consulta la pagina Add and delete rules nella Guida per l'utente di Amazon VPC.

  3. Assicurati di utilizzare la stringa bootstrap-brokers ad accesso pubblico per accedere al cluster. Un cluster MSK con accesso pubblico attivato ha due diverse stringhe bootstrap-brokers, una per l'accesso pubblico e una per l'accesso dall'interno di AWS. Per ulteriori informazioni, consulta Ottieni i broker bootstrap usando il AWS Management Console.

Impossibile accedere al cluster dall'interno AWS: problemi di rete

Se disponi di un'applicazione Apache Kafka che non è in grado di comunicare correttamente con un cluster MSK, inizia eseguendo il seguente test di connettività.

  1. Utilizzare uno dei metodi descritti in Ottieni i broker bootstrap per un cluster Amazon MSK per ottenere gli indirizzi dei broker bootstrap.

  2. Nel comando seguente sostituisci bootstrap-broker con uno degli indirizzi del broker ottenuti nel passaggio precedente. Sostituire port-number con 9094 se il cluster è configurato per utilizzare l'autenticazione TLS. Se il cluster non utilizza l'autenticazione TLS, port-number sostituiscila con 9092. Eseguire il comando dal computer client.

    telnet bootstrap-broker port-number

    Dove il numero di porta è:

    • 9094 se il cluster è configurato per utilizzare l'autenticazione TLS.

    • 9092 Se il cluster non utilizza l'autenticazione TLS.

    • È necessario un numero di porta diverso se l'accesso pubblico è abilitato.

    Eseguire il comando dal computer client.

  3. Ripetere il comando precedente per tutti i broker bootstrap.

Se la macchina client è in grado di accedere ai broker, significa che non ci sono problemi di connettività. In questo caso, eseguire il comando seguente per verificare se il client Apache Kafka è configurato correttamente. Per ottenerlobootstrap-brokers, usa uno dei metodi descritti inOttieni i broker bootstrap per un cluster Amazon MSK. Sostituiscilo topic con il nome del tuo argomento.

<path-to-your-kafka-installation>/bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties --topic topic

Se il comando precedente va a buon fine, significa che il client è configurato correttamente. Se non è ancora possibile produrre e consumare da un'applicazione, eseguire il debug del problema a livello di applicazione.

Se il computer client non è in grado di accedere ai broker, consulta le seguenti sottosezioni per una guida basata sulla configurazione del computer client.

EC2 Client Amazon e cluster MSK nello stesso VPC

Se il computer client si trova nello stesso VPC del cluster MSK, assicurati che il gruppo di sicurezza del cluster disponga di una regola in entrata che accetta il traffico dal gruppo di sicurezza del computer client. Per informazioni sull'impostazione di queste regole, consulta Regole del gruppo di sicurezza. Per un esempio di come accedere a un cluster da un' EC2 istanza Amazon che si trova nello stesso VPC del cluster, vedi. Inizia a usare Amazon MSK

EC2 Client Amazon e cluster MSK in diversi VPCs

Se il computer client e il cluster si trovano in due ambienti diversi VPCs, verifica quanto segue:

  • I due VPCs sono peer-to-peer.

  • Lo stato della connessione peering è attivo.

  • Le tabelle dei percorsi delle due VPCs sono impostate correttamente.

Per informazioni sul peering VPC, consulta Utilizzo di connessioni peering VPC.

Client locale

Nel caso di un client locale configurato per connettersi al cluster MSK utilizzando AWS VPN, assicurati quanto segue:

  • Lo stato della connessione VPN è UP. Per informazioni su come verificare lo stato della connessione VPN, consulta How do I check the current status of my VPN tunnel?.

  • La tabella di routing del VPC del cluster contiene la route per un CIDR locale la cui destinazione ha il formato Virtual private gateway(vgw-xxxxxxxx).

  • Il gruppo di sicurezza del cluster MSK consente il traffico sulla porta 2181, sulla porta 9092 (se il cluster accetta traffico non crittografato) e sulla porta 9094 (se il cluster accetta traffico crittografato TLS).

Per ulteriori indicazioni AWS VPN sulla risoluzione dei problemi, consulta Troubleshooting Client VPN.

AWS Direct Connect

Se il client utilizza AWS Direct Connect, consulta Risoluzione dei problemi AWS Direct Connect.

Se le linee guida per risoluzione dei problemi precedenti non consentono di risolvere il problema, assicurarsi che il traffico di rete non sia bloccato da un firewall. Per ulteriori operazioni di debug, utilizza strumenti come tcpdump e Wireshark per analizzare il traffico e assicurarti che raggiunga il cluster MSK.

Autenticazione non riuscita: troppe connessioni

L'errore Failed authentication ... Too many connects indica che un broker si sta proteggendo perché uno o più client IAM stanno tentando di connettersi ad esso a una velocità aggressiva. Per aiutare i broker ad accettare nuove connessioni IAM a una velocità più elevata, puoi aumentare il parametro di configurazione reconnect.backoff.ms.

Per ulteriori informazioni sui limiti di velocità per le nuove connessioni per broker, consulta la pagina Quota di Amazon MSK.

Autenticazione fallita: sessione troppo breve

L'Failed authentication ... Session too shorterrore si verifica quando il client tenta di connettersi a un cluster utilizzando credenziali IAM che stanno per scadere. Assicurati di controllare come vengono aggiornate le tue credenziali IAM. Molto probabilmente, le credenziali vengono sostituite troppo vicino alla scadenza della sessione, il che comporta problemi sul lato server e errori di autenticazione.

MSK Serverless: la creazione del cluster ha esito negativo

Se si tenta di creare un cluster MSK Serverless e il flusso di lavoro ha esito negativo, è possibile che non si disponga dell'autorizzazione per creare un endpoint VPC. Verifica che l'amministratore ti abbia concesso l'autorizzazione a creare un endpoint VPC consentendo l'operazione ec2:CreateVpcEndpoint.

Per un elenco completo delle autorizzazioni necessarie per eseguire tutte le operazioni di Amazon MSK, consulta la pagina AWS politica gestita: Amazon MSKFull Access.