Bewährte Methoden zur Überwachung der Kafka-Gesundheit mit integrierten Befehlen

Kafkas integrierte Befehle sind der schnellste Weg, um grundlegende Fragen bei Vorfällen zu beantworten: Sind Partitionen geführt, sind Replikate synchron und hängen Verbraucher hinterher? Sie ersetzen nicht Prometheus, JMX oder eine verwaltete Überwachungsplattform, eignen sich aber hervorragend für schnelle Überprüfungen von einem Bastion-Host oder Admin-Container aus.

Die folgenden Beispiele verwenden --bootstrap-server, den aktuellen Client-Pfad für Kafka-Administrationsbefehle.

Eine saubere Befehlsumgebung einrichten

Halten Sie die Broker-Liste in einer Variablen, damit jeder Befehl wiederholbar ist:

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

Wenn Ihr Cluster TLS oder SASL verwendet, legen Sie die Client-Einstellungen in einer Eigenschaftendatei ab und übergeben Sie sie mit --command-config:

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

Thema- und Partitionsgesundheit überprüfen

Beginnen Sie mit kafka-topics.sh --describe. Ein gesundes Thema sollte für jede Partition einen Leader und eine In-Sync-Replica-Liste haben, die dem erwarteten Replikationsfaktor entspricht.

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

Achten Sie auf diese Felder:

• Leader: sollte nicht none sein.
• Replicas: die zugewiesenen Broker für die Partition.
• Isr: Replikate, die derzeit mit dem Leader synchron sind.

Wenn Replicas drei Broker hat, aber Isr nur einen, ist das Thema unter-repliziert. Das deutet normalerweise auf Broker-Ausfallzeiten, Festplattenbelastung, Netzwerkprobleme oder ein Replikat hin, das nicht mithalten kann.

Unter-replizierte Partitionen schnell finden

Verwenden Sie den integrierten Filter, wenn Sie eine schnelle clusterweite Überprüfung benötigen:

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

Keine Ausgabe ist eine gute Nachricht. Jede Ausgabe verdient eine Untersuchung, insbesondere bei Themen, die für eine stärkere Haltbarkeit mit min.insync.replicas konfiguriert sind.

Consumer-Lag überwachen

Consumer-Lag zeigt Ihnen, ob eine Verbrauchergruppe mit den produzierten Datensätzen Schritt hält.

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

Wichtige Spalten sind:

• CURRENT-OFFSET: wo die Gruppe ihren Fortschritt festgeschrieben hat.
• LOG-END-OFFSET: der neueste Offset in der Partition.
• LAG: die Differenz zwischen den beiden.
• CONSUMER-ID, HOST und CLIENT-ID: welcher Verbraucher die Partition besitzt.

Kurze Spitzen können während Bereitstellungen oder Verkehrsspitzen normal sein. Anhaltender Lag bedeutet, dass die Gruppe Aufmerksamkeit benötigt: langsame Verarbeitung, zu wenige Verbraucher, Partitionsungleichgewicht, Latenz bei nachgelagerten Abhängigkeiten oder Verzögerungen beim Abruf auf Brokerseite.

Aktive Verbrauchergruppen auflisten

Wenn Sie den Gruppennamen nicht kennen, listen Sie zuerst die Gruppen auf:

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

Überprüfen Sie dann die Gruppe, die der betroffenen Anwendung zugeordnet ist.

Broker-API-Erreichbarkeit überprüfen

kafka-broker-api-versions.sh ist eine einfache Möglichkeit, zu bestätigen, dass Ihr Client Broker erreichen und einen Metadaten-/API-Handshake abschließen kann.

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

Wenn dies fehlschlägt, überprüfen Sie DNS, Sicherheitsgruppen oder Firewalls, TLS/SASL-Einstellungen und ob die angekündigten Listener-Adressen von dem Ort aus erreichbar sind, an dem Sie den Befehl ausführen.

CLI-Überprüfungen während Vorfällen verwenden

Ein praktischer Triage-Ablauf sieht so aus:

1. Führen Sie kafka-broker-api-versions.sh aus, um die Konnektivität zu bestätigen.
2. Führen Sie kafka-topics.sh --describe --under-replicated-partitions aus, um die Replikationsgesundheit zu überprüfen.
3. Beschreiben Sie das betroffene Thema und überprüfen Sie Leader und ISR.
4. Beschreiben Sie die betroffene Verbrauchergruppe und überprüfen Sie den Lag pro Partition.
5. Vergleichen Sie die langsamen Partitionen mit Broker-, Festplatten- und Anwendungsprotokollen.

Fazit

Kafkas integrierte Befehle bieten Ihnen einen zuverlässigen ersten Blick auf die Cluster-Gesundheit. Halten Sie Admin-Client-Konfigurationen bereit, verwenden Sie --bootstrap-server und konzentrieren Sie sich auf Leader, ISR, unter-replizierte Partitionen und Consumer-Lag. Sobald die CLI zeigt, wo das Problem liegt, sind tiefere Broker-Metriken und Protokolle viel einfacher zu interpretieren.