Fehlerbehebung bei hoher Verbraucherlatenz in Ihrer Kafka-Pipeline

Hohe Verbraucherlatenz bedeutet, dass Nachrichten in Kafka verfügbar sind, bevor Ihre Anwendung sie vollständig verarbeitet hat. Diese Verzögerung kann sich als Verbraucherverzögerung, veraltete Dashboards, verzögerte Warnmeldungen oder nachgelagerte Jobs äußern, die ihr erwartetes Zeitfenster verpassen. Das Unangenehme daran ist, dass Kafka gesund sein kann, während die Pipeline dennoch langsam ist. Der Verbraucher wartet möglicherweise auf eine Datenbank, erledigt zu viel Arbeit pro Poll, committet zu oft Offsets oder kämpft mit Rebalancings, die durch lange Verarbeitungspausen verursacht werden.

Diese Anleitung geht zuerst auf die Verbraucherseite ein, da dort die meisten Latenzvorfälle sichtbar werden. Das Ziel ist es, das langsame Segment zu finden, bevor Einstellungen geändert werden.

Verständnis von Verbraucherverzögerung und Latenz

Die Verbraucherverzögerung ist die primäre Metrik, die auf Latenzprobleme hinweist. Sie stellt die Differenz zwischen dem neuesten Offset, der in eine Partition produziert wurde, und dem Offset dar, den die Verbrauchergruppe erfolgreich gelesen und committet hat. Eine hohe Verzögerung bedeutet, dass Ihre Verbraucher zurückfallen.

Wichtige zu überwachende Metriken:

• Verbraucherverzögerung: Gesamtzahl ungelesener Nachrichten pro Partition.
• Fetch-Rate vs. Produktionsrate: Wenn die Verbraucher-Fetch-Rate konsequent hinter der Produzentenrate zurückbleibt, wird die Verzögerung wachsen.
• Commit-Latenz: Zeit, die Verbraucher benötigen, um ihren Fortschritt zu speichern.

Phase 1: Analyse des Verbraucher-Fetching-Verhaltens

Der häufigste Grund für hohe Latenz ist ineffizienter Datenabruf. Verbraucher müssen Daten von Brokern abrufen, und wenn die Konfiguration suboptimal ist, verbringen sie möglicherweise zu viel Zeit mit Warten oder rufen zu wenig Daten ab.

Optimierung von fetch.min.bytes und fetch.max.wait.ms

Diese beiden Einstellungen beeinflussen direkt, wie viele Daten ein Verbraucher ansammelt, bevor er einen Fetch anfordert, und balancieren Latenz gegen Durchsatz.

• fetch.min.bytes: Die Mindestmenge an Daten, die der Broker zurückgeben soll (in Bytes). Ein größerer Wert fördert das Batching, was den Durchsatz erhöht, aber die Latenz leicht erhöhen kann, wenn die erforderliche Größe nicht sofort verfügbar ist.
  • Best Practice: Für Hochdurchsatz-Pipelines mit niedriger Latenz können Sie diesen Wert relativ niedrig halten (z.B. 1 Byte), um eine sofortige Rückgabe zu gewährleisten, oder ihn erhöhen, wenn Durchsatzengpässe beobachtet werden.
• fetch.max.wait.ms: Wie lange der Broker wartet, um fetch.min.bytes zu sammeln, bevor er antwortet. Ein längeres Warten maximiert die Batch-Größe, erhöht aber direkt die Latenz, wenn das erforderliche Volumen nicht vorhanden ist.
  • Kompromiss: Eine Verkürzung dieser Zeit (z.B. von den Standard-500ms auf 50ms) senkt die Latenz drastisch, kann aber zu kleineren, weniger effizienten Fetches führen.

Anpassen von max.poll.records

Diese Einstellung steuert, wie viele Datensätze in einem einzigen Consumer.poll()-Aufruf zurückgegeben werden.

max.poll.records=500 

