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 possono aiutarti a risolvere i problemi che potresti avere con il tuo cluster AmazonMSK. 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
- Il cluster sembra bloccato nello stato CREATING
- Lo stato del cluster va 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 poco replicate () URP maggiori di 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: problemi di rete AWS
- Autenticazione non riuscita: troppe connessioni
- MSKServerless: la creazione del cluster non riesce
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 alla leadership e all'appartenenza a 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, ISR con conseguente latenza all'interno del cluster per tutti i broker che condividono tali partizioni (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 impostate le migliori pratiche per i 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 della velocità di storage per i broker in un cluster Amazon MSK.
Per ridurre al minimo la pressione di replica,
num.replica.fetchersabbassare 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 Amazon MSK bug-fix versione 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 Amazon MSK bug-fix, consulta. Aggiorna la versione di Apache Kafka
Le soluzioni alternative per risolvere questo problema senza aggiornare il cluster alla versione 2.4.1.1 di Amazon MSK bug-fix consistono nell'impostare i client Kafka da utilizzare o nel nodo broker di coordinamento del gruppo di consumatori Protocollo di iscrizione statico bloccato. Identificazione e riavvio
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.iddella 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.NumberOfCloudWatchResourcePoliciesLimitExceededeccezione, scegli una policy Amazon CloudWatch Logs esistente nel tuo account e aggiungi quanto segueJSON.
{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}
Se provi ad aggiungere JSON quanto sopra a una politica esistente ma ricevi un errore che indica che hai raggiunto la lunghezza massima per la politica che hai scelto, prova ad aggiungerlo JSON a un'altra delle tue politiche Amazon CloudWatch Logs. Dopo averlo aggiunto JSON a una politica esistente, prova ancora una volta a configurare la consegna dei log tramite broker-log ad Amazon Logs. CloudWatch
Nessun gruppo di sicurezza predefinito
Se provi a creare un cluster e ricevi un errore che indica che non esiste un gruppo di sicurezza predefinito, è possibile VPC che tu stia utilizzando un gruppo di sicurezza condiviso con te. Chiedi all'amministratore di concederti l'autorizzazione per descrivere i gruppi di sicurezza in questione VPC e riprova. Per un esempio di policy che consente questa azione, consulta AmazonEC2: consente la gestione dei gruppi EC2 di sicurezza associati a uno specificoVPC, a livello di programmazione e nella console.
Il cluster sembra bloccato 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 va 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 hanno accesso al cluster ma riscontrano ancora problemi nella produzione e nel consumo di dati, la causa potrebbe essere KAFKA-7697
, che riguarda Apache Kafka versione 2.1.0 e può portare a un punto morto per 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 MSK i comandi di Amazon, aggiorna il tuo 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 i MSK comandi Amazon AWS CLI per eseguire, consultaAmazonMSK: come funziona.
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 poco replicate () URP maggiori di zero
Il parametro UnderReplicatedPartitions è importante da monitorare. In un MSK cluster integro, questa metrica ha il valore 0. Se è maggiore di zero, il motivo potrebbe essere uno dei seguenti.
-
Se
UnderReplicatedPartitionspresenta 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 Best practice. -
Se
UnderReplicatedPartitionsè costantemente maggiore di 0, anche durante i periodi di traffico ridotto, il problema potrebbe essere che hai impostato un criterio restrittivo ACLs che non concede l'accesso all'argomento ai broker. Per replicare le partizioni, i broker devono essere autorizzati per entrambi gli argomenti. READ DESCRIBE DESCRIBEviene concesso di default con l'autorizzazione. READ Per informazioni sull'impostazioneACLs, vedere Autorizzazione e ACLs nella documentazionedi Apache Kafka.
Il cluster ha argomenti chiamati __amazon_msk_canary e __amazon_msk_canary_state
Potresti vedere che il tuo MSK cluster 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 sulle relative regole in entrata e in uscita, consulta Security groups for your VPC nella Amazon VPC User Guide.
Assicurati che il tuo indirizzo IP e la porta del cluster siano consentiti nelle regole in entrata della rete del cluster. VPC ACL A differenza dei gruppi di sicurezza, le reti ACLs sono prive di 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 Aggiungere ed eliminare regole nella Amazon VPC User Guide.
-
Assicurati di utilizzare la stringa bootstrap-brokers ad accesso pubblico per accedere al cluster. Un MSK cluster con accesso pubblico attivato ha due diverse stringhe bootstrap-brokers, una per l'accesso pubblico e una per l'accesso dall'interno. AWS Per ulteriori informazioni, consulta Ottieni i broker bootstrap usando il AWS Management Console.
Impossibile accedere al cluster dall'interno: problemi di rete AWS
Se disponi di un'applicazione Apache Kafka che non è in grado di comunicare correttamente con un MSK cluster, 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-brokercon uno degli indirizzi del broker che hai ottenuto nel passaggio precedente. Replace (Sostituisci)port-numbercon 9094 se il cluster è configurato per utilizzare l'TLSautenticazione. Se il cluster non utilizza l'TLSautenticazione, sostituisciport-numbercon 9092. Eseguire il comando dal computer client.telnetbootstrap-brokerport-numberDove il numero di porta è:
9094 se il cluster è configurato per utilizzare l'autenticazione. TLS
9092 Se il cluster non utilizza l'TLSautenticazione.
È 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 ottenere bootstrap-brokers, utilizzare uno dei metodi descritti inOttieni i broker bootstrap per un cluster Amazon MSK. Replace (Sostituisci) topic con il nome dell'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.
EC2Client e MSK cluster Amazon nello stesso ambiente VPC
Se la macchina client si trova nella VPC stessa area del MSK cluster, assicurati che il gruppo di sicurezza del cluster disponga di una regola in entrata che accetti il traffico proveniente 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'EC2istanza Amazon che si trova nella VPC stessa area del cluster, consultaInizia a usare Amazon MSK.
EC2Client e MSK cluster Amazon in diversi VPCs
Se il computer client e il cluster si trovano in due ambienti diversiVPCs, 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 VPC peering, vedere Working with VPC Peering Connections.
Client locale
Nel caso di un client locale configurato per connettersi al MSK cluster tramite AWS VPN, assicurati quanto segue:
-
Lo stato della VPN connessione è
UP. Per informazioni su come controllare lo stato della VPN connessione, vedi Come posso controllare lo stato attuale del mio VPN tunnel?. -
La tabella di routing del cluster VPC contiene la route per un locale CIDR la cui destinazione ha il formato
Virtual private gateway(vgw-xxxxxxxx). -
Il gruppo di sicurezza del MSK cluster consente il traffico sulla porta 2181, sulla porta 9092 (se il cluster accetta traffico in chiaro) e sulla porta 9094 (se il cluster accetta traffico crittografato). TLS
AWS Direct Connect
Se il client utilizza AWS Direct Connect, vedi 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, usa strumenti come tcpdump e Wireshark per analizzare il traffico e assicurarti che raggiunga il cluster. MSK
Autenticazione non riuscita: troppe connessioni
L'Failed authentication ... Too many connectserrore indica che un broker si sta proteggendo perché uno o più IAM client stanno tentando di connettersi ad esso a una velocità aggressiva. Per aiutare i broker ad accettare un tasso più elevato di nuove IAM connessioni, puoi aumentare il parametro di reconnect.backoff.ms
Per ulteriori informazioni sui limiti di velocità per le nuove connessioni per broker, consulta la pagina MSKQuota Amazon.
MSKServerless: la creazione del cluster non riesce
Se provi a creare un cluster MSK Serverless e il flusso di lavoro fallisce, potresti non avere l'autorizzazione per creare un VPC endpoint. Verifica che l'amministratore ti abbia concesso l'autorizzazione a creare un VPC endpoint autorizzando l'azione. ec2:CreateVpcEndpoint
Per un elenco completo delle autorizzazioni necessarie per eseguire tutte le MSK azioni di Amazon, consultaAWS politica gestita: A mazonMSKFull Access.
