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. Risoluzione dei problemi relativi ad Amazon MSK Replicator

La sostituzione del volume causa la saturazione del disco a causa del sovraccarico delle repliche

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 replicate e ripristinate, le partizioni sono idonee per diventare membri della leadership e della replica in-sincronizzata (ISR).

Problema

In un broker in fase di recupero dopo la sostituzione del volume, alcune partizioni di varie dimensioni possono 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 può talvolta saturare i limiti di throughput del volume sottostante, che nel caso predefinito sono 250 MiB al secondo. Quando si verifica questa saturazione, tutte le partizioni già recuperate subiranno un impatto, con conseguente latenza in tutto il cluster per tutti i broker che condividono l'ISR con le partizioni ripristinate (non solo le partizioni leader dovute agli ack remoti). acks=all Questo problema è più comune nei cluster più grandi con un numero maggiore di partizioni di dimensioni variabili.

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 di Apache Kafka, che riguarda le versioni di Apache Kafka KAFKA-9752 2.3.1 e 2.4.1.

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 Aggiorna 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:

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.

Riavvio del nodo dei broker di coordinamento

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

Errore durante l'invio dei log dei broker ad Amazon CloudWatch Logs

Quando provi a configurare il cluster per inviare i log dei broker ad Amazon CloudWatch Logs, potresti riscontrare 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 riscontri un'InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceededeccezione, scegli una policy Amazon CloudWatch Logs esistente nel tuo account e aggiungi il seguente JSON.

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

Se provi ad aggiungere il codice JSON riportato sopra a una policy esistente ma ricevi un errore che indica che hai raggiunto la lunghezza massima per la policy selezionata, prova ad aggiungere il JSON a un'altra delle tue politiche Amazon Logs. CloudWatch Dopo aver aggiunto il JSON a una policy esistente, riprova a configurare la consegna dei broker-log 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 una policy che consente questa operazione, consulta Amazon EC2: consente la gestione dei gruppi di sicurezza EC2 associati a uno specifico VPC, in modo programmatico 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

AWS CLI non riconosce Amazon MSK

Se hai AWS CLI installato, ma non riconosce i comandi Amazon MSK, esegui l'upgrade AWS CLI alla versione più recente. Per istruzioni dettagliate su come aggiornare il AWS CLI, consulta Installazione di AWS Command Line Interface. Per informazioni su come utilizzare i comandi Amazon MSK AWS CLI per eseguire, 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.

Under-replicated partizioni (URP) maggiori di 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.

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 le ACL su 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:

Impossibile accedere al cluster tramite bootstrap IPv6

Se hai problemi di connessione a un cluster utilizzando le stringhe di bootstrap IPv6 fornite, procedi nel seguente modo:

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

Se il computer 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. Sostituisci 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.

Client Amazon EC2 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'istanza Amazon EC2 che si trova nello stesso VPC del cluster, consulta la pagina Inizia a usare Amazon MSK.

Client Amazon EC2 e cluster MSK in VPC diversi

Se il computer client e il cluster si trovano in due VPC diversi, verificare quanto segue:

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

On-premises cliente

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

Per ulteriori indicazioni sulla risoluzione dei problemi, consulta Site-to-Site VPN Troubleshooting Client VPN. https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/troubleshooting.html

Direct Connect

Se il client utilizza Direct Connect, vedi Risoluzione dei problemi. 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 non riuscita: sessione troppo breve

L'Failed authentication ... Session too shorterrore si verifica quando il client tenta di connettersi a un cluster utilizzando le 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: AmazonMSKFullAccess.

Impossibile eseguire l'aggiornamento KafkaVersionsList nella configurazione MSK

Quando si aggiorna la KafkaVersionsList proprietà nella risorsa AWS: :MSK: :Configuration, l'aggiornamento non riesce e viene visualizzato il seguente errore.

Resource of type 'AWS::MSK::Configuration' with identifier '<identifierName>' already exists.

Quando si aggiorna la KafkaVersionsList proprietà, AWS CloudFormation ricrea una nuova configurazione con la proprietà aggiornata prima di eliminare la vecchia configurazione. L'aggiornamento CloudFormation dello stack non riesce perché la nuova configurazione utilizza lo stesso nome della configurazione esistente. Tale aggiornamento richiede la sostituzione di una risorsa. Per eseguire correttamente l'aggiornamentoKafkaVersionsList, è necessario aggiornare anche la proprietà Name nella stessa operazione.

Inoltre, se la configurazione è collegata a cluster creati utilizzando Console di gestione AWS or AWS CLI, aggiungete quanto segue alla risorsa di configurazione per evitare tentativi falliti di eliminazione delle risorse.

UpdateReplacePolicy: Retain

Una volta completato l'aggiornamento, accedi alla console Amazon MSK ed elimina la vecchia configurazione. Per informazioni sulle configurazioni MSK, consulta Configurazione con provisioning di Amazon MSK.

Errori di configurazione del nome di dominio personalizzato

Quando si crea o si applica una configurazione che includecustom.advertised.listeners, è possibile che si verifichino i seguenti errori. Per ulteriori informazioni sulla configurazione dei nomi di dominio personalizzati, vedereConfigura nomi di dominio personalizzati per il tuo cluster Amazon MSK.

Formato non valido

L'API restituisce un errore HTTP 400 con invalidParameter=serverproperties il seguente messaggio.

Invalid custom.advertised.listeners format. Expected: LISTENER_NAME://host:port+{broker_id} (comma-separated for multiple).

Il valore che hai fornito custom.advertised.listeners non segue il formato richiesto. Correggilo in modo che utilizzi lo schemaLISTENER_NAME://hostname:port+{broker_id}, assicurati che la variabile {broker_id} template appaia nella porta in modo che ogni broker si risolva in un indirizzo univoco e separa più listener con una virgola. Quindi invia nuovamente la configurazione corretta utilizzando. UpdateClusterConfiguration

Listener non legato al cluster

L'API restituisce un errore HTTP 400 con invalidParameter=configurationInfo il seguente messaggio.

Custom advertised listener(s) [CLIENT_SECURE] are not bound on this cluster. Valid client listeners: [CLIENT_IAM]. A broker cannot advertise a listener it does not bind.

Il listener che hai specificato non è attivo nel tuo cluster. Questo errore si verifica duranteUpdateClusterConfiguration, non duranteCreateConfiguration. Un broker può pubblicizzare solo un ascoltatore che effettivamente vincola. Aggiorna il tuo custom.advertised.listeners valore in modo che faccia riferimento a uno dei listener client validi elencati nel messaggio di errore per il tuo cluster (ad esempio,). CLIENT_IAM Se il listener non è ancora abilitato nel cluster (ad esempioCLIENT_SECURE), abilita prima l'autenticazione o il tipo di listener. Quindi riapplica la configurazione utilizzando. UpdateClusterConfiguration

Il processo di aggiornamento non riesce

Esamina il tuo custom.advertised.listeners valore per problemi quali conflitti di porte o nomi host irrisolvibili, correggi la configurazione e riapplicala utilizzando. UpdateClusterConfiguration

Se l'errore è seguito a un'operazione di ridimensionamento, aggiungete il listener Network Load Balancer, il gruppo di destinazione e il record DNS corrispondenti per ogni nuovo broker. Verifica che tutti i client siano in grado di risolvere il nome di dominio personalizzato. Puoi anche ripristinare la configurazione di lavoro precedente applicando la vecchia configurazione.