Wenn max.poll.records zu niedrig eingestellt ist, verbringt der Verbraucher übermäßig viel Zeit mit dem Durchlaufen von poll()-Aufrufen, ohne signifikante Datenmengen zu verarbeiten, was den Overhead erhöht. Wenn es zu hoch ist, kann die Verarbeitung des großen Batches länger dauern als das Session-Timeout, was unnötige Rebalancings verursacht.

Umsetzbarer Tipp: Beginnen Sie mit einem moderaten Wert wie 100 bis 500 und beobachten Sie die tatsächliche Verarbeitungszeit für jeden Poll. Nehmen Sie keine Einstellung durch Raten vor. Wenn ein Batch von 500 Datensätzen vier Minuten dauert, weil jeder Datensatz in eine langsame API schreibt, wird eine Erhöhung von max.poll.records den Verbraucher instabiler machen, nicht schneller.

Phase 2: Untersuchung der Verarbeitungszeit und Commits

Selbst wenn Daten schnell abgerufen werden, entsteht eine hohe Latenz, wenn die Zeit, die für die Verarbeitung des abgerufenen Batches benötigt wird, die Zeit zwischen den Fetches überschreitet.

Engpässe in der Verarbeitungslogik

Wenn Ihre Verbraucheranwendungslogik umfangreiche externe Aufrufe (z.B. Datenbankschreibvorgänge, API-Abfragen) umfasst, die nicht innerhalb der Verarbeitungsschleife parallelisiert sind, wird die Verarbeitungszeit explodieren.

Schritte zur Fehlerbehebung:

1. Messen der Verarbeitungszeit: Verwenden Sie Metriken, um die Wanduhrzeit zu verfolgen, die zwischen dem Empfang des Batches und dem Abschluss aller nachgelagerten Operationen vor dem Commit vergeht.
2. Parallelisierung: Wenn die Verarbeitung langsam ist, erwägen Sie die Verwendung interner Thread-Pools in Ihrer Verbraucheranwendung, um Datensätze nach dem Pollen, aber vor dem Committen von Offsets gleichzeitig zu verarbeiten.

Überprüfung der Commit-Strategie

Das Committen von Offsets kann Latenz verursachen, wenn es zu häufig erfolgt, da jeder Commit eine Koordination mit Kafka erfordert. Das größere Risiko ist jedoch normalerweise die Korrektheit. Zu frühes Committen kann nach einem Absturz zu Datenverlust führen. Zu spätes Committen kann nach einem Absturz zu einer Wiederholung von Arbeit führen.

• enable.auto.commit: In Ordnung für einfache Leser, Experimente und nicht kritische Pipelines. Für Produktionsverbraucher, die Datenbanken aktualisieren, APIs aufrufen oder abgeleitete Ereignisse veröffentlichen, sind manuelle Commits normalerweise einfacher zu handhaben.
• auto.commit.interval.ms: Gibt an, wie oft Offsets committet werden (Standard ist 5 Sekunden).

Wenn die Verarbeitung schnell und stabil ist, reduziert ein längeres Intervall (z.B. 10-30 Sekunden) den Commit-Overhead. Wenn Ihre Anwendung jedoch häufig abstürzt, bewahrt ein kürzeres Intervall mehr laufende Arbeit, obwohl es den Netzwerkverkehr und die potenzielle Latenz erhöht.

Warnung zu manuellen Commits: Wenn Sie manuelle Commits verwenden (enable.auto.commit=false), stellen Sie sicher, dass commitSync() sparsam eingesetzt wird. commitSync() blockiert den Verbraucher-Thread, bis der Commit bestätigt wird, was die Latenz erheblich beeinträchtigt, wenn es nach jeder einzelnen Nachricht oder jedem kleinen Batch aufgerufen wird.

Phase 3: Skalierung und Ressourcenzuweisung

Wenn die Konfigurationen optimiert erscheinen, könnte das grundlegende Problem unzureichende Parallelität oder Ressourcensättigung sein.

Skalierung der Verbraucher-Threads

