Fehlerbehebung bei häufigem Kafka-Consumer-Lag mithilfe von Konsolenbefehlen

Consumer-Lag ist die erste Zahl, die die meisten Kafka-Operatoren überprüfen, wenn eine Pipeline sich langsam anfühlt, aber es ist auch eine der am leichtesten falsch zu interpretierenden Zahlen. Eine Gruppe kann eine Million Datensätze an Lag aufweisen, weil eine nachgelagerte API eine Zeitüberschreitung hat, weil eine Bereitstellung die Hälfte der Consumer offline gelassen hat, weil eine Partition heißer ist als die anderen, oder weil die Anwendung gesund ist und sich einfach nach einer geplanten Pause aufholt. Die Befehle sind einfach. Das Urteilsvermögen um sie herum entscheidet über Erfolg oder Misserfolg bei Vorfällen.

Dieser Leitfaden konzentriert sich auf den Befehlszeilenweg, den ich während eines Lag-Vorfalls verwende: Beschreiben Sie die Gruppe, vergleichen Sie Partitionen, bestätigen Sie, ob Consumer aktiv sind, entscheiden Sie, ob der Lag wächst oder schrumpft, und erwägen Sie erst dann einen Offset-Reset. Offset-Resets sind enthalten, weil sie manchmal notwendig sind, aber sie sind kein Heilmittel für einen langsamen Consumer. Sie überspringen entweder Arbeit oder wiederholen Arbeit. Behandeln Sie sie als operative Entscheidung, nicht als Leistungsverbesserung.

Kafka-Consumer-Lag verstehen

In Kafka sind Nachrichten in Topics organisiert, die weiter in Partitionen unterteilt sind. Jeder Nachricht innerhalb einer Partition wird ein sequenzieller, unveränderlicher Offset zugewiesen. Consumer lesen Nachrichten aus einer Partition, indem sie ihre aktuelle Position, auch als committed offset bezeichnet, beibehalten. Der Kafka-Broker verfolgt den log-end-offset für jede Partition, der den Offset der letzten an die Partition angehängten Nachricht darstellt.

Consumer-Lag = Log-End-Offset - Committed Offset

Im Wesentlichen ist Lag die Anzahl der Nachrichten, die ein Consumer hinter dem Kopf des Logs für eine bestimmte Partition zurückliegt. Während ein gewisser Lag in jedem Streaming-System natürlich und zu erwarten ist, signalisiert ein ständig wachsender oder übermäßig großer Lag ein Problem.

Warum hoher Consumer-Lag ein Problem ist:

• Verzögerte Datenverarbeitung: Ihre Anwendungen verarbeiten Daten möglicherweise zu langsam, was sich auf Echtzeitanalysen oder kritische Geschäftsabläufe auswirkt.
• Ressourcenerschöpfung: Consumer haben möglicherweise Mühe, Schritt zu halten, was zu hoher CPU-, Speicher- oder Netzwerkauslastung führt.
• Veraltete Daten: Nachgelagerte Systeme, die Daten von zurückgebliebenen Consumern erhalten, arbeiten mit veralteten Informationen.
• Probleme mit der Aufbewahrungsrichtlinie: Wenn der Lag die Aufbewahrungsfrist des Topics überschreitet, verpassen Consumer möglicherweise dauerhaft Nachrichten, da sie aus dem Log gelöscht werden.
• Neuausrichtung von Consumer-Gruppen: Anhaltender Lag kann zu instabilem Verhalten der Consumer-Gruppe und häufigen Neuausrichtungen beitragen.

Häufige Ursachen für hohen Lag:

• Langsame Consumer-Logik: Die Consumer-Anwendung selbst benötigt zu viel Zeit, um jede Nachricht zu verarbeiten.
• Unzureichende Consumer-Instanzen: Es werden nicht genügend Consumer-Instanzen ausgeführt, um das Nachrichtenaufkommen über alle Partitionen hinweg zu bewältigen.
• Netzwerklatenz: Probleme zwischen Consumern und Brokern.
• Leistungsprobleme des Brokers: Broker haben möglicherweise Schwierigkeiten, Nachrichten effizient bereitzustellen.
• Spitzen in der Nachrichtenproduktion: Vorübergehende Nachrichtenausbrüche, die Consumer überfordern.
• Konfigurationsfehler: Falsche Consumer- oder Topic-Konfigurationen.

