Effektive Strategien zur Überwachung und Alarmierung der Kafka-Gesundheit

Kafka-Ausfälle sind im Nachhinein selten mysteriös. Ein Broker hat seine Festplatte gefüllt, eine Consumer-Gruppe ist zurückgefallen, ein Thema hat eine saubere Führung verloren, ein Controller begann zu flattern, oder ein Netzwerkpfad wurde so langsam, dass Clients auszeiteten. Die Schwierigkeit besteht darin, diese Signale frühzeitig zu erkennen, ohne Leute für jeden harmlosen Spike zu alarmieren.

Gutes Kafka-Monitoring beginnt mit einer kleinen Reihe von Gesundheitsfragen: Können Broker Anfragen bedienen, können Partitionen Leader wählen, sind Replikate auf dem neuesten Stand, verarbeiten Consumer schnell genug, und geht dem Cluster CPU, Arbeitsspeicher, Netzwerk oder Festplattenspeicher aus? Die folgenden Metriken sind nützlich, weil sie auf diese Fragen zurückzuführen sind.

Warum Kafka-Überwachung entscheidend ist

Kafkas verteilte Architektur führt mehrere potenzielle Fehlerquellen und Leistungseinbußen ein. Das Verständnis dieser potenziellen Probleme und deren Überwachung ist der Schlüssel zur Aufrechterhaltung eines gesunden Clusters:

Datenlatenz: Ein hoher Consumer-Lag kann darauf hindeuten, dass Consumer nicht mit der Produzentenrate Schritt halten, was zu veralteten Daten führt und nachgelagerte Anwendungen beeinträchtigt.
Ressourcennutzung: Unzureichende CPU, Arbeitsspeicher oder Festplattenspeicher auf Brokern können zu Leistungseinbußen, Reaktionsunfähigkeit oder sogar Broker-Abstürzen führen.
Partitionsungleichgewicht: Eine ungleichmäßige Verteilung von Partitionen über Broker kann dazu führen, dass einige Broker überlastet sind, während andere unterausgelastet sind, was Durchsatz und Verfügbarkeit beeinträchtigt.
Broker-Verfügbarkeit: Broker-Ausfälle können zu Datenunverfügbarkeit oder -verlust führen, wenn sie nicht ordnungsgemäß behandelt werden. Die Überwachung der Broker-Gesundheit ist für die Fehlertoleranz von größter Bedeutung.
Netzwerkprobleme: Netzwerkpartitionen oder hohe Latenz zwischen Brokern oder zwischen Clients und Brokern können die Clusterleistung und -stabilität erheblich beeinträchtigen.

Wichtige Kafka-Metriken zur Überwachung

Effektives Monitoring basiert auf der Verfolgung der richtigen Metriken. Diese können grob in Metriken auf Broker-Ebene, Themen-Ebene und Client-Ebene kategorisiert werden.

Metriken auf Broker-Ebene

Diese Metriken geben Einblicke in die Gesundheit und Leistung einzelner Kafka-Broker.

Anfragemetriken:
- kafka.network.RequestMetrics.RequestsPerSec (Rate eingehender Anfragen)
- kafka.network.RequestMetrics.TotalTimeMs (Gesamtzeit für die Verarbeitung von Anfragen)
- kafka.network.RequestMetrics.ResponseQueueTimeMs (Zeit in der Antwortwarteschlange)
- kafka.network.RequestMetrics.LocalTimeMs (Zeit auf dem Broker verbracht)
- kafka.network.RequestMetrics.RemoteTimeMs (Zeit für die Kommunikation mit anderen Brokern)
- kafka.network.RequestMetrics.TotalBytesInPerSec & TotalBytesOutPerSec (Netzwerkdurchsatz)
Protokollmetriken:
- kafka.log.Log.Size (Größe der Protokollsegmente auf der Festplatte)
- kafka.log.Log.N.MessagesPerSec (Rate der Nachrichten, die in ein Protokollsegment geschrieben werden)
- kafka.log.Log.N.BytesPerSec (Byte-Rate, die in ein Protokollsegment geschrieben wird)
- kafka.log.Log.N.LogFlushStats.LogFlushRateAndTimeMs (Rate und Zeit für das Leeren von Protokollsegmenten)
Controller-Metriken: (Wichtig für Leader-Wahl und Partitionsverwaltung)
- kafka.controller.Controller.ControllerStateChangesPerSec
- kafka.controller.Controller.LeaderChangesPerSec
JVM-Metriken: (Wesentlich für das Verständnis der Broker-Ressourcennutzung)
- kafka.server:type=jvm,name=HeapMemoryUsage
- kafka.server:type=jvm,name=NonHeapMemoryUsage
- kafka.server:type=jvm,name=GarbageCollection
- kafka.server:type=jvm,name=Threads