Kafka-Verbraucher skalieren, indem die Anzahl der Verbraucherinstanzen innerhalb einer Gruppe erhöht wird, bis zur Anzahl der Partitionen, die sie konsumieren. Wenn Sie 20 Partitionen und 5 Verbraucherinstanzen haben, wird Kafka normalerweise mehrere Partitionen jedem Verbraucher zuweisen. Das kann völlig in Ordnung sein. Die Grenze ist, dass eine Partition in einer Verbrauchergruppe jeweils nur von einem Verbraucher verarbeitet wird, sodass eine einzelne heiße Partition nicht einfach durch Hinzufügen weiterer Gruppenmitglieder behoben werden kann.

Faustregel: Die Anzahl der Verbraucherinstanzen sollte im Allgemeinen die Anzahl der Partitionen aller Themen, die sie abonnieren, nicht überschreiten. Mehr Instanzen als Partitionen führen zu untätigen Threads.

Broker- und Netzwerkzustand

Latenz kann außerhalb des Verbrauchercodes entstehen:

1. Broker-CPU/Arbeitsspeicher: Wenn Broker überlastet sind, steigt ihre Antwortzeit auf Fetch-Anfragen, was zu Verbraucher-Timeouts und Verzögerungen führt.
2. Netzwerksättigung: Hoher Netzwerkverkehr zwischen Verbrauchern und Brokern kann TCP-Übertragungen verlangsamen, insbesondere beim Abrufen großer Batches.

Verwenden Sie Überwachungstools, um die CPU-Auslastung der Broker und den Netzwerk-I/O in Zeiten hoher Verzögerung zu überprüfen.

Die Form der Verzögerung lesen

Die Form der Verzögerung verrät Ihnen, wo Sie suchen müssen. Eine einzelne zurückbleibende Partition deutet normalerweise auf ein enges Problem hin. Vielleicht leitet ein Schlüssel zu viel Verkehr an eine Partition. Vielleicht löst ein Datensatz einen langsamen Codepfad aus. Vielleicht ist der Host, der diese Partitionszuweisung ausführt, nicht gesund. In dieser Situation kann das Hinzufügen weiterer Verbraucher nichts bewirken, da Kafka diese eine Partition nicht auf mehrere Verbraucher in derselben Gruppe aufteilen kann.

Eine gleichmäßige Verzögerung über alle Partitionen hinweg deutet auf eine gemeinsame Grenze hin. Der Dienst benötigt möglicherweise mehr Instanzen, die nachgelagerte Datenbank ist möglicherweise gesättigt, oder die Broker sind möglicherweise langsam bei der Bereitstellung von Fetches. Wenn die Verzögerung jeden Tag zur gleichen Zeit ansteigt, suchen Sie nach geplanten Jobs, Batch-Produzenten, Komprimierungsdruck, Backups oder Autoscaling-Ereignissen. Kafka-Latenz ist oft ein Nebeneffekt von etwas außerhalb von Kafka.

Trennen Sie auch "Datensätze im Rückstand" von "Zeit im Rückstand". Ein Thema mit winzigen Ereignissen kann eine erschreckende Anzahl von Datensätzen im Rückstand aufweisen, aber in Sekunden aufholen. Ein Thema mit großen Datensätzen oder teurer Verarbeitung kann eine geringere Anzahl von Datensätzen im Rückstand aufweisen, aber Minuten geschäftlicher Verzögerung darstellen. Wenn Ihr Überwachungsstack die Verzögerungszeit aus Ereigniszeitstempeln schätzen kann, stellen Sie diese neben die Offset-Verzögerung grafisch dar. Wenn nicht, entnehmen Sie mit kafka-console-consumer.sh in einer temporären Gruppe einige Datensätze und vergleichen Sie die Ereigniszeitstempel mit der Wanduhrzeit.

Häufige Korrekturen, die nach hinten losgehen

Die erste schlechte Korrektur ist das Erhöhen von max.poll.interval.ms, bis Rebalancings aufhören. Das kann gültig sein, wenn die Verarbeitung von Natur aus lang ist, aber es kann auch einen blockierten Verbraucher länger verstecken. Wenn der Verbraucher zwanzig Minuten lang bei einem nachgelagerten Aufruf hängt, verzögert ein größeres Intervall die Wiederherstellung.