Diagnose von Lag mit kafka-consumer-groups.sh (Empfohlen)

Das Tool kafka-consumer-groups.sh ist die moderne und empfohlene Methode zur Verwaltung und Inspektion von Consumer-Gruppen. Es interagiert direkt mit den Kafka-Brokern, um Consumer-Offset-Informationen abzurufen, die in einem internen __consumer_offsets-Topic gespeichert sind. Dieses Tool bietet umfassende Details zum Status der Consumer-Gruppe, einschließlich Lag.

Grundlegende Verwendung zur Beschreibung einer Consumer-Gruppe

Um den Lag für eine bestimmte Consumer-Gruppe zu überprüfen, verwenden Sie die Optionen --describe und --group:

kafka-consumer-groups.sh --bootstrap-server <Kafka_Broker_Host:Port> --describe --group <Consumer_Group_Name>

Ersetzen Sie <Kafka_Broker_Host:Port> durch die Adresse eines Ihrer Kafka-Broker (z. B. localhost:9092) und <Consumer_Group_Name> durch den Namen der Consumer-Gruppe, die Sie überprüfen möchten.

Interpretation der Ausgabe

Eine typische Ausgabe sieht etwa so aus:

GROUP           TOPIC                          PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG             CONSUMER-ID                                       HOST            CLIENT-ID
my-consumer-app my-topic                       0          12345           12347           2               consumer-1-a1b2c3d4-e5f6-7890-1234-abcdedfg      /192.168.1.100  consumer-1
my-consumer-app my-topic                       1          20000           20500           500             consumer-2-hijk-lmno-pqrs-tuvw-xyz              /192.168.1.101  consumer-2
my-consumer-app my-topic                       2          5000            5000            0               consumer-3-1234-5678-90ab-cdef-12345678          /192.168.1.102  consumer-3
my-consumer-app another-topic                  0          900             900             0               consumer-1-a1b2c3d4-e5f6-7890-1234-abcdedfg      /192.168.1.100  consumer-1

Lassen Sie uns die wichtigen Spalten aufschlüsseln:

• GROUP: Der Name der Consumer-Gruppe.
• TOPIC: Das Topic, das konsumiert wird.
• PARTITION: Die spezifische Partition des Topics.
• CURRENT-OFFSET: Der letzte Offset, der vom Consumer für diese Partition committet wurde.
• LOG-END-OFFSET: Der Offset der neuesten Nachricht in dieser Partition.
• LAG: Die Differenz zwischen LOG-END-OFFSET und CURRENT-OFFSET. Dies ist die Anzahl der Nachrichten, die der Consumer zurückliegt.
• CONSUMER-ID: Eine eindeutige Kennung für die Consumer-Instanz. Wenn dies - ist, bedeutet es, dass dieser Partition kein aktiver Consumer zugewiesen ist.
• HOST: Die IP-Adresse oder der Hostname der Consumer-Instanz.
• CLIENT-ID: Die Client-ID, die für die Consumer-Instanz konfiguriert ist.

Wichtige Beobachtungen:

• Hohe LAG-Werte: Zeigen an, dass der Consumer zurückfällt. Untersuchen Sie die Consumer-Logik, Ressourcen oder Skalierung.
• - in CONSUMER-ID: Deutet darauf hin, dass eine Partition nicht konsumiert wird. Dies kann auf eine unzureichende Anzahl aktiver Consumer in der Gruppe oder eine abgestürzte Consumer-Instanz zurückzuführen sein, die nicht wieder beigetreten ist. Wenn LAG für solche Partitionen hoch ist, ist dies ein kritisches Problem.
• LAG von 0: Bedeutet, dass der Consumer mit den neuesten Nachrichten vollständig auf dem neuesten Stand ist.

Diagnose von Lag mit consumer-offset-checker.sh (Veraltetes Tool)

consumer-offset-checker.sh ist ein älteres, veraltetes Tool, das sich auf ZooKeeper zum Speichern und Abrufen von Consumer-Offsets stützte (für Consumer, die den alten kafka.consumer.ZookeeperConsumerConnector verwenden). Für moderne Kafka-Clients (0.9.0 und später) werden Offsets in Kafka selbst gespeichert. Obwohl es weitgehend durch kafka-consumer-groups.sh ersetzt wurde, können Sie es in älteren Umgebungen oder mit veralteten Consumer-Clients antreffen.

Warnung: Hinweis zur Veraltung