Metriken auf Themen-Ebene

Diese Metriken konzentrieren sich auf die Leistung und Gesundheit bestimmter Kafka-Themen.

Unterreplizierte Partitionen:
- kafka.cluster.PartitionReplicaCount.UnderReplicatedPartitions (Anzahl der Partitionen mit weniger Replikaten als gewünscht)
- Die Alarmierung zu dieser Metrik ist entscheidend für Datenhaltbarkeit und -verfügbarkeit.
Offline-Partitionen:
- kafka.cluster.PartitionState.OfflinePartitionsCount (Anzahl der nicht verfügbaren Partitionen)
- Eine hohe Anzahl weist auf ein ernstes Problem mit der Partitionsführung oder Broker-Verfügbarkeit hin.
Leader-Wahl-Rate:
- kafka.controller.Controller.LeaderChangesPerSec (Rate der Leader-Neuwahlen)
- Ein Spike kann auf Instabilität oder Broker-Ausfälle hindeuten.

Metriken der Consumer-Gruppe

Diese Metriken sind entscheidend für das Verständnis des Consumer-Lags und der Verarbeitungsgeschwindigkeit Ihrer Anwendungen.

Consumer-Lag: Dies ist oft keine direkte Kafka-Metrik, sondern wird durch den Vergleich des neuesten Offsets, der für ein Thema produziert wurde, mit dem neuesten Offset, der von einer Gruppe konsumiert wurde, berechnet. Überwachungstools bieten diese Berechnung normalerweise an.
- Kritischer Alarm: Ein hoher Consumer-Lag (z. B. Überschreiten eines definierten Schwellenwerts für einen längeren Zeitraum) zeigt an, dass Consumer zurückfallen.
Fetch-Anfragemetriken (aus Sicht des Consumers):
- kafka.consumer.Fetcher.MaxLag
- kafka.consumer.Fetcher.MinFetchWaitMs
- kafka.consumer.Fetcher.MaxFetchWaitMs

Implementierung von Überwachungslösungen

Mehrere Tools und Ansätze können zur Überwachung von Kafka verwendet werden. Die Wahl hängt oft von Ihrer vorhandenen Infrastruktur und Ihren betrieblichen Anforderungen ab.

JMX und Prometheus

Kafka-Broker stellen über JMX (Java Management Extensions) eine Fülle von Metriken bereit. Tools wie Prometheus können diese JMX-Metriken mit einem Adapter wie jmx_exporter abrufen.

JMX aktivieren: Kafka hat JMX normalerweise standardmäßig aktiviert. Stellen Sie sicher, dass der JMX-Port zugänglich ist.
jmx_exporter konfigurieren: Laden Sie jmx_exporter herunter und konfigurieren Sie es, um Kafka-JMX-Metriken in einem Prometheus-kompatiblen Format bereitzustellen. Sie benötigen eine Konfigurations-YAML-Datei, die angibt, welche MBeans abgerufen werden sollen. Beispiel jmx_exporter Konfigurationsausschnitt für Kafka JMX: jmx_exporter/example_configs/kafka-2-0-0.yml (oft im jmx_exporter-Repository zu finden)
Prometheus konfigurieren: Fügen Sie ein Ziel in Ihrer Prometheus-Konfiguration hinzu, um den von jmx_exporter bereitgestellten Endpunkt abzurufen, der neben Ihren Kafka-Brokern läuft.
```
scrape_configs:
  - job_name: 'kafka'
    static_configs:
      - targets: ['<kafka-broker-ip>:9404'] # Standardport für jmx_exporter
```
Mit Grafana visualisieren: Verwenden Sie Grafana, um Dashboards zu erstellen, die diese Prometheus-Metriken anzeigen. Vorgefertigte Kafka-Dashboards sind auf Grafana Labs verfügbar.