Die zweite schlechte Korrektur ist das Erhöhen der Partitionen während eines Vorfalls, ohne das Schlüsselmodell zu überprüfen. Mehr Partitionen können die zukünftige Parallelität verbessern, aber sie ändern die Partitionszuweisung für neue Datensätze und können Ordnungsannahmen beeinflussen. Sie teilt auch keine Datensätze auf, die bereits in vorhandenen Partitionen sitzen.

Die dritte schlechte Korrektur ist das Umschalten auf --to-latest-Offset-Resets, um Dashboards grün zu machen. Das überspringt Arbeit. Manchmal akzeptiert das Geschäft das, z.B. für wegwerfbare Analyseereignisse während eines Ausfalls. Für Abrechnung, Auftragsabwicklung, Sicherheitswarnungen oder benutzersichtbare Zustandsänderungen kann das Überspringen von Datensätzen im Rückstand einen viel größeren Vorfall verursachen als die Latenz selbst.

Wann die Skalierung von Verbrauchern hilft

Skalierung hilft, wenn die Gruppe mehr Partitionen als aktive Verbraucher hat und die Arbeit einigermaßen gleichmäßig auf diese Partitionen verteilt ist. Wenn ein Thema 24 Partitionen und 6 Verbraucher hat, kann der Wechsel zu 12 Verbrauchern die Latenz reduzieren, da jede Instanz weniger Partitionen verarbeitet. Der Wechsel von 24 Verbrauchern auf 40 Verbraucher wird derselben Gruppe nicht helfen; die zusätzlichen Verbraucher bleiben untätig, da nur 24 Partitionen zugewiesen werden können.

Skalierung hilft nicht viel, wenn alle Verbraucher auf dieselbe gesättigte Abhängigkeit warten. Wenn jeder Verbraucher in eine Datenbanktabelle schreibt, die bereits ausgelastet ist, können mehr Verbraucher die Konkurrenz erhöhen und die Latenz verschlechtern. In diesem Fall können das Bündeln von Schreibvorgängen, das Ändern von Indizes, das Hinzufügen von Gegendruck oder das Trennen heißer Arbeitslasten wichtiger sein als Kafka-Einstellungen.

Beobachten Sie Rebalancings während der Skalierung. Ein rollierender Deploy, der Verbraucher zu aggressiv startet und stoppt, kann Latenzspitzen erzeugen, selbst wenn die endgültige Replikatanzahl korrekt ist. Statische Mitgliedschaft mit group.instance.id kann unnötige Partitionsbewegungen für einige langlebige Dienste reduzieren, erfordert jedoch eine sorgfältige Instanzidentitätsverwaltung. Kooperatives Rebalancing kann auch Störungen im Vergleich zu eifrigem Rebalancing reduzieren, abhängig von der Client- und Assignor-Konfiguration.

Wenn Latenz wirklich ein Aufbewahrungsrisiko ist

Hohe Latenz wird dringend, wenn die Verzögerung sich dem Themen-Aufbewahrungsfenster nähert. Kafka entfernt alte Segmente basierend auf der Aufbewahrungsrichtlinie, nicht darauf, ob jeder Verbraucher sie gelesen hat. Wenn ein Verbraucher sechs Stunden hinter einem Thema zurück ist, das sieben Tage Daten aufbewahrt, haben Sie Zeit, die Anwendung zu reparieren. Wenn er sechs Tage hinter demselben Thema zurück ist, benötigen Sie einen Wiederherstellungsplan, bevor die ältesten ungelesenen Datensätze auslaufen.

Schätzen Sie während einer solchen Störung die Aufholrate. Wenn die Gruppe die Verzögerung um 50.000 Datensätze pro Minute reduziert und 5 Millionen Datensätze im Rückstand sind, kann sie in einem akzeptablen Zeitfenster aufholen. Wenn die Verzögerung immer noch wächst, erholt sich die Gruppe nicht. Möglicherweise müssen Sie Produzenten anhalten, temporäre Verbraucherkapazität hinzufügen, eine langsame nachgelagerte Abhängigkeit aus dem heißen Pfad entfernen oder eine bewusste Entscheidung darüber treffen, welche Daten übersprungen werden können.

