Kafka-Konfigurations-Best Practices für Produktionsumgebungen

Kafka ist in der Entwicklung nachsichtig und in der Produktion viel weniger nachsichtig. Ein Topic mit einer Replikation funktioniert gut, bis ein Broker ausfällt. Ein Producer mit schwachen Bestätigungen wirkt schnell, bis Nachrichten während eines Ausfalls verschwinden. Ein Consumer, der Offsets automatisch committet, scheint einfach, bis er Arbeit committet, die er noch nicht abgeschlossen hat. Die Kafka-Konfiguration in der Produktion dreht sich hauptsächlich darum, zu entscheiden, welche Ausfälle Sie tolerieren möchten, und diese Entscheidungen dann explizit zu machen.

Dieser Leitfaden behandelt Best Practices für die Kafka-Konfiguration in Produktionsumgebungen, ohne so zu tun, als gäbe es eine perfekte Konfigurationsdatei. Die richtigen Einstellungen hängen von der Arbeitslast, den Latenzanforderungen, den Haltbarkeitsanforderungen, der operativen Reife und der Kafka-Version ab. Die folgenden Beispiele sind Ausgangspunkte, die Sie unter Ihrem eigenen Datenverkehr testen sollten.

Grundlegendes zu den wichtigsten Kafka-Komponenten und ihrer Konfiguration

Bevor wir uns mit spezifischen Konfigurationen befassen, ist es entscheidend, die Kernkomponenten von Kafka zu verstehen und wie ihre Einstellungen das Gesamtsystemverhalten beeinflussen.

Broker: Die Kafka-Server, die Daten speichern und Client-Anfragen bedienen. Die Broker-Konfiguration bestimmt Leistung, Ressourcennutzung und Fehlertoleranz.
Topics: Kategorien oder Feeds von Nachrichten, die veröffentlicht werden.
Partitionen: Topics werden in eine oder mehrere Partitionen unterteilt, was Parallelität bei der Verarbeitung und Speicherung ermöglicht.
Replikation: Der Prozess des Kopierens von Partitionen über mehrere Broker, um Datenhaltbarkeit und -verfügbarkeit bei Broker-Ausfällen zu gewährleisten.
Consumer-Gruppen: Eine Gruppe von Consumern, die zusammenarbeiten, um Nachrichten von einem Topic zu konsumieren. Kafka stellt sicher, dass jede Nachricht innerhalb eines Topics an höchstens einen Consumer innerhalb jeder Consumer-Gruppe geliefert wird.

Topic- und Partitionierungsstrategien

Eine effektive Topic- und Partitionskonfiguration ist grundlegend für die Skalierbarkeit und Leistung von Kafka.

Partitionsanzahl

Die Wahl der richtigen Anzahl von Partitionen ist eine kritische Entscheidung. Mehr Partitionen ermöglichen eine höhere Parallelität auf der Consumerseite, was bedeutet, dass mehr Consumer-Instanzen Daten gleichzeitig verarbeiten können. Zu viele Partitionen können jedoch die Broker-Ressourcen (Speicher, Festplatten-I/O) belasten und die Latenz erhöhen. Eine gängige Faustregel ist, mit einer Partitionsanzahl zu beginnen, die Ihren erwarteten Spitzen-Consumer-Durchsatz widerspiegelt, wobei Sie bedenken sollten, dass Sie später bei Bedarf weitere Partitionen hinzufügen können.

Überlegung: Die maximale Anzahl von Partitionen, die ein Broker verarbeiten kann, ist durch seinen Speicher begrenzt. Jede Partition benötigt Speicher für ihre Leader- und Follower-Replikate.
Empfehlung: Streben Sie eine Partitionsanzahl an, die Ihren Anforderungen an die Consumer-Parallelität entspricht, vermeiden Sie jedoch übermäßige Partitionierung. Überwachen Sie die Ressourcennutzung des Brokers, um ein optimales Gleichgewicht zu finden.

Partitionsschlüssel

Beim Produzieren von Nachrichten bestimmt ein Partitionsschlüssel (oft ein Record-Key), in welche Partition eine Nachricht geschrieben wird. Eine konsistente Partitionierung ist für die geordnete Verarbeitung innerhalb einer Consumer-Gruppe unerlässlich.