Dieses Tool verlässt sich für das Offset-Management auf ZooKeeper. Moderne Kafka-Clients (0.9.0+) speichern Offsets direkt in Kafka. Für neuere Cluster und Clients ist kafka-consumer-groups.sh das maßgebliche und bevorzugte Tool. Verwenden Sie consumer-offset-checker.sh nur, wenn Sie explizit wissen, dass Ihre Consumer-Clients so konfiguriert sind, dass sie Offsets in ZooKeeper speichern.

Grundlegende Verwendung

Um den Lag mit diesem Tool zu überprüfen, müssen Sie die ZooKeeper-Verbindungszeichenfolge angeben:

consumer-offset-checker.sh --zk <ZooKeeper_Host:Port> --group <Consumer_Group_Name>

Ersetzen Sie <ZooKeeper_Host:Port> (z. B. localhost:2181) und <Consumer_Group_Name>.

Interpretation der Ausgabe

Group           Topic                          Partition Offset  LogSize Lag     Owner
my-old-app      my-old-topic                   0         1000    1050    50      consumer-1_hostname-1234-5678-90ab-cdef
my-old-app      my-old-topic                   1         2000    2000    0       consumer-2_hostname-abcd-efgh-ijkl-mnop

• Group, Topic, Partition: Ähnlich wie bei kafka-consumer-groups.sh.
• Offset: Der vom Consumer committete Offset.
• LogSize: Der LOG-END-OFFSET der Partition.
• Lag: Die Anzahl der Nachrichten, die der Consumer zurückliegt.
• Owner: Die Consumer-Instanz, die derzeit die Partition besitzt (von ihr konsumiert).

Die Interpretation der Lag-Werte ist ähnlich: Hoher Lag deutet auf Probleme hin, und ein fehlender Owner für eine Partition mit hohem Lag ist ein kritisches Problem.

Behebung von hohem Consumer-Lag: Strategien und Offset-Resets

Sobald Sie einen hohen Consumer-Lag identifiziert haben, besteht der nächste Schritt darin, ihn zu beheben. Dies beinhaltet oft einen zweigleisigen Ansatz: Zuerst die Ursache untersuchen und beheben, und zweitens, falls erforderlich, Consumer-Offsets zurücksetzen.

Untersuchung der Ursache

Bevor Sie zu Offset-Resets springen, ist es entscheidend zu verstehen, warum der Lag auftritt. Überprüfen Sie Folgendes:

• Consumer-Anwendungslogs: Suchen Sie nach Fehlern, übermäßigen Verarbeitungszeiten oder Anzeichen für Anwendungsfehler.
• Metriken des Consumer-Hosts: Überwachen Sie CPU-, Speicher- und Netzwerkauslastung. Ist der Consumer ressourcenbegrenzt?
• Metriken des Kafka-Brokers: Sind die Broker unter Stress? Sind Festplatten-I/O, Netzwerk oder CPU hoch?
• Producer-Durchsatz: Gab es einen unerwarteten Anstieg der Nachrichtenproduktion?
• Status der Consumer-Gruppe: Gibt es häufige Neuausrichtungen? Wird max.poll.interval.ms erreicht?

Skalierung von Consumern

Wenn das Problem darin besteht, dass vorhandene Consumer Nachrichten nicht schnell genug verarbeiten können und das Topic genügend Partitionen hat, müssen Sie möglicherweise Ihre Consumer-Gruppe durch Hinzufügen weiterer Consumer-Instanzen hochskalieren. Jede Consumer-Instanz in einer Gruppe übernimmt eine oder mehrere Partitionen, bis alle Partitionen zugewiesen sind, bis zur Anzahl der Partitionen.

Zurücksetzen von Consumer-Offsets

Das Zurücksetzen von Consumer-Offsets bedeutet, den Startpunkt zu ändern, ab dem eine Consumer-Gruppe Nachrichten liest. Dies ist eine leistungsstarke, potenziell störende Operation, die mit Vorsicht verwendet werden sollte.

Wichtige Überlegungen vor dem Zurücksetzen von Offsets:

• Datenverlust: Das Zurücksetzen auf --to-latest führt dazu, dass Consumer alle Nachrichten zwischen ihrem aktuellen Offset und dem log-end-offset überspringen, was zu dauerhaftem Datenverlust für diese Nachrichten führt.
• Datenwiederaufbereitung: Das Zurücksetzen auf --to-earliest oder einen älteren Offset bedeutet, dass Consumer Nachrichten, die sie bereits verarbeitet haben, erneut verarbeiten. Ihre Consumer-Anwendung muss idempotent sein (die mehrmalige Verarbeitung einer Nachricht führt zum gleichen Ergebnis), um dies problemlos zu handhaben.
• Anwendungsstatus: Überlegen Sie, wie sich die erneute Verarbeitung auf einen von Ihrer Consumer-Anwendung oder nachgelagerten Systemen verwalteten Status auswirken könnte.

Zum Zurücksetzen von Offsets verwenden Sie erneut kafka-consumer-groups.sh. Es bietet verschiedene Optionen zum Zurücksetzen von Offsets:

• --to-earliest: Setzt Offsets auf den frühesten verfügbaren Offset in der Partition zurück.
• --to-latest: Setzt Offsets auf den neuesten Offset in der Partition zurück (überspringt effektiv alle aktuellen Nachrichten).
• --to-offset <offset>: Setzt Offsets auf einen bestimmten, gewünschten Offset zurück.
• --to-datetime <YYYY-MM-DDTHH:mm:SS.sss>: Setzt Offsets auf den Offset zurück, der einem bestimmten Zeitstempel entspricht.
• --shift-by <N>: Verschiebt den aktuellen Offset um N Positionen (z. B. -10, um 10 Nachrichten zurückzugehen, +10, um 10 Nachrichten vorzugehen).

Entscheidende Sicherheitsfunktionen: --dry-run und --execute

Führen Sie immer zuerst einen --dry-run durch, um zu sehen, was die Zurücksetzungsoperation tun würde, bevor Sie mit --execute committen.

Schritt-für-Schritt-Prozess zum Zurücksetzen von Offsets:

1. Stoppen Sie alle Consumer in der Ziel-Consumer-Gruppe. Dies ist wichtig, um zu verhindern, dass Consumer neue Offsets committen, während Sie versuchen, sie zurückzusetzen.

2. Führen Sie einen Probelauf durch, um die Offset-Änderungen in der Vorschau anzuzeigen:

   • Beispiel: Zurücksetzen auf den frühesten Offset (alle Nachrichten erneut verarbeiten)

     kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-consumer-app --reset-offsets --to-earliest --topic my-topic --dry-run
     

   • Beispiel: Zurücksetzen auf den neuesten Offset (alle zurückgebliebenen Nachrichten überspringen)

     kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-consumer-app --reset-offsets --to-latest --topic my-topic --dry-run
     

   • Beispiel: Zurücksetzen auf einen bestimmten Zeitstempel (z. B. ab 2023-01-01 00:00:00 UTC)

     kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-consumer-app --reset-offsets --to-datetime 2023-01-01T00:00:00.000 --topic my-topic --dry-run
     

   • Beispiel: Offsets um 500 Nachrichten zurückverschieben (pro Partition)

     kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-consumer-app --reset-offsets --shift-by -500 --topic my-topic --dry-run
     

   Die Ausgabe von --dry-run zeigt die vorgeschlagenen Offset-Änderungen an:

   GROUP                          TOPIC                          PARTITION NEW-OFFSET
   my-consumer-app                my-topic                       0         0
   my-consumer-app                my-topic                       1         0
   

3. Führen Sie das Zurücksetzen aus, sobald Sie mit den Ergebnissen des Probelaufs zufrieden sind:

   • Beispiel: Zurücksetzen auf den frühesten Offset (ausführen)

     kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-consumer-app --reset-offsets --to-earliest --topic my-topic --execute
     

4. Starten Sie die Consumer-Anwendungen neu. Nachdem die Offsets zurückgesetzt wurden, starten Sie Ihre Consumer-Instanzen neu. Sie beginnen nun, von den neuen Start-Offsets zu konsumieren.

Tipp: Zurücksetzen für alle Topics in einer Gruppe

Wenn Sie Offsets für alle Topics zurücksetzen möchten, die von einer Gruppe konsumiert werden, können Sie das Flag --topic weglassen, wenn Sie kafka-consumer-groups.sh --reset-offsets verwenden. Seien Sie hierbei besonders vorsichtig, da dies alles betrifft.

Best Practices für Consumer-Operationen