Die beste Überwachung der Verbraucherlatenz zeigt sowohl die betriebliche Verzögerung als auch den Aufbewahrungsspielraum. "Diese Gruppe ist 20 Minuten zurück" ist nützlich. "Diese Gruppe hat 18 Stunden, bevor ungelesene Daten ablaufen" ist die Zahl, die die richtigen Leute in den Raum bringt.

Ein praktisches Latenz-Runbook

Beginnen Sie mit der Verzögerung auf Partitionsebene, nicht nur mit der Gesamtverzögerung:

kafka-consumer-groups.sh --bootstrap-server kafka-1:9092 --describe --group realtime-enricher

Wenn die Verzögerung auf eine Partition konzentriert ist, suchen Sie nach Schlüsselschiefe oder einer Verbraucherinstanz, die langsamer ist als die anderen. Wenn die Verzögerung gleichmäßig verteilt ist, suchen Sie nach einem gemeinsamen Engpass: zu wenige Verbraucher, langsame nachgelagerte Aufrufe, Broker-Fetch-Latenz oder einen Produzentenanstieg, der die normale Kapazität überschritten hat. Führen Sie den Befehl zweimal im Abstand von ein oder zwei Minuten aus, damit Sie wissen, ob die Gruppe aufholt oder weiter zurückfällt.

Messen Sie dann vier Zeitabläufe innerhalb der Anwendung: Wartezeit in poll(), Zeit für die Verarbeitung der zurückgegebenen Datensätze, Zeit für das Schreiben in nachgelagerte Systeme und Zeit für das Committen von Offsets. Diese Zahlen sagen Ihnen, welche Einstellung wichtig ist. Wenn poll() zu lange wartet, während der Datenverkehr gering ist, reduzieren Sie fetch.max.wait.ms oder halten Sie fetch.min.bytes niedrig. Wenn die Verarbeitung dominiert, sind Kafka-Fetch-Einstellungen eine Ablenkung. Wenn Commits dominieren, hören Sie auf, jeden Datensatz mit synchronen Commits zu committen.

Für Dienste mit niedriger Latenz beginne ich normalerweise mit konservativem Fetch-Batching und erhöhe es nur, wenn Broker- oder Netzwerk-Overhead eindeutig das Problem ist:

fetch.min.bytes=1
fetch.max.wait.ms=50
max.poll.records=100
enable.auto.commit=false

Das ist keine universelle beste Konfiguration. Es ist ein lesbarer Ausgangspunkt. Ein Batch-ETL-Verbraucher bevorzugt möglicherweise größere Fetches und größere max.poll.records. Ein Betrugsbewertungsdienst bevorzugt möglicherweise kleinere Batches, da ein langsamer API-Aufruf den gesamten Batch aufhalten kann.

Seien Sie besonders vorsichtig beim Hinzufügen von Worker-Threads nach poll(). Parallele Verarbeitung kann helfen, aber Offsets dürfen nur committet werden, nachdem alle früheren Datensätze für die relevante Partition sicher verarbeitet wurden. Wenn Worker-Threads in falscher Reihenfolge abschließen und Sie den höchsten Offset zu früh committen, kann ein Absturz stillschweigend Datensätze überspringen, die noch in Bearbeitung waren. Ein gängiges Muster ist es, den Abschluss pro Partition zu verfolgen und nur den höchsten zusammenhängenden abgeschlossenen Offset zu committen.

Die Checkliste ist einfach: Überprüfen Sie die Verzögerung nach Partition, messen Sie die Anwendungsphasen, optimieren Sie das Fetch-Verhalten nur, wenn das Fetch-Verhalten das Problem ist, und skalieren Sie Verbraucher nur, wenn genügend Partitionen vorhanden sind, um die zusätzlichen Instanzen zu nutzen. Diese Reihenfolge verhindert die meiste verschwendete Optimierungsarbeit.