partitioner.class: Diese Producer-Konfiguration kann auf org.apache.kafka.clients.producer.internals.DefaultPartitioner (Standard, verwendet einen Hash des Schlüssels) oder einen benutzerdefinierten Partitioner gesetzt werden.
Best Practice: Verwenden Sie einen Schlüssel, der Nachrichten gleichmäßig auf die Partitionen verteilt. Wenn Nachrichten mit demselben Schlüssel in der richtigen Reihenfolge verarbeitet werden müssen, garantiert Kafka die Reihenfolge nur innerhalb einer Partition.

Replikation und Fehlertoleranz

Replikation ist der primäre Mechanismus von Kafka zur Gewährleistung von Datenhaltbarkeit und -verfügbarkeit.

Replikationsfaktor

Der Replikationsfaktor bestimmt, wie viele Kopien jeder Partition im Cluster vorgehalten werden. Für Produktionsumgebungen wird ein minimaler Replikationsfaktor von 3 dringend empfohlen.

Vorteil: Mit einem Replikationsfaktor von 3 kann Kafka in der Regel einen Broker-Ausfall tolerieren, während ein weiteres Replikat verfügbar bleibt. Die genaue Verfügbarkeit hängt von min.insync.replicas, Producer acks, Leader-Election-Einstellungen und davon ab, welche Broker ausfallen.
Konfiguration: Dies wird auf Topic-Ebene festgelegt, entweder bei der Topic-Erstellung oder über kafka-topics.sh-Befehle.

# Beispiel: Erstellen eines Topics mit Replikationsfaktor 3
kafka-topics.sh --create --topic my-production-topic --bootstrap-server kafka-broker-1:9092 --replication-factor 3 --partitions 6

`min.insync.replicas`

Diese Broker-Konfigurationseinstellung legt die Mindestanzahl von Replikaten fest, die einen Schreibvorgang bestätigen müssen, bevor er als erfolgreich gilt. Für Topics mit einem Replikationsfaktor von N stellt die Einstellung min.insync.replicas=M (wobei M < N) sicher, dass ein Schreibvorgang erst bestätigt wird, nachdem M Replikate ihn bestätigt haben. Um Datenverlust zu verhindern, sollte min.insync.replicas in der Regel auf N-1 oder N/2 + 1 gesetzt werden, abhängig von Ihren Verfügbarkeits- und Haltbarkeitsabwägungen.

Empfehlung: Setzen Sie für kritische Topics min.insync.replicas auf replication_factor - 1. Dadurch wird sichergestellt, dass mindestens zwei Replikate (in einem 3-Replikat-Setup) die Daten haben, bevor der Schreibvorgang bestätigt wird, was Verluste verhindert, wenn der Leader ausfällt.
Konfiguration: Dies ist eine Konfiguration auf Broker-Ebene und kann auch pro Topic festgelegt werden.

# broker.properties
min.insync.replicas=2

# Topic-Level-Konfiguration (überschreibt Broker-Einstellung)
# kafka-configs.sh --alter --topic my-critical-topic --bootstrap-server ... --add-config min.insync.replicas=2

Leader-Election und Controller

Kafka verwendet einen Controller-Broker zur Verwaltung des Cluster-Zustands, einschließlich der Partition-Führerschaft. Robuste Controller-Konfigurationen sind entscheidend.

controller.quorum.voters: In KRaft-basierten Clustern gibt dies die Controller-Quorum-Wähler an. ZooKeeper-basierte Cluster verwenden ein anderes Control-Plane-Setup, kopieren Sie diese Einstellung also nicht blind zwischen den Architekturen.
num.io.threads und num.network.threads: Diese Broker-Einstellungen steuern die Anzahl der Threads, die für die Bearbeitung von I/O- und Netzwerkanfragen vorgesehen sind. Passen Sie sie basierend auf der Arbeitslast und der verfügbaren CPU an.

Producer- und Consumer-Konfigurationen

Die Optimierung der Producer- und Consumer-Einstellungen ist der Schlüssel zum Erreichen eines hohen Durchsatzes und einer geringen Latenz.

