Apache Kafka Monitoring: Broker, Partitionen und Consumer Lag
Sehen Sie Consumer Lag pro Gruppe und Partition, den Zustand von Brokern und Replikation sowie die Services hinter jedem Topic. Obseria erfasst Kafka-Metriken per OpenTelemetry und verknüpft sie mit Traces.
Warum Apache Kafka mit Obseria überwachen
Consumer Lag mit Kontext
Lag pro Consumer Group, Topic und Partition, in TopoGraph mit dem konsumierenden Service verknüpft. So sehen Sie, wer zurückfällt und warum.
Replikation auf einen Blick
In-Sync-Replikas, unterreplizierte und Offline-Partitionen pro Broker zeigen Risiken, bevor ein Brokerausfall zu Datenverlust führt.
Nachrichten Ende-zu-Ende tracen
OpenTelemetry-Kontext in Kafka-Headern verbindet Producer- und Consumer-Spans. Ein langsamer Checkout zeigt das Topic, auf das er gewartet hat.
Kafka-Komponenten, die Obseria überwacht
- Broker. Anzahl der Broker, Request-Latenz und JMX-Metriken wie UnderReplicatedPartitions und ActiveControllerCount.
- Topics und Partitionen. Partitionen pro Topic, aktuelle und älteste Offsets, Replikas und In-Sync-Replikas pro Partition.
- Consumer Groups. Mitglieder, committete Offsets und Lag pro Gruppe, Topic und Partition sowie summiert pro Topic.
- Producer und Consumer. Client-Spans und -Metriken aus dem OpenTelemetry Java Agent und anderen SDKs mit Kafka-Instrumentierung.
- Kafka Connect und Streams. JVM- und JMX-Metriken von Connect-Workern und Streams-Anwendungen über den Obseria Agent oder Java Agent.
- Managed Kafka. Amazon MSK und andere Managed-Cluster über den kafka_metrics-Receiver und agentenlose Cloud-Integrationen.
Die Apache Kafka-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Rückstand bei der Verarbeitung
Zeigt, wie weit Ihre verarbeitenden Anwendungen hinter den eingehenden Daten liegen, ein direkter Hinweis auf verzögerte Bestellungen.
Aktivität der Verarbeitung
Zeigt, wie viele verarbeitende Instanzen aktiv sind und ob sie zügig durch die eingehenden Daten vorankommen.
Sicherheit der Daten
Macht sichtbar, ob alle Daten sicher auf mehrere Server kopiert sind, damit beim Ausfall eines Servers nichts verloren geht.
Cluster-Zustand und Wachstum
Zeigt, wie viele Server online sind, ob der Cluster sauber koordiniert wird und wie stark die Datenmenge wächst.
Alle 10 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
kafka.consumer_group.lag | 1 | Nachrichten, die eine Consumer Group auf einer Partition hinter dem neuesten Offset liegt. |
kafka.consumer_group.lag_sum | 1 | Gesamter Lag einer Consumer Group über alle Partitionen eines Topics. |
kafka.consumer_group.members | {members} | Aktive Mitglieder pro Gruppe; Einbrüche deuten auf Abstürze oder Rebalances. |
kafka.consumer_group.offset | 1 | Committeter Offset pro Partition; flach bei wachsendem Lag heißt: Consumer hängt. |
kafka.partition.current_offset | 1 | Neuester Offset pro Partition, Basis für den Producer-Durchsatz pro Topic. |
kafka.partition.replicas_in_sync | {replicas} | In-Sync-Replikas pro Partition; weniger als der Replikationsfaktor ist ein Risiko. |
kafka.brokers | {brokers} | Anzahl der Broker im Cluster aus Sicht des Clients. |
kafka.topic.partitions | {partitions} | Partitionen pro Topic, die die Parallelität der Consumer begrenzen. |
UnderReplicatedPartitions | {partitions} | JMX-Gauge (kafka.server:type=ReplicaManager) für Partitionen mit fehlenden Replikas; sollte 0 sein. |
ActiveControllerCount | 1 | JMX-Gauge (kafka.controller:type=KafkaController); genau ein Broker sollte 1 melden. |
Apache Kafka-Monitoring in wenigen Minuten einrichten
- Schritt 1
Collector mit den Brokern verbinden
Ergänzen Sie den kafka_metrics-Receiver mit Ihren Bootstrap-Brokern und aktivieren Sie die Scraper brokers, topics und consumers.
- Schritt 2
Broker-JMX-Metriken ergänzen
Installieren Sie den Obseria Agent auf den Broker-Hosts oder binden Sie den OpenTelemetry Java Agent ein, um JVM- und Kafka-JMX-Metriken zu erfassen.
- Schritt 3
Producer und Consumer instrumentieren
Nutzen Sie OpenTelemetry SDKs oder den Java Agent in Ihren Services, damit Spans den Trace-Kontext über Kafka-Header weitergeben.
receivers:
kafka_metrics:
cluster_alias: kafka-prod
brokers: ["kafka-0:9092", "kafka-1:9092", "kafka-2:9092"]
protocol_version: 3.0.0
scrapers: [brokers, topics, consumers]
collection_interval: 30s
exporters:
otlphttp:
endpoint: ${env:OBSERIA_OTLP_ENDPOINT}
headers:
Authorization: "Bearer ${env:OBSERIA_TOKEN}"
service:
pipelines:
metrics:
receivers: [kafka_metrics]
exporters: [otlphttp]
Sofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- Consumer Lag nach Gruppe, Topic und Partition
- Übersicht über Broker und Replikation
- Topic-Durchsatz aus Partition-Offsets
- Alert: Consumer Lag wächst seit 10 Minuten
- Alert: unterreplizierte oder Offline-Partitionen über 0
Apache Kafka-Monitoring: Darauf kommt es an
Warum Kafka Monitoring wichtig ist
Apache Kafka steht zwischen den Services, die Events erzeugen, und denen, die darauf reagieren. Läuft Kafka gesund, bemerkt es niemand. Verliert ein Broker seine Replikas oder fällt eine Consumer Group zurück, werden Bestellungen verspätet verarbeitet, Betrugsprüfungen verpassen ihr Zeitfenster und Dashboards zeigen veraltete Daten. Da Producer weiterhin erfolgreich schreiben, während Consumer hinterherhinken, zeigen sich diese Probleme selten als Fehler. Kafka Monitoring muss sie deshalb als Zahlen sichtbar machen: Lag, Replikationszustand und Durchsatz.
Obseria erfasst Kafka-Metriken mit dem OpenTelemetry Collector und dem Obseria Agent, verknüpft jede Consumer Group mit dem Service, der sie betreibt, und verfolgt Nachrichten per Trace vom Producer bis zum Consumer.
Die Kafka-Metriken, auf die es ankommt
Consumer Lag
Kafka Consumer Lag ist die Differenz zwischen dem neuesten Offset einer Partition und dem Offset, den eine Consumer Group committet hat. kafka.consumer_group.lag zeigt ihn pro Partition, kafka.consumer_group.lag_sum pro Topic. Der absolute Wert allein täuscht: 50.000 Nachrichten sind für einen Service Sekunden, für einen anderen Stunden Arbeit. Beobachten Sie den Trend und alarmieren Sie, wenn der Lag über mehrere Minuten stetig wächst.
Zustand von Brokern und Replikation
Jeder Broker stellt JMX-Metriken bereit. UnderReplicatedPartitions sollte auf jedem Broker 0 sein, OfflinePartitionsCount auf dem Controller ebenfalls, und genau ein Broker sollte ActiveControllerCount mit 1 melden. Aus Client-Sicht zeigt der Vergleich von kafka.partition.replicas_in_sync mit kafka.partition.replicas, welche Partitionen gefährdet sind.
Durchsatz und Partitionen
Die Rate von kafka.partition.current_offset ist die Schreibrate pro Partition. Ungleiche Raten innerhalb eines Topics deuten auf einen ungünstig verteilten Message Key. kafka.topic.partitions begrenzt, wie viele Consumer einer Gruppe parallel arbeiten können.
Typische Kafka-Probleme und wie Sie sie erkennen
- Hängender Consumer: Der committete Offset bleibt flach, während der Lag wächst. Häufig eine fehlerhafte Nachricht oder ein blockierter Downstream-Aufruf; der Consumer-Span im Trace zeigt, was es ist.
- Rebalance-Stürme:
kafka.consumer_group.membersändert sich ständig, und der Lag springt nach jeder Änderung. Typische Ursachen sind Verarbeitungszeiten übermax.poll.interval.msoder häufige Pod-Neustarts. - Hot Partitions: Eine Partition trägt den Großteil des Traffics, ihr Consumer hängt hinterher, während andere Leerlauf haben.
- Replikation hinkt hinterher: Unterreplizierte Partitionen, die sich nach einem Broker-Neustart nicht erholen, deuten auf Platten- oder Netzwerksättigung beim Follower.
- Retention-Überraschungen: Nähert sich der Lag dem ältesten Offset (
kafka.partition.oldest_offset), werden Nachrichten gelöscht, bevor sie konsumiert sind.
Best Practices für Kafka Monitoring
- Alarmieren Sie auf Lag-Wachstum und Aufholzeit, nicht auf einen festen Lag-Wert.
- Nutzen Sie für kritische Topics Replikationsfaktor 3 und
min.insync.replicas2 und alarmieren Sie, wenn die In-Sync-Replikas darunter fallen. - Überwachen Sie Clients ebenso wie Broker: Fehlerraten der Producer und Verarbeitungszeit der Consumer erklären den meisten Lag.
- Geben Sie den OpenTelemetry-Trace-Kontext in Message-Headern weiter, damit asynchrone Abläufe nachvollziehbar bleiben.
- Versehen Sie Metriken mit einem Cluster-Alias, damit mehrere Cluster in Dashboards getrennt bleiben.
So unterstützt Obseria Ihr Kafka Monitoring
Obseria führt Broker-, Topic- und Consumer-Metriken, JVM-Metriken und Client-Traces an einem Ort zusammen. TopoGraph zeigt, welche Services in welches Topic schreiben und daraus lesen, sodass ein Lag-Alert das zuständige Team nennt. Obseria Intelligence korreliert Lag mit Deployments, Consumer-Fehlern und Downstream-Latenz und erklärt die wahrscheinliche Ursache mit einer Beweiskette. Queue-Monitoring-Ansichten, Dashboards und Alerts sind enthalten, und Sie fragen alles mit OQL, PromQL oder SQL ab.
Ein praktischer Einstieg ist ein Collector pro Cluster mit dem kafka_metrics-Receiver sowie der Obseria Agent auf jedem Broker-Host für JMX- und Host-Metriken wie Plattenbelegung und Netzwerkdurchsatz. Stehen die Dashboards für Lag und Replikation, instrumentieren Sie die zwei oder drei kritischsten Producer- und Consumer-Services mit OpenTelemetry. Ab dann kommt jeder Lag-Alert mit den Traces der wartenden Nachrichten und der Deployment-Historie des konsumierenden Services. Das verkürzt den Weg vom Alert zur Behebung deutlich, gerade bei asynchronen Abläufen, die sich über mehrere Teams und Topics erstrecken.
Verwandte Integrationen
Passende Funktionen
Queue Monitoring
Behalten Sie Consumer Lag, Durchsatz und Nachrichtenalter über alle Broker und Topics im Blick und verfolgen Sie Nachrichten vom Producer bis zum Consumer.
Mehr erfahrenDistributed Tracing
Verfolgen Sie jeden Request über Services, Queues und Datenbanken hinweg und finden Sie den langsamen Span oder die fehlerhafte Abhängigkeit in Sekunden.
Mehr erfahrenAnomalie-Erkennung
Obseria Intelligence lernt den normalen Rhythmus jedes Service, meldet echte Abweichungen statt Schwellenwert-Rauschen und fasst zusammenhängende Anomalien zu einem Problem mit wahrscheinlicher Ursache zusammen.
Mehr erfahrenMehr erfahren
Die vier Golden Signals: Latenz, Traffic, Fehler und Sättigung
Die vier Golden Signals erklärt: Latenz, Traffic, Fehler und Sättigung, der Bezug zu RED- und USE-Methode und die Messung mit OpenTelemetry.
Was ist eine Root-Cause-Analyse (RCA)?
Was ist eine Root-Cause-Analyse? Der RCA-Prozess für Software-Incidents, 5 Whys, Fishbone und Fehlerbaum, ein Praxisbeispiel und RCA mit KI.
Häufige Fragen zum Apache Kafka-Monitoring
Der kafka_metrics-Receiver des OpenTelemetry Collectors liest die neuesten Partition-Offsets und die committeten Offsets jeder Consumer Group und meldet die Differenz als kafka.consumer_group.lag pro Partition und kafka.consumer_group.lag_sum pro Topic.
Consumer Lag und Partition-Metriken funktionieren ohne JMX. Für Broker-Interna wie UnderReplicatedPartitions oder Request-Latenz installieren Sie den Obseria Agent auf den Broker-Hosts oder binden den OpenTelemetry Java Agent ein.
Ja. Die OpenTelemetry-Instrumentierung für Kafka-Clients schreibt den Trace-Kontext in Message-Header, sodass Producer- und Consumer-Spans in Obseria im selben Trace erscheinen.
Ja. Richten Sie den kafka_metrics-Receiver mit TLS- oder SASL-Einstellungen auf die MSK-Bootstrap-Broker und nutzen Sie die agentenlose AWS-Integration für die Service-Metriken, die AWS veröffentlicht.
Beginnen Sie mit wachsendem Lag über 10 Minuten pro Consumer Group, unterreplizierten Partitionen über 0, Offline-Partitionen über 0 und einer aktiven Controller-Anzahl ungleich 1 im Cluster.
Starten Sie heute mit dem Apache Kafka-Monitoring
Binden Sie Apache Kafka in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.