Kafka-spezifische Überwachungstools

Kafka Manager (ehemals Yahoo Kafka Manager): Ein beliebtes webbasiertes Tool zur Verwaltung von Kafka-Clustern. Es bietet Broker-Status, Themeninspektion, Consumer-Lag-Überwachung und Partitionsverwaltung.
CMAK (Cluster Manager for Apache Kafka): Ein Fork des Kafka Managers, aktiv gewartet und bietet ähnliche Funktionen.
Lenses.io / Confluent Control Center: Kommerzielle Angebote, die erweiterte Kafka-Überwachung, -Verwaltung und Datenvisualisierungsfunktionen bieten.
Open-Source-Kafka-Überwachungsstapel: Kombinationen wie ELK-Stack (Elasticsearch, Logstash, Kibana) mit Kafka-Protokollen oder TICK-Stack (Telegraf, InfluxDB, Chronograf, Kapacitor) für Zeitreihendaten.

Einrichtung effektiver Alarmierung

Sobald Metriken gesammelt werden, besteht der nächste Schritt darin, Alarme für kritische Bedingungen zu konfigurieren. Ihre Alarmierungsstrategie sollte sich auf Probleme konzentrieren, die sich direkt auf die Anwendungsverfügbarkeit, Datenintegrität oder Leistung auswirken.

Zu konfigurierende kritische Alarme:

Unterreplizierte Partitionen > 0: Dies ist ein Alarm mit hoher Priorität, der auf potenziellen Datenverlust oder -unverfügbarkeit hinweist. Eine sofortige Untersuchung ist erforderlich.
Anzahl Offline-Partitionen > 0: Ähnlich wie unterreplizierte Partitionen bedeutet dies Partitionen, die vollständig nicht verfügbar sind.
Hoher Consumer-Lag: Definieren Sie einen Schwellenwert basierend auf der Toleranz Ihrer Anwendung für veraltete Daten. Alarmieren Sie, wenn der Lag diesen Schwellenwert für eine bestimmte Dauer (z. B. 5 Minuten) überschreitet. PromQL-Beispiel (konzeptionell für Prometheus/Grafana):
```
avg_over_time(kafka_consumergroup_lag_max{group="your-consumer-group"}[5m]) > 1000
```
Hinweis: Der genaue Metrikname und die Berechnung des Lags hängen von Ihrem Überwachungssetup ab (z. B. Verwendung von Kafkas eigenen Metriken, kafka-exporter oder clientseitigen Metriken).
Broker-CPU/Arbeitsspeicher/Festplattennutzung: Alarmieren Sie, wenn die Auslastung vordefinierte Schwellenwerte überschreitet (z. B. 80 % für CPU/Arbeitsspeicher, 90 % für Festplatte). Festplattenspeicher ist besonders kritisch für Kafka.
Hohe Anforderungslatenz: Alarmieren Sie bei anhaltenden Anstiegen von RequestMetrics.TotalTimeMs oder bestimmten Anforderungstypen (z. B. Produzieren, Abrufen).
Broker-Neustart/Nichtverfügbarkeit: Richten Sie Alarme ein, wenn ein Kafka-Broker nicht mehr erreichbar ist oder keine Metriken mehr meldet.
Spitzen bei der Leader-Wahl-Rate: Alarmieren Sie bei ungewöhnlich hohen Raten von Leader-Wahlen, was auf Instabilität hindeuten kann.

Integration von Alarmierungstools