Producer-Konfigurationen

acks: Steuert die Anzahl der von Replikaten benötigten Bestätigungen. Die Einstellung acks=all (oder -1) bietet die stärkste Haltbarkeitsgarantie. In Kombination mit min.insync.replicas ist dies für die Produktion entscheidend.
retries: Setzen Sie einen hohen Wert (z. B. Integer.MAX_VALUE), um sicherzustellen, dass vorübergehende Fehler nicht zu Nachrichtenverlust führen. Verwenden Sie max.in.flight.requests.per.connection effektiv mit Wiederholungen.
max.in.flight.requests.per.connection: Steuert die maximale Anzahl unbestätigter Anfragen, die an einen Broker gesendet werden können. Ältere Clients verwendeten oft 1, um eine Neuordnung bei Wiederholungen zu vermeiden. Moderne idempotente Producer können die Reihenfolge mit höheren sicheren Grenzen bewahren, aber überprüfen Sie Ihre Client-Version und -Einstellungen.
batch.size und linger.ms: Diese Einstellungen steuern das Nachrichten-Batching. Größere Batches können den Durchsatz verbessern, erhöhen aber die Latenz. linger.ms fügt eine kleine Verzögerung hinzu, um mehr Nachrichten zusammenfassen zu können.

# producer.properties
acks=all
retries=2147483647
max.in.flight.requests.per.connection=1
batch.size=16384
linger.ms=5

Consumer-Konfigurationen

auto.offset.reset: Für die Produktion wird oft latest bevorzugt, um eine erneute Verarbeitung alter Nachrichten beim Neustart zu vermeiden. earliest kann verwendet werden, wenn Sie Nachrichten von Anfang an erneut verarbeiten müssen.
enable.auto.commit: Setzen Sie für eine zuverlässige Verarbeitung auf false. Manuelle Commits geben Ihnen die Kontrolle darüber, wann Offsets committet werden, und verhindern so die erneute Zustellung oder den Verlust von Nachrichten. Verwenden Sie commitSync() oder commitAsync() für explizite Commits.
max.poll.records: Steuert die maximale Anzahl von Datensätzen, die in einem einzigen poll()-Aufruf zurückgegeben werden. Passen Sie dies an, um die Verarbeitungslast zu verwalten und Consumer-Rebalances zu verhindern.
isolation.level: Setzen Sie auf read_committed, wenn Sie Kafka-Transaktionen verwenden, um sicherzustellen, dass Consumer nur committete Nachrichten lesen.

# consumer.properties
group.id=my-consumer-group
auto.offset.reset=latest
enable.auto.commit=false
isolation.level=read_committed
max.poll.records=500

Sicherheitsaspekte

Die Sicherung Ihres Kafka-Clusters ist in Produktionsumgebungen nicht verhandelbar.

Authentifizierung und Autorisierung

SSL/TLS: Verschlüsseln Sie die Kommunikation zwischen Clients und Brokern sowie zwischen Brokern untereinander. Dies erfordert das Generieren und Verteilen von Zertifikaten.
SASL (Simple Authentication and Security Layer): Verwenden Sie SASL-Mechanismen wie GSSAPI (Kerberos), PLAIN oder SCRAM zur Authentifizierung von Clients.
Autorisierung (ACLs): Konfigurieren Sie Zugriffskontrolllisten (ACLs), um zu definieren, welche Benutzer oder Prinzipale welche spezifischen Operationen (Lesen, Schreiben, Topic erstellen usw.) für welche Ressourcen (Topics, Consumer-Gruppen) ausführen dürfen.

Verschlüsselung

ssl.enabled.protocols: Stellen Sie sicher, dass Sie sichere Protokolle wie TLSv1.2 oder TLSv1.3 verwenden.
ssl.cipher.suites: Konfigurieren Sie starke Cipher Suites.

Konfigurationsbeispiel (Producer mit SASL über TLS)

security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="myuser" password="mypassword";
ssl.truststore.location=/path/to/truststore.jks
ssl.truststore.password=password

Leistungsoptimierung und Überwachung

