Best Practices per il Monitoraggio della Salute di Kafka con Comandi Integrati

I comandi integrati di Kafka sono il modo più rapido per rispondere a domande di base durante gli incidenti: le partizioni hanno un leader, le repliche sono sincronizzate e i consumatori sono in ritardo? Non sostituiscono Prometheus, JMX o una piattaforma di monitoraggio gestita, ma sono eccellenti per controlli rapidi da un host bastione o da un container amministrativo.

Gli esempi seguenti utilizzano --bootstrap-server, che è il percorso client corrente per i comandi di amministrazione di Kafka.

Imposta un Ambiente di Comando Pulito

Mantieni la lista dei broker in una variabile in modo che ogni comando sia ripetibile:

export KAFKA_HOME=/opt/kafka
export BOOTSTRAP_SERVER="kafka1:9092,kafka2:9092,kafka3:9092"
cd "$KAFKA_HOME/bin"

Se il tuo cluster utilizza TLS o SASL, inserisci le impostazioni del client in un file delle proprietà e passalo con --command-config:

./kafka-topics.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --command-config /etc/kafka/admin-client.properties \
  --list

Verifica la Salute dei Topic e delle Partizioni

Inizia con kafka-topics.sh --describe. Un topic sano dovrebbe avere un leader per ogni partizione e una lista di repliche in sincronia che corrisponda al fattore di replica previsto.

./kafka-topics.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --describe \
  --topic orders

Cerca questi campi:

• Leader: non dovrebbe essere none.
• Replicas: i broker assegnati per la partizione.
• Isr: repliche attualmente in sincronia con il leader.

Se Replicas ha tre broker ma Isr ne ha solo uno, il topic è sotto-replicato. Di solito ciò indica un broker inattivo, pressione sul disco, problemi di rete o una replica che non riesce a tenere il passo.

Trova Rapidamente le Partizioni Sotto-Replicate

Utilizza il filtro integrato quando hai bisogno di un controllo rapido a livello di cluster:

./kafka-topics.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --describe \
  --under-replicated-partitions

Nessun output è una buona notizia. Qualsiasi output merita un'indagine, specialmente per i topic con min.insync.replicas configurato per una maggiore durabilità.

Monitora il Ritardo dei Consumatori

Il ritardo dei consumatori ti dice se un gruppo di consumatori sta tenendo il passo con i record prodotti.

./kafka-consumer-groups.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --describe \
  --group payments-worker

Le colonne importanti includono:

• CURRENT-OFFSET: dove il gruppo ha impegnato il progresso.
• LOG-END-OFFSET: l'ultimo offset nella partizione.
• LAG: la differenza tra i due.
• CONSUMER-ID, HOST e CLIENT-ID: quale consumatore possiede la partizione.

Picchi brevi possono essere normali durante deploy o picchi di traffico. Un ritardo sostenuto significa che il gruppo ha bisogno di attenzione: elaborazione lenta, troppi pochi consumatori, squilibrio delle partizioni, latenza delle dipendenze a valle o ritardi lato broker nel recupero.

Elenca i Gruppi di Consumatori Attivi

Quando non conosci il nome del gruppo, elenca prima i gruppi:

./kafka-consumer-groups.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --list

Poi ispeziona il gruppo che corrisponde all'applicazione interessata.

Verifica la Raggiungibilità dell'API del Broker

kafka-broker-api-versions.sh è un modo semplice per confermare che il tuo client può raggiungere i broker e completare una stretta di mano sui metadati/API.

./kafka-broker-api-versions.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER"

Se questo fallisce, controlla DNS, gruppi di sicurezza o firewall, impostazioni TLS/SASL e se gli indirizzi listener pubblicizzati sono raggiungibili da dove esegui il comando.

Utilizza i Controlli CLI Durante gli Incidenti

Un flusso di triage pratico è il seguente:

1. Esegui kafka-broker-api-versions.sh per confermare la connettività.
2. Esegui kafka-topics.sh --describe --under-replicated-partitions per verificare la salute della replica.
3. Descrivi il topic interessato e verifica leader e ISR.
4. Descrivi il gruppo di consumatori interessato e controlla il ritardo per partizione.
5. Confronta le partizioni lente con i log del broker, del disco e dell'applicazione.

Conclusione

I comandi integrati di Kafka ti offrono una prima occhiata affidabile alla salute del cluster. Tieni pronte le configurazioni del client amministrativo, usa --bootstrap-server e concentrati su leader, ISR, partizioni sotto-replicate e ritardo dei consumatori. Una volta che la CLI mostra dove si trova il problema, le metriche e i log più approfonditi del broker sono molto più facili da interpretare.