Datensysteme
    Aktualisiert am Mai 2026
    Apache Kafka logo

    Apache Kafka Überwachung

    Überwachen Sie den Zustand von Apache Kafka-Brokern, Partitionsverzögerungen, Verbrauchergruppen und den Durchsatz in Echtzeit – ganz ohne Konfiguration.

    Kostenlose Testversion startenDokumente anzeigen

    Warum überwachen Sie Apache Kafka?

    Apache Kafka ist das Rückgrat von Echtzeit-Datenpipelines und Event-Streaming. Die Überwachung von Kafka gewährleistet den einwandfreien Betrieb der Broker-Cluster, minimale Verzögerungen bei den Konsumenten, eine optimale Partitionsverteilung und eine zuverlässige Nachrichtenübermittlung.

    Automatische Erkennung über Xitogent
    Broker-Zustand und ISR-Verfolgung
    Überwachung des Consumer-Group-Lags
    Metriken zur Partitionsverteilung
    Nachrichten-Durchsatzraten
    Festplattennutzung pro Broker
    Metriken auf Topic-Ebene
    1-Minuten-Erfassungsintervalle
    Anpassbare Alarmschwellen für jede Metrik
    Metrikerfassung im 1-Minuten-Takt out of the box
    Was ist Kafka-Monitoring?

    Kafka-Monitoring, erklärt

    Kafka-Monitoring erfasst unterreplizierte Partitionen, Offline-Partitionen, Consumer-Group-Lag-Spitzen, ISR-Shrinks, Controller-Ausfälle und Disk-Druck, bevor sie Datenverlust, Fehler nachgelagerter Microservices oder komplette Broker-Ausfälle verursachen. Für CDC-Pipelines, Event-Sourcing-Systeme, Microservice-Eventing und jeden produktiven Kafka-Cluster ist die Sichtbarkeit pro Broker + pro Consumer-Group das, was einen 60-Sekunden-Alarm auf einen nachlaufenden Consumer von dem Fund eines 50-Millionen-Nachrichten-Backlogs am Ende des Tages unterscheidet. Xitoring erkennt Ihre Broker automatisch, liest JMX MBeans + Consumer-Offsets und leitet Alarme an Slack, PagerDuty, Telegram oder Ihre bestehende Rufbereitschaft.

    Kennzahlen

    Was wir überwachen

    Anzahl Broker

    Aktive Broker im Cluster.

    Consumer-Lag

    Nachrichten-Rückstand je Consumer-Group.

    Nachrichten ein/Sek.

    Nachrichten-Eingangsrate.

    Ein-/Ausgangsbytes

    Netzwerkdurchsatz pro Broker.

    Unter-replizierte Partitionen

    Partitionen unterhalb des Replikationsfaktors.

    ISR-Schrumpfungen

    Schrumpfungsereignisse von In-Sync-Replicas.

    UncleanLeaderElectionsPerSec

    Rate, mit der nicht synchrone Replicas zum Leader befördert werden (mit Datenverlust). Sollte 0 sein — ungleich null bedeutet `unclean.leader.election.enable=true` UND ein tatsächlicher Fehlerfall ist eingetreten.

    MessagesInPerSec / BytesIn / BytesOut

    Durchsatz pro Broker und pro Topic. Plötzliche Rückgänge bei stabiler Producer-Anzahl = Ingest-Problem; plötzliche Spitzen = Retry-Sturm oder ausufernder Producer.

    Request-Latenz (p99)

    p99 der Produce-, Fetch-, Metadata-Request-Handler-Zeit aus `kafka.network:type=RequestMetrics`. Erkennt Broker-Überlast, bevor sie Timeouts auf Client-Seite verursacht.

    LeaderCount pro Broker

    Partition-Leader pro Broker. Ungleiche Verteilung (ein Broker hält 60 %+ der Leader) = unausgeglichener Cluster, beheben mit `kafka-reassign-partitions.sh` oder.

    Log-Größe pro Topic

    Aggregierte On-Disk-Log-Größe pro Topic aus `kafka.log:type=Log,name=Size`. Treibt Disk-Space-Alarme und informiert Tiered-Storage-Policies in Kafka 3.8+.

    RemoteLogManager (Tiered Storage)

    Kafka-3.8+-Tiered-Storage-Metriken: in den Remote-Tier hochgeladene Bytes, Segmente in Remote vs. lokal, Fetch-Latenz aus Remote. Erkennt S3-Konnektivitäts-/IAM-Probleme, die Tiered-Fetches brechen.

    Auslöser & Benachrichtigungen

    Konfigurierbare Alarmauslöser

    Richten Sie benutzerdefinierte Trigger in Ihrem Dashboard ein, um benachrichtigt zu werden, sobald die Kennzahlen von „Apache Kafka“ Ihre festgelegten Schwellenwerte überschreiten.

    Apache Kafka Dashboard zur Konfiguration von Überwachungsauslösern

    Consumer-Lag

    entscheidend

    Wird ausgelöst, wenn ein Consumer zurückfällt.

    Unter-replizierte Partitionen

    entscheidend

    Warnungen bei Replikationsproblemen.

    Broker ausgefallen

    entscheidend

    Wird ausgelöst, wenn ein Broker den Cluster verlässt.

    Festplattenbelegung

    Warnung

    Wird ausgelöst, wenn die Broker-Festplatte volläuft.

    01

    Bedeutung von Kafka-Überwachung

    Kafka verarbeitet täglich Billionen von Nachrichten. Consumer-Lag, Broker-Ausfälle und Partitions-Ungleichgewicht können Datenpipelines zum Ausfall bringen.

    • Consumer-Lag vor Datenverlust erkennen
    • ISR zur Sicherung der Datenhaltbarkeit überwachen
    • Broker-Zustand über Cluster hinweg verfolgen
    • Partitionsbalance sicherstellen
    Kafka-Überwachung
    Partitionsanalyse
    02

    Warum entscheiden Sie sich für Xitoring

    Kafka-Überwachung auf Enterprise-Niveau.

    • Zero-Config-Setup
    • Globale Knoten
    • Zentrales Dashboard
    • Benachrichtigungen über mehrere Kanäle
    • Aufbewahrungsfristen
    Übersicht
    Benachrichtigungen
    Anwendungsfälle

    Häufige Kafka-Monitoring- Szenarien

    Wo Kafka heute typischerweise läuft – und was schiefgehen könnte, wenn niemand aufpasst.

    Das Messaging-Backbone, das Ihre Apps verbindet

    Wenn Kafka die Nachrichten transportiert, die Daten zwischen Ihren Apps bewegen, bedeutet jede Verlangsamung, dass eine App im Stillen zurückfällt – und die Folgen (verzögerte Updates, veraltete Daten, unterbrochene Workflows) zeigen sich erst später. Wir erkennen die Verzögerung in dem Moment, in dem sie beginnt, damit sie niemals zu einem für Kunden sichtbaren Problem wird.

    Kafka läuft in Kubernetes

    Wenn Kafka in Kubernetes läuft, verschiebt die Plattform es ständig – und ein routinemäßiger Neustart kann das Sicherheitsnetz, das Ihre Daten schützt, kurzzeitig schwächen. Wir überwachen jeden Neustart und jede Neuausrichtung, damit ein normales Update das System nicht unbemerkt einen Fehler von Datenverlust entfernt zurücklassen kann.

    Selbstverwaltetes Kafka für große Datenmengen

    Unternehmen, die ihr eigenes Kafka in großem Maßstab betreiben, benötigen es felsenfest – es transportiert normalerweise die wertvollsten Daten, die sie haben. Wir überwachen die Signale, die es gesund halten, damit das Team sich auf die Entwicklung von Produkten konzentrieren kann, anstatt die Messaging-Schicht zu bekämpfen.

    Bevor Sie beginnen

    Voraussetzungen für Apache Kafka

    Stellen Sie sicher, dass diese Punkte erfüllt sind — danach ist die Installation eine Sache von 60 Sekunden.

    • Kafka-Broker mit aktiviertem JMX (Standardport 9999)
    • Netzwerkerreichbarkeit von Xitogent zu jedem JMX-Port der Broker
    • JMX-Authentifizierungsanmeldedaten, falls Security konfiguriert ist
    Einrichtungsanleitung

    Erste Schritte in Minuten

    1

    Xitogent auf jedem Broker installieren

    Installieren Sie den ressourcenschonenden Xitogent-Monitoring-Agenten auf jedem Kafka-Broker, den Sie überwachen möchten.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    JMX auf jedem Broker aktivieren

    Kafka stellt Broker-Metriken über JMX bereit. Setzen Sie `KAFKA_JMX_OPTS`, um einen JMX-Listener (typischerweise Port 9999) auf jedem Broker zu aktivieren, laden Sie den Dienst neu und prüfen Sie, dass der Agent-Host den JMX-Port erreichen kann.

    sudo xitogent integrate
    3

    Kafka-Integration aktivieren

    Aktivieren Sie die Kafka-Integration über das Xitoring-Dashboard oder die CLI. Xitogent erkennt Broker-IDs, Topics und Consumer-Groups im Cluster automatisch.

    4

    Alarmschwellen konfigurieren (optional)

    Legen Sie eigene Schwellenwerte für Consumer-Lag, unterrepublizierte Partitionen oder Broker-Down-Ereignisse fest, um Replikationsprobleme und Rückstau zu erkennen, bevor Consumer zurückfallen.

    5

    Funktion überprüfen

    Führen Sie diesen Befehl auf dem Server aus, um zu bestätigen, dass Xitogent die Integration erkannt hat. Innerhalb von etwa 30 Sekunden werden frische Metriken in Ihr Dashboard gestreamt.

    sudo xitogent status
    Vergleichen

    Erwägen Sie Alternativen?

    Sehen Sie, wie sich Xitoring gegen die Alternativen für Apache Kafka-Monitoring schlägt — Pauschalpreise, tiefere Integrationen und ein Agent, der Ihren gesamten Stack abdeckt.

    Alle Vergleiche ansehen

    Häufig gestellte Fragen

    Kafka-Versionen?
    Kafka 2.x und 3.x werden unterstützt.
    ZooKeeper oder KRaft?
    Beide Modi werden unterstützt.
    Was sind unterreplizierte Partitionen und wie behebe ich sie?
    Unterreplizierte Partitionen haben weniger ISRs (In-Sync-Replicas) als der Replikationsfaktor — meist weil ein Broker tot, hinterher oder im Neustart ist. Führen Sie `kafka-topics.sh --describe --under-replicated-partitions` aus, um sie aufzulisten. Beheben Sie den zugrunde liegenden Broker, dann holen die ISR automatisch auf. Wenn ein Broker dauerhaft verloren ist, verwenden Sie `kafka-reassign-partitions.sh`, um Replicas auf überlebende Broker zu verschieben. Anhaltende UnderReplicatedPartitions > 0 = Rufbereitschaft alarmieren.
    Wie überwache ich Kafka-Broker-JMX-Metriken mit Prometheus?
    Standardmuster: Deployen Sie prometheus als JVM-Java-Agent in jedem Broker (`-javaagent:jmx_prometheus_javaagent.jar=8080:kafka-config.yml`), Prometheus scrapt den `/metrics`-Endpunkt des Exporters. Die `kafka-config.yml` whitelistet das MBean → Metrik-Mapping. Xitogent liest JMX direkt ohne Exporter, ist aber kompatibel mit Umgebungen, die bereits für Grafana-Dashboards betrieben werden.
    Was ist der KRaft-Modus und wie ändert sich das Monitoring ohne ZooKeeper?
    KRaft (Kafka Raft) ersetzt ZooKeeper durch ein internes Raft-basiertes Controller-Quorum (Standard seit Kafka 3.3, einzige Option in 4.0). Monitoring ändert sich: keine ZK-Ensemble-Metriken, stattdessen beobachten Sie das Controller-Quorum (3 oder 5 Broker laufen als Controller), `kafka.controller:type=KafkaController` MBeans und `kafka.server:type=raft-metrics`. Die Semantik von `ActiveControllerCount` ist dieselbe (sollte genau 1 aktiver Leader sein).
    Wie erkenne ich Kafka-Offline-Partitionen?
    `kafka.controller:type=KafkaController,name=OfflinePartitionsCount` — sollte 0 sein. Jeder Wert ungleich null = Daten sind weder für Lesen noch für Schreiben verfügbar. In Kombination mit `UncleanLeaderElectionsPerSec > 0` = der Cluster hat Daten verloren, indem er ein nicht synchrones Replica befördert hat. Betroffene Partitionen via `kafka-topics.sh --describe --unavailable-partitions` auflisten.
    Wie überwache ich einen Kafka-Cluster auf Kubernetes (Strimzi)?
    Der Strimzi-Operator aktiviert JMX auf jedem Broker standardmäßig auf Port `:9999`. Installieren Sie Xitogent auf einem K8s-Node mit Netzwerkzugriff auf Broker-Pods, oder deployen Sie es als DaemonSet, das sich über Service-DNS mit dem JMX-Endpunkt jedes Pods verbindet. Beobachten Sie operator-getriebene Rolling-Update-Events (sichtbar als ISR-Shrinks) und begrenzen Sie das Alarm-Fenster, damit Routine-Updates die Rufbereitschaft nicht alarmieren. Disk-Nutzung pro Pod gegenüber der Tiered-Storage-Schwelle ist hier ebenfalls wichtig.
    Kafka vs. Redpanda Monitoring — was ist anders?
    Redpanda ist wire-kompatibel mit der Kafka-API und stellt äquivalente Metriken bereit, aber direkt via Prometheus (kein JMX — Redpanda ist C++, kein JVM). Gleiche Metrik-Semantik (UnderReplicatedPartitions, ConsumerLag etc.) aber anderer Transport. Xitogent funktioniert mit beiden — JMX-Pfad für Apache Kafka / Confluent / Strimzi, Prometheus-Pfad für Redpanda. Das Cluster-Health-Alarm-Set ist identisch.
    Welche Kafka-Versionen werden unterstützt?
    Kafka 3.x (3.8 hat Tiered Storage GA via KIP-405 hinzugefügt), Kafka 4.0 (KRaft Pflicht, kein ZooKeeper), Kafka 4.1 (KIP-848 Next-Gen-Consumer-Rebalance-Protokoll mit serverseitigem Coordinator). Älteres 2.x funktioniert, aber ohne KRaft und Tiered Storage. Confluent Platform 7.x / 8.x und Redpanda sind über die gemeinsame Kafka-API kompatibel.

    Apache Kafka überwachen heute

    In weniger als 60 Sekunden eingerichtet. Keine Kreditkarte erforderlich. Umfassende Kennzahlen vom ersten Tag an.

    Kostenlose Testversion starten

    Entdecke weiter

    Verwandte Themen Integrationen