Kontinuierliche Überwachung und Optimierung sind für die Aufrechterhaltung einer optimalen Leistung unerlässlich.

Broker-Tuning

num.partitions: Obwohl dies eine Einstellung auf Topic-Ebene ist, muss der Broker die Gesamtzahl der Partitionen verwalten. Überwachen Sie CPU, Speicher und Festplatten-I/O.
log.segment.bytes und log.roll.hours: Steuern Sie die Größe und die Roll-Häufigkeit von Log-Segmenten. Kleinere Segmente können zu mehr offenen Dateihandles und erhöhtem Overhead führen. Größere Segmente können mehr Speicherplatz pro Segment verbrauchen, reduzieren aber den Overhead.
message.max.bytes: Die maximale Größe einer Nachricht in Bytes. Stellen Sie sicher, dass dies für Ihren Anwendungsfall groß genug, aber nicht übermäßig ist.
replica.fetch.max.bytes: Steuert die maximale Anzahl von Bytes pro Fetch-Anfrage durch ein Follower-Replikat. Passen Sie dies an, um die Fetch-Effizienz und die Speichernutzung auszugleichen.

JVM-Tuning

Heap-Größe: Weisen Sie dem JVM, das Kafka ausführt, ausreichend Heap-Speicher zu. Überwachen Sie die Heap-Nutzung und die GC-Aktivität.
Garbage Collector: Wählen Sie einen geeigneten GC-Algorithmus (z. B. wird G1GC oft für Kafka empfohlen).

Überwachung

Implementieren Sie eine umfassende Überwachung mit Tools wie Prometheus/Grafana, Datadog oder kafka-spezifischen Überwachungslösungen.

Wichtige Metriken: Überwachen Sie die Broker-Gesundheit, den Topic-Durchsatz, den Consumer-Lag, den Replikationsstatus, die Anforderungslatenz und die Ressourcennutzung (CPU, Speicher, Festplatte, Netzwerk).
Alerting: Richten Sie Alarme für kritische Bedingungen wie hohen Consumer-Lag, Broker-Reaktionslosigkeit oder Speicherplatzmangel ein.

Consumer-Gruppen-Rebalances

Consumer-Gruppen-Rebalances treten auf, wenn Consumer einer Gruppe beitreten oder sie verlassen oder wenn Partitionen neu zugewiesen werden. Häufige Rebalances können die Verarbeitung stören.

session.timeout.ms: Wie lange ein Broker auf einen Heartbeat eines Consumers wartet, bevor er ihn als tot betrachtet. Niedrigere Werte bedeuten eine schnellere Erkennung, können aber aufgrund von Netzwerkstörungen zu vorzeitigen Rebalances führen.
heartbeat.interval.ms: Wie oft Consumer Heartbeats senden. Sollte deutlich kleiner als session.timeout.ms sein.
max.poll.interval.ms: Die maximale Zeit zwischen Poll-Aufrufen eines Consumers. Wenn ein Consumer länger als diese Zeit benötigt, um Nachrichten zu verarbeiten und erneut zu pollt, wird er als tot betrachtet, was ein Rebalance auslöst. Stellen Sie sicher, dass Ihre Consumer Nachrichten innerhalb dieses Intervalls verarbeiten können.
Tipp: Optimieren Sie die Consumer-Verarbeitungslogik, um die Arbeit innerhalb von max.poll.interval.ms abzuschließen und unnötige Rebalances aufgrund langsamer Consumer zu vermeiden.

Produktionsstandards, die ich explizit festlegen würde

Überlassen Sie wichtiges Kafka-Verhalten nicht versehentlichen Standardeinstellungen. Einige Standardeinstellungen sind für den allgemeinen Gebrauch vernünftig, aber Produktionssysteme benötigen Entscheidungen, die zu den Daten passen.

Verwenden Sie für kritische Event-Streams einen Replikationsfaktor von 3 oder mehr, wenn der Cluster genügend Broker und Racks hat, um dies zu unterstützen. Kombinieren Sie dies mit acks=all auf der Produzentenseite und min.insync.replicas=2 bei einem Topic mit drei Replikaten. Diese Kombination bedeutet, dass ein Schreibvorgang nur bestätigt wird, wenn der Leader und mindestens ein synchroner Follower ihn haben. Wenn zu viele Replikate nicht mehr synchron sind, erhalten die Produzenten Fehler, anstatt stillschweigend eine schwächere Haltbarkeit zu akzeptieren.

