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
Argomenti
- La sostituzione del volume causa la saturazione del disco a causa del sovraccarico della replica
- Gruppo di consumatori bloccato nello stato PreparingRebalance
- Errore nell'invio dei log del broker ad Amazon CloudWatch Logs
- Nessun gruppo di sicurezza predefinito
- I cluster sono bloccati nello stato CREATING
- Lo stato del cluster passa da CREATING a FAILED
- Lo stato del cluster è ACTIVE ma i produttori non possono inviare dati o i consumatori non possono ricevere dati
- AWS CLI non riconosce Amazon MSK
- Le partizioni vengono messe offline o le repliche non sono sincronizzate
- Lo spazio su disco è insufficiente
- La memoria è insufficiente
- Il produttore ottiene NotLeaderForPartitionException
- Partizioni sottoreplicate (URP) superiori a zero
- Il cluster ha argomenti chiamati __amazon_msk_canary e __amazon_msk_canary_state
- La replica delle partizioni ha esito negativo
- Impossibile accedere al cluster con accesso pubblico attivato
- Impossibile accedere al cluster dall'interno AWS: problemi di rete
- Autenticazione non riuscita: troppe connessioni
- Autenticazione fallita: sessione troppo breve
- MSK Serverless: la creazione del cluster ha esito negativo
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
Per migliorare la postura I/O della replica, assicuratevi che siano state adottate le migliori impostazioni dei thread.
Per ridurre la probabilità di saturazione del volume sottostante, abilita lo storage fornito con un throughput più elevato. Un valore di throughput minimo di 500 MIB/s è consigliato per i casi di replica ad alto throughput, ma il valore effettivo necessario varia in base alla velocità effettiva e al caso d'uso. Esegui il provisioning del throughput di storage per i broker Standard in un cluster Amazon MSK.
Per ridurre al minimo la pressione di replica,
num.replica.fetchers
abbassare al valore predefinito di2
.
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
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:
Imposta la proprietà
group.instance.id
della configurazione dei consumatori Kafkasu una stringa statica che identifica il consumatore nel gruppo. Assicurati che le altre istanze della configurazione siano aggiornate in modo da utilizzare la stringa statica.
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:
Identifica il coordinatore del gruppo utilizzando il comando
kafka-consumer-groups.sh
.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.NumberOfCloudWatchResourcePoliciesLimitExceeded
eccezione, 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 ACLsnella 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:
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.
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.
-
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à.
Utilizzare uno dei metodi descritti in Ottieni i broker bootstrap per un cluster Amazon MSK per ottenere gli indirizzi dei broker bootstrap.
-
Nel comando seguente sostituisci
bootstrap-broker
con uno degli indirizzi del broker ottenuti nel passaggio precedente. Sostituireport-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.
-
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-listbootstrap-brokers
--producer.config client.properties --topictopic
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 short
errore 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.