• Proaktive Überwachung: Implementieren Sie eine robuste Überwachung des Consumer-Lags mit Tools wie Prometheus/Grafana, Datadog oder benutzerdefinierten Skripten. Richten Sie Warnungen für schnell wachsenden oder konstant hohen Lag ein.
• Idempotenz verstehen: Entwerfen Sie Ihre Consumer-Anwendungen so, dass sie idempotent sind. Dies ermöglicht eine sichere erneute Verarbeitung von Nachrichten im Falle von Fehlern oder Offset-Resets.
• max.poll.interval.ms anpassen: Diese Einstellung definiert die maximale Zeit, die ein Consumer ohne Polling auskommen kann. Wenn Ihre Verarbeitungslogik langsam ist, erhöhen Sie diesen Wert, um unerwünschte Neuausrichtungen zu verhindern, aber untersuchen Sie auch die zugrunde liegende Langsamkeit.
• Unverarbeitbare Nachrichten behandeln: Implementieren Sie eine Strategie für "Giftpillen"-Nachrichten (z. B. senden Sie sie an eine Dead-Letter-Queue - DLQ), anstatt wiederholt zu fehlschlagen und den Consumer zu blockieren.
• Graceful Shutdowns: Stellen Sie sicher, dass Ihre Consumer-Anwendungen ordnungsgemäß heruntergefahren werden, indem sie ihre endgültigen Offsets committen, um unnötige erneute Verarbeitung oder Lag-Spitzen während Neustarts zu vermeiden.
• Partitionen an Consumer anpassen: Streben Sie für optimale Parallelität an, mindestens so viele Partitionen zu haben, wie Sie voraussichtlich Consumer-Instanzen ausführen werden. Mehr Partitionen ermöglichen mehr Parallelität.

Ein praktischer Vorfallablauf

Wenn Lag einen Alarm auslöst, widerstehen Sie dem Drang, zuerst Offsets zurückzusetzen. Erfassen Sie zunächst den aktuellen Gruppenstatus:

kafka-consumer-groups.sh --bootstrap-server kafka-1:9092 --describe --group payments-writer

Achten Sie auf die Form, nicht nur auf die Größe. Wenn jede Partition um ungefähr den gleichen Betrag zurückliegt, ist die gesamte Gruppe wahrscheinlich unterdimensioniert oder durch eine gemeinsame Abhängigkeit blockiert. Wenn eine Partition weit zurückliegt, überprüfen Sie auf Key-Skew, eine Giftnachricht oder einen einzelnen Consumer-Host mit schlechtem CPU-, Festplatten-, DNS- oder Netzwerkverhalten. Wenn CONSUMER-ID - ist, hat die Partition derzeit kein aktives Mitglied zugewiesen; dies deutet normalerweise auf abgestürzte Consumer, eine laufende Neuausrichtung oder eine Gruppe mit weniger gesunden Mitgliedern als erwartet hin.

Führen Sie den Befehl eine Minute später erneut aus. Ein Lag-Wert von 500.000 ist weniger besorgniserregend, wenn er nach einem Rollback schnell sinkt. Ein Lag-Wert von 5.000 ist besorgniserregender, wenn er sich bei normalem Datenverkehr jede Minute verdoppelt. Während eines Vorfalls notiere ich normalerweise drei Zahlen: Gesamt-Lag, schlechtester Partitions-Lag und ob der Gruppenstatus stabil ist. Das gibt Ihnen genug Signal, um zu entscheiden, ob Sie Consumer skalieren, Produzenten verlangsamen, Anwendungsfehler beheben oder eine kontrollierte Wiederholung vorbereiten sollten.

Speichern Sie vor jedem Zurücksetzen die aktuellen Offsets an einem dauerhaften Ort, auch wenn es nur das Vorfall-Ticket ist. Ein Probelauf ist kein Backup. Die Befehlsausgabe gibt Ihnen die Offsets, die Sie möglicherweise benötigen, wenn jemand erkennt, dass das Zurücksetzen Daten übersprungen hat, die noch wichtig waren.

Abschließende Überprüfungen

Ein gesundes Lag-Runbook hat drei Gewohnheiten: Beschreiben vor dem Ändern, Probelauf vor dem Ausführen und den Consumer reparieren, bevor Offsets verschoben werden. kafka-consumer-groups.sh gibt Ihnen die rohe Wahrheit über committete Offsets und Partitionsbesitz. Ihre Aufgabe ist es, diese Ausgabe mit dem dahinter liegenden Anwendungsverhalten zu verbinden.