Dieser Kompromiss ist beabsichtigt. Während eines Ausfalls kann ein Topic mit hoher Haltbarkeit Schreibvorgänge ablehnen, anstatt Daten zu bestätigen, die sich nur auf einem Broker befinden. Einige Systeme bevorzugen Verfügbarkeit gegenüber Haltbarkeit für bestimmte Telemetrie- oder Clickstream-Daten. Das ist in Ordnung, wenn es eine bewusste Entscheidung ist. Es ist gefährlich, wenn niemand merkt, dass das Topic so konfiguriert wurde.

Deaktivieren Sie die unreine Leader-Wahl für Topics, bei denen Datenverlust nicht akzeptabel ist. Eine unreine Wahl kann eine Partition wieder online bringen, indem ein nicht synchrones Replikat gewählt wird, aber dieses Replikat kann je nach Ausfallverlauf und Produzenteneinstellungen bestätigte Datensätze vermissen lassen. Für kritische Daten ist es oft besser, nicht verfügbar zu sein, als Datensätze ohne Vorwarnung zu verlieren oder zurückzusetzen.

Partitionsanzahl: Wählen Sie für Durchsatz und Betrieb

Die Partitionsanzahl steuert die Parallelität, aber mehr Partitionen sind nicht kostenlos. Jede Partition fügt Metadaten, Dateihandles, Replikationsarbeit, Leader-Wahl-Arbeit und Wiederherstellungs-Overhead hinzu. Sie wirkt sich auch auf das Verhalten der Consumer-Gruppe aus. Ein Topic mit 200 Partitionen kann mehr Consumer-Parallelität unterstützen als ein Topic mit 12, erzeugt aber auch mehr bewegliche Teile während Broker-Neustarts und Rebalances.

Schätzen Sie zunächst die Consumer-Parallelität und den Durchsatz ab. Wenn der konsumierende Dienst maximal 12 Instanzen ausführt, sind 48 Partitionen möglicherweise ausreichend. Wenn Sie Hunderte von unabhängigen Verarbeitungsthreads erwarten, benötigen Sie möglicherweise mehr. Lassen Sie Raum für Wachstum, da eine spätere Erhöhung der Partitionsanzahl die Schlüsselverteilung und das Ordnungsverhalten für schlüsselgebundene Nachrichten ändern kann.

Die Reihenfolge wird nur innerhalb einer Partition garantiert. Wenn alle Ereignisse für customer_id=123 in der richtigen Reihenfolge verarbeitet werden müssen, verwenden Sie einen stabilen Schlüssel, der auf dieser Kunden-ID basiert. Erwarten Sie keine Ordnung über das gesamte Topic hinweg. Achten Sie auch auf heiße Schlüssel. Wenn ein Kunde, Mandant oder Gerät einen großen Anteil des Datenverkehrs produziert, kann die schlüsselbasierte Partitionierung eine Partition überlasten, während andere ruhig bleiben.

Für Multi-Tenant-Systeme sollten Sie abwägen, ob ein gemeinsames Topic oder viele Tenant-Topics einfacher zu betreiben sind. Viele kleine Topics können Metadaten-Overhead erzeugen. Ein riesiges gemeinsames Topic kann Aufbewahrung, Zugriffskontrolle und Incident-Response erschweren. Die beste Wahl hängt von den Isolationsanforderungen und der Verkehrsform ab.

Aufbewahrung ist eine Produktentscheidung, nicht nur eine Broker-Einstellung

Die Kafka-Aufbewahrung bestimmt, wie lange Daten für die Wiedergabe verfügbar bleiben. Eine kurze Aufbewahrung spart Speicherplatz, schränkt aber die Wiederherstellung ein. Eine lange Aufbewahrung ermöglicht Backfills und Audit-Workflows, erhöht aber die Speicherkosten und die Wiederherstellungszeit.