Ihr Prometheus-Setup kann mit Alarmierungsmanagern wie Alertmanager integriert werden. Alertmanager kümmert sich um Deduplizierung, Gruppierung und Weiterleitung von Alarmen an verschiedene Benachrichtigungskanäle wie E-Mail, Slack, PagerDuty usw.

Alertmanager-Konfigurationsbeispiel (alertmanager.yml):

route:
  group_by: ['alertname', 'cluster', 'service']
  receiver: 'default-receiver'
  routes:
    - receiver: 'critical-ops'
      match_re:
        severity: 'critical'
      continue: true

receivers:
  - name: 'default-receiver'
    slack_configs:
      - channel: '#kafka-alerts'

  - name: 'critical-ops'
    slack_configs:
      - channel: '#kafka-critical'
    pagerduty_configs:
      - service_key: '<your-pagerduty-key>'

Best Practices für Kafka-Überwachung und -Alarmierung

Baselines festlegen: Verstehen Sie das normale Betriebsverhalten Ihres Kafka-Clusters. Dies hilft bei der Festlegung sinnvoller Alarmschwellen und der Identifizierung von Anomalien.
Alarme staffeln: Unterscheiden Sie zwischen kritischen Alarmen, die sofortiges Handeln erfordern, und informativen Alarmen, die überprüft werden müssen, aber keine Notfallreaktion erfordern.
Aktionen automatisieren: Erwägen Sie für häufige Probleme (z. B. Festplattenwarnungen) die Automatisierung von Korrekturmaßnahmen, wo dies sicher ist.
Die Metadatenebene überwachen: Ältere Kafka-Cluster sind häufig auf ZooKeeper angewiesen, während neuere Bereitstellungen den KRaft-Modus verwenden können. Überwachen Sie das Metadaten-Quorum, das Ihr Cluster tatsächlich verwendet.
Netzwerk überwachen: Stellen Sie sicher, dass Netzwerkkonnektivität und Latenz zwischen Brokern und Clients innerhalb akzeptabler Grenzen liegen.
Dashboards regelmäßig überprüfen: Verlassen Sie sich nicht nur auf Alarme. Überprüfen Sie regelmäßig Ihre Überwachungs-Dashboards, um Trends und potenzielle Probleme zu erkennen, bevor sie Alarme auslösen.
Alarme testen: Testen Sie Ihr Alarmsystem regelmäßig, um sicherzustellen, dass Benachrichtigungen korrekt gesendet werden und die richtigen Personen erreichen.

Alarmieren Sie bei Symptomen, auf die Leser reagieren können

Kafka stellt viele Metriken bereit, und es ist einfach, ein Dashboard zu erstellen, das beeindruckend aussieht, aber bei einem Vorfall nicht hilft. Beginnen Sie mit Alarmen, die eine klare Bedieneraktion haben.

UnderReplicatedPartitions > 0 ist umsetzbar, weil es bedeutet, dass mindestens eine Partition weniger synchronisierte Replikate als erwartet hat. Die erste Überprüfung ist die Broker-Gesundheit, dann Festplatte, Netzwerk und Replikat-Fetcher-Lag. Wenn es sich während eines rollierenden Neustarts schnell auflöst, kann es erwartet werden. Wenn es ungleich Null bleibt, behandeln Sie es als Haltbarkeits- und Verfügbarkeitsrisiko.

OfflinePartitionsCount > 0 ist dringender. Eine Partition ohne aktiven Leader kann keinen normalen Produktions- oder Abrufverkehr bedienen. Dieser Alarm sollte den Cluster- und Broker-Kontext enthalten und für Produktionscluster eine Seite auslösen.

Consumer-Lag ist wichtig, aber erfordert Nuancen. Ein Lag von 10.000 Datensätzen kann für ein nachrangiges nächtliches Batch-Thema harmlos und für eine Betrugserkennungspipeline schwerwiegend sein. Alarmieren Sie auf Lag relativ zum Zweck der Consumer-Gruppe: anhaltender Lag, Lag, der schneller zunimmt, als Consumer sich erholen können, oder geschätzte Zeit im Rückstand, wenn Ihre Tooling dies berechnen kann.