Legen Sie die Aufbewahrung pro Topic basierend auf der Verwendung der Daten fest. Ein Befehlstopic benötigt möglicherweise nur ein kurzes Zeitfenster. Ein Ereignisverlaufstopic benötigt möglicherweise Tage oder Wochen. Ein kompaktiertes Topic, das den letzten Stand darstellt, verwendet ein anderes Modell: Kafka behält nach der Kompaktierung den aktuellsten Wert pro Schlüssel sowie Tombstones für Löschungen bis zur Bereinigung.

Häufige Einstellungen umfassen:

retention.ms=604800000
retention.bytes=-1
cleanup.policy=delete

Für kompaktierte Topics:

cleanup.policy=compact
min.cleanable.dirty.ratio=0.5
delete.retention.ms=86400000

Seien Sie vorsichtig mit großen Nachrichten. Kafka kann größere Datensätze verarbeiten, wenn es konsistent konfiguriert ist, aber die Erhöhung von message.max.bytes bedeutet, dass Sie die Producer-max.request.size, die Consumer-fetch.max.bytes, die Broker-Replica-Fetch-Einstellungen und die Speicherauswirkungen überprüfen müssen. In vielen Systemen ist es einfacher und zuverlässiger, große Nutzlasten in einem Objektspeicher zu speichern und eine Referenz über Kafka zu senden.

Produzenteneinstellungen, die Schmerz vermeiden

Aktivieren Sie für die meisten Produktionsproduzenten die Idempotenz, es sei denn, Sie haben einen bestimmten Grund dagegen. Idempotente Produktion hilft, doppelte Schreibvorgänge zu vermeiden, die durch Wiederholungen nach vorübergehenden Fehlern verursacht werden. Viele moderne Kafka-Clients aktivieren es automatisch unter bestimmten Konfigurationen, aber es lohnt sich, die Entscheidung in Ihrer Produzentenkonfiguration sichtbar zu machen.

Beispiel für eine Produzentenbasislinie:

acks=all
enable.idempotence=true
retries=2147483647
delivery.timeout.ms=120000
request.timeout.ms=30000
linger.ms=5
batch.size=32768
compression.type=zstd

Die Wahl der Komprimierung hängt vom CPU-Budget und der Kafka-Version ab. zstd bietet oft eine starke Komprimierung, während lz4 und snappy übliche Optionen mit geringer Latenz sind. Testen Sie mit Ihren Nutzlasten. JSON-Logs, Avro-Datensätze, Protobuf-Nachrichten und bereits komprimierte Binärdaten verhalten sich unterschiedlich.

Batching ist ein weiterer Kompromiss. Ein kleiner linger.ms gibt dem Produzenten ein kurzes Zeitfenster, um Datensätze zu gruppieren, was den Durchsatz und die Komprimierung verbessern kann. Ein zu hoher Wert fügt Latenz hinzu. Denken Sie bei benutzerorientierten Anforderungspfaden an die Latenzbudgets. Für die Hintergrunderfassung kann ein etwas größerer Linger akzeptabel sein.

Ignorieren Sie keine Produzentenfehler. Wenn acks=all und min.insync.replicas einen Schreibvorgang während Broker-Problemen ablehnen, ist das ein nützlicher Gegendruck. Die Anwendung muss entscheiden, ob sie wiederholen, puffern, die Anfrage fehlschlagen lassen oder auf einen Fallback umleiten soll. Das Protokollieren des Fehlers und das Verwerfen des Ereignisses ist keine Haltbarkeitsstrategie.

Consumer-Einstellungen, die zur Verarbeitungssemantik passen

Consumer-Offset-Commits definieren, was "verarbeitet" bedeutet. Bei enable.auto.commit=true kann der Client Offsets committen, bevor Ihre Anwendung die Arbeit sicher abgeschlossen hat. Das kann für einmalige Analysen akzeptabel sein, ist aber riskant für Zahlungen, Bestellungen, Bereitstellungen oder alles, bei dem das Verpassen eines Ereignisses weh tut.

Deaktivieren Sie für eine zuverlässige Verarbeitung den Auto-Commit und committen Sie, nachdem die Arbeit erledigt ist:

enable.auto.commit=false
max.poll.records=500
max.poll.interval.ms=300000
session.timeout.ms=45000
heartbeat.interval.ms=15000
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor

Die Commit-Strategie hängt von der Anwendung ab. commitSync() ist einfacher und gibt ein klares Fehlerverhalten, kann aber Latenz hinzufügen. commitAsync() kann den Durchsatz verbessern, aber Sie müssen Callback-Fehler sorgfältig behandeln. Viele Dienste committen regelmäßig nach erfolgreichen Batches und machen nachgelagerte Schreibvorgänge idempotent, sodass eine Wiedergabe sicher ist.

Wenn die Verarbeitung einer Nachricht lange dauern kann, reduzieren Sie max.poll.records, erhöhen Sie max.poll.interval.ms oder verschieben Sie die langsame Arbeit hinter eine interne Warteschlange, während die Poll-Schleife verantwortungsvoll weiterläuft. Ein Consumer, der zu lange mit dem Pollen aufhört, löst ein Rebalance aus, und wiederholte Rebalances lassen die gesamte Gruppe instabil erscheinen.

Verwenden Sie statische Mitgliedschaft für Consumer, die häufig neu starten, aber mit stabilen Identitäten zurückkommen. Es kann unnötige Rebalances während rollierender Bereitstellungen reduzieren. Kooperatives Rebalancing kann die Unterbrechung im Vergleich zu eifrigem Rebalancing ebenfalls reduzieren, abhängig von der Client-Unterstützung.

Sicherheit, die Teams betreiben können

Produktions-Kafka sollte Verschlüsselung während der Übertragung verwenden, wenn Datenverkehr nicht vertrauenswürdige Netzwerke durchquert oder sensible Daten trägt. Die meisten Organisationen sollten TLS für die Client-Broker-Kommunikation und die Kommunikation zwischen Brokern verwenden. Die Authentifizierung kann gegenseitiges TLS, SASL/SCRAM, Kerberos, OAuth oder ein anderer unterstützter Mechanismus sein, abhängig von der Umgebung.

ACLs sollten spezifisch genug sein, um versehentliche Schäden zu verhindern. Ein Produzent für orders.created benötigt keine Berechtigung, um jedes Topic zu beschreiben. Eine Consumer-Gruppe für die Abrechnung benötigt keine Berechtigung, um Broker-Konfigurationen zu ändern. Verwenden Sie Namenskonventionen, die ACLs lesbar machen, und binden Sie Service-Prinzipale an Anwendungen und nicht an einzelne Personen.

Geheimnisse müssen rotiert werden. Wenn SASL-Anmeldeinformationen oder Keystores manuell auf Server kopiert werden, wird die Rotation schmerzhaft und hört irgendwann auf. Verwenden Sie nach Möglichkeit den Secret Manager Ihrer Plattform. Testen Sie die Rotation in der Staging-Umgebung, einschließlich rollierender Client-Neustarts.

Entscheiden Sie auch, wer Topics erstellen kann. Die automatische Topic-Erstellung ist in der Entwicklung praktisch und in der Produktion gefährlich. Ein Tippfehler in einem Topic-Namen kann ein neues Topic mit Standard-Partitionen, Standard-Replikation und Standard-Aufbewahrung erstellen. Viele Produktionscluster deaktivieren die automatische Topic-Erstellung und verwalten Topics über Infrastrukturcode oder einen genehmigten Workflow.

Broker- und Speicherprüfungen

Kafka ist empfindlich gegenüber Festplatten. Verwenden Sie Speicher mit vorhersagbarer Latenz, überwachen Sie die Festplattennutzung aggressiv und halten Sie genügend freien Speicherplatz für Aufbewahrung, Replikationsaufholung und betriebliche Fehler. Ein Broker mit einer vollen Festplatte kann einen viel größeren Vorfall verursachen als ein Broker mit hoher CPU.