Festplattenalarme sollten ausgelöst werden, bevor Kafka keinen Platz zum Schreiben hat. Kafka-Broker sind von Natur aus festplattenintensive Systeme, und volle Festplatten können kaskadierende Probleme verursachen. Kombinieren Sie Festplattennutzungswarnungen mit dem Kontext des Protokollverzeichnisses, damit die Person im Bereitschaftsdienst sehen kann, ob das Problem ein Broker, ein Mount oder eine Aufbewahrungsrichtlinie im gesamten Cluster ist.

Ein praktisches Dashboard-Layout

Ein nützliches Kafka-Dashboard hat normalerweise Ebenen. Die oberste Reihe sollte beantworten, ob der Cluster Datenverkehr bedient: Broker-Anzahl, Offline-Partitionen, unterreplizierte Partitionen, Controller-Änderungen, Anforderungslatenz und Produktions-/Abruffehlerraten.

Die nächste Reihe sollte Durchsatz und Druck anzeigen: Bytes rein, Bytes raus, Produktionsanfragen, Abrufanfragen, Netzwerkprozessor-Leerlauf, Anforderungshandler-Leerlauf, CPU, Arbeitsspeicher, Festplattennutzung und Festplatten-E/A. Diese Panels helfen Ihnen zu sehen, ob ein Latenzspike mit einer echten Ressourcenbeschränkung übereinstimmt.

Die dritte Reihe sollte sich auf die Replikation konzentrieren: Replikat-Fetcher-Lag, In-Sync-Replica-Shrink/Expand-Ereignisse, Leader-Wahl-Rate und Partitionsverteilung nach Broker. Wenn ein Broker weitaus mehr Leader oder heiße Partitionen als die anderen hat, kann der Cluster insgesamt gesund aussehen, während ein Knoten überlastet ist.

Die vierte Reihe sollte sich auf Consumer konzentrieren: Lag nach Gruppe und Thema, verbrauchte Datensätze pro Sekunde, Rebalance-Rate, sofern verfügbar, und Consumer-Fehlermetriken aus der Anwendungsinstrumentierung. Broker-Metriken können Ihnen nicht sagen, ob ein Consumer in einem langsamen Datenbankschreibvorgang steckt, nachdem er Nachrichten abgerufen hat.

Wo Befehlszeilenprüfungen immer noch helfen

Selbst mit Dashboards sind Kafka-Befehlszeilentools nützlich, um zu bestätigen, was der Cluster glaubt.

Überprüfen Sie den Partitionsstatus des Themas:

kafka-topics.sh --bootstrap-server broker1:9092 --describe --topic orders

Suchen Sie nach Partitionen mit fehlenden Leadern, Replikaten, die nicht im ISR sind, oder ungleichmäßiger Leader-Platzierung.

Überprüfen Sie den Consumer-Lag:

kafka-consumer-groups.sh \
  --bootstrap-server broker1:9092 \
  --describe \
  --group billing-worker

Die Ausgabe hilft Ihnen, zwischen "die gesamte Gruppe ist zurück" und "eine Partition steckt fest" zu unterscheiden. Eine feststeckende Partition deutet oft auf eine Giftnachricht, einen heißen Schlüssel oder eine einzelne, nicht gesunde Consumer-Instanz hin.

Überprüfen Sie die Broker-API-Versionen, wenn sich Clients seltsam verhalten:

kafka-broker-api-versions.sh --bootstrap-server broker1:9092

Versionskonflikte sind nicht die häufigste Ursache für Gesundheitsvorfälle, können aber das Client-Verhalten nach Upgrades oder gemischten Version-Rollouts erklären.

Vermeidung von lauten Kafka-Alarmen

Laute Alarme entstehen normalerweise durch Schwellenwerte, die von einem anderen Cluster kopiert wurden. Kafka-Workloads variieren zu stark für universelle Zahlen. Ein Zahlungsstrom, ein Metriken-Feuerhahn und ein Batch-Import-Thema haben unterschiedliche Latenztoleranz, Durchsatz, Partitionsanzahl und Aufbewahrungserwartungen.

Verwenden Sie anhaltende Fenster für Alarme, die natürlich ansteigen können. Beispielsweise muss der Consumer-Lag möglicherweise mehrere Minuten über dem Schwellenwert bleiben, bevor eine Seite ausgelöst wird. Unterreplizierte Partitionen in der Produktion verdienen möglicherweise ein kürzeres Fenster. Broker-Aus-Alarme sollten geplante Wartungsarbeiten berücksichtigen, aber sie sollten nicht so aggressiv versteckt werden, dass echte Ausfälle unbemerkt bleiben.

Jede Seite sollte einen wahrscheinlichen Besitzer haben. "Broker-Festplatte voll" gehört zum Plattform- oder Betriebsteam. Consumer-Lag für billing-worker kann zum Anwendungsteam gehören. Wenn alle Kafka-Alarme ohne Besitzer an einen Kanal weitergeleitet werden, werden die Leute lernen, sie zu ignorieren.

Metadatenebene und Versionsnuancen

Viele bestehende Kafka-Cluster verwenden immer noch ZooKeeper, und diese Cluster benötigen ZooKeeper-Überwachung: Quorum-Gesundheit, Latenz, Festplatte, JVM-Gesundheit und Verbindungsanzahl. Kafka-Cluster, die den KRaft-Modus verwenden, benötigen stattdessen eine Überwachung des Controller-Quorums. Die betriebliche Idee ist dieselbe: Wenn die Metadatenebene nicht gesund ist, kann sich die Broker-Gesundheit auf eine Weise verschlechtern, die zunächst nicht zusammenhängend erscheint.

Seien Sie vorsichtig mit alten Anleitungen, die besagen, dass jeder Kafka-Cluster auf ZooKeeper angewiesen ist. Das war viele Jahre lang wahr, aber neuere Kafka-Bereitstellungen verwenden es möglicherweise nicht. Ihr Runbook sollte zu dem Cluster passen, den Sie tatsächlich betreiben.

Runbooks sind wichtiger als perfekte Dashboards

Ein Alarm ohne Runbook lässt die Bereitschaftsperson raten. Schreiben Sie für jeden kritischen Alarm die ersten Überprüfungen, die häufigsten Ursachen und den Eskalationspfad auf. Für unterreplizierte Partitionen könnte das Runbook sagen: Überprüfen Sie die Broker-Erreichbarkeit, überprüfen Sie die Festplattennutzung, überprüfen Sie Netzwerkfehler, überprüfen Sie kürzliche Bereitstellungen oder Neustarts, identifizieren Sie betroffene Themen und entscheiden Sie, ob die Wartung pausiert werden soll.

Für Consumer-Lag könnte das Runbook sagen: Identifizieren Sie, ob der Lag alle Partitionen oder eine Partition betrifft, überprüfen Sie die Gesundheit der Consumer-Bereitstellung, überprüfen Sie kürzliche Anwendungsfehler, überprüfen Sie nachgelagerte Abhängigkeiten und suchen Sie nach Rebalances. Wenn eine einzelne Partition steckt, finden Sie den aktuellen Offset und überprüfen Sie die Nachricht sicher mit internem Tooling, anstatt blind Offsets zu überspringen.

Gutes Monitoring beseitigt keine Vorfälle. Es macht die ersten Entscheidungen schneller und weniger emotional.

Die Kafka-Gesundheitsüberwachung funktioniert, wenn jede Metrik mit einer betrieblichen Frage verbunden ist. Sind Partitionen verfügbar? Sind Replikate auf dem neuesten Stand? Halten Consumer Schritt? Gehen Brokern die Ressourcen aus? Sind Controller oder Metadaten-Dienste stabil? Bauen Sie Dashboards und Alarme um diese Fragen herum auf und halten Sie dann die Schwellenwerte an Ihren eigenen Workload gebunden, anstatt an die Standardwerte anderer.