Trennen Sie Kafka-Logs von nicht verwandten lauten Arbeitslasten. Vermeiden Sie es, Kafka-Daten auf gemeinsam genutzten Festplatten zu platzieren, auf denen ein anderer Prozess plötzlich I/O verbrauchen kann. Verstehen Sie in Cloud-Umgebungen die Durchsatzlimits von Volumes, Burst-Guthaben und das Wiederherstellungsverhalten. Eine Festplatte, die eine Minute lang gute Benchmarks liefert, kann unter anhaltender Replikation und Kompaktierung dennoch Probleme haben.

Rack-Awareness ist wichtig, wenn Sie mehrere Verfügbarkeitszonen oder Racks haben. Konfigurieren Sie Broker-Rack-IDs und Topic-Platzierung, sodass sich Replikate nicht alle in derselben Ausfallzone befinden. Ein Replikationsfaktor von 3 ist weniger nützlich, wenn alle drei Replikate mit einem Rack- oder Zonenproblem verschwinden.

Überwachung und Alarme, die echte Ausfälle erkennen

Ein nützliches Kafka-Überwachungs-Setup überwacht sowohl Kafka-Interna als auch die Client-Erfahrung. Broker-Metriken allein sagen Ihnen nicht, ob Consumer mithalten oder Produzenten Fehler sehen.

Überwachen Sie unter-replizierte Partitionen, offline Partitionen, aktive Controller-Anzahl, Anforderungslatenz, Fehlerraten bei Produktion und Fetch, Netzwerkdurchsatz, Festplattennutzung, Festplatten-I/O-Latenz, ISR-Schrumpfungs- und Expansionsraten, Controller-Ereigniswarteschlangenzeit, Consumer-Lag, Rebalance-Rate und Client-Wiederholungs-/Fehlerzahlen.

Consumer-Lag braucht Kontext. Ein Lag von 100 Datensätzen kann auf einem Topic, das Millionen pro Stunde erhält, in Ordnung sein. Ein Lag von 100 kann auf einem volumenarmen Befehlstopic ernst sein. Alarmieren Sie nach Möglichkeit auf das Lag-Alter oder die Zeit bis zum Aufholen, nicht nur auf die rohe Anzahl der Datensätze.

Testen Sie Broker-Neustarts während Wartungsfenstern, bevor der erste echte Ausfall eintritt. Ein Produktions-Kafka-Cluster sollte einen geplanten Broker-Neustart ohne Datenverlust und ohne Überraschung für Clients überstehen. Wenn ein Broker-Neustart einen größeren Vorfall verursacht, war der Cluster bereits fragil.

Ein Produktionsreife-Check

Bevor Sie einen Kafka-Cluster als produktionsreif bezeichnen, würde ich diese Punkte überprüfen:

Kritische Topics haben explizite Partitionen, Replikationsfaktor, Aufbewahrung, Bereinigungsrichtlinie und min.insync.replicas.
Produzenten für kritische Topics verwenden acks=all, Idempotenz, wo unterstützt, Wiederholungen und eine klare Fehlerbehandlung.
Consumer committen Offsets erst, nachdem die Anwendung ihren beabsichtigten Verarbeitungspunkt erreicht hat.
TLS, Authentifizierung und ACLs sind aktiviert und getestet.
Die automatische Topic-Erstellung ist deaktiviert oder streng kontrolliert.
Die Überwachung umfasst Broker-Gesundheit, Client-Fehler, Consumer-Lag, Festplatte und Replikation.
Backup- oder Wiedergabeerwartungen sind dokumentiert. Die Kafka-Aufbewahrung ist kein Ersatz für jedes Backup-Bedürfnis.
Verfahren für Broker-Neustart, Client-Bereitstellung und Anmeldeinformationsrotation wurden getestet.

Die praktische Erkenntnis

Die Kafka-Produktionskonfiguration ist eine Reihe von Kompromissen, kein universelles Rezept. Machen Sie Entscheidungen über Haltbarkeit, Ordnung, Wiedergabe, Sicherheit und Latenz pro Topic und pro Anwendung explizit. Testen Sie diese Entscheidungen dann mit Broker-Neustarts, Client-Ausfällen, langsamen Consumern und vollen Festplatten-Szenarien, bevor der Produktionsverkehr die Lektion für Sie erteilt.