- Logstash liest Datenströme aus Kafka über das kafka-Input-Plugin und verarbeitet sie in einer dreistufigen Pipeline: Input, Filter, Output.
- Ein Kafka-Topic sollte mindestens 3 Partitionen und einen Replikationsfaktor von 2 haben, damit ein Broker-Ausfall verkraftbar bleibt.
- Der json-Codec im Input ersetzt das manuelle Parsen und senkt die Latenz pro Nachricht um bis zu 40 %.
- Die JVM-Heap-Größe sollte 50–60 % des verfügbaren RAM betragen, nie mehr.
- Ohne persistente Queue und korrekte Consumer-Gruppe verlieren Sie bei einem Neustart bis zu 100 % der ungelesenen Nachrichten.
Warum Logstash und Kafka gemeinsam für die Echtzeit-Datenanalyse einsetzen?
Kafka puffert Datenströme skalierbar und entkoppelt Produzenten von Konsumenten, während Logstash diese Ströme transformiert, anreichert und an Analysesysteme weiterleitet — eine Kombination, die Durchsatz und Flexibilität gleichzeitig liefert.
Kurz gesagt :
- Logstash liest Kafka-Ströme über das kafka-Input-Plugin und verarbeitet sie in den drei Stufen Input, Filter und Output.
- Kafka-Topics benötigen mindestens 3 Partitionen und Replikationsfaktor 2, um Broker-Ausfälle zu verkraften.
- Der json-Codec im Input senkt die Latenz pro Nachricht um bis zu 40 %.
- Die JVM-Heap-Größe sollte 50–60 % des RAM betragen; ohne persistente Queue und Consumer-Gruppe gehen bei Neustart bis zu 100 % ungelesener Nachrichten verloren.
Bevor wir uns in die Konfiguration stürzen, möchte ich die Architektur klarstellen. Kafka ist ein verteiltes Log. Logstash ist ein Verarbeitungsmotor. Das sind zwei verschiedene Aufgaben, und genau deshalb passen sie zusammen.
Ich habe in den letzten Jahren zahlreiche Pipelines evaluiert, von kleinen Setups mit 8 GB RAM bis zu Clustern mit 40 Brokern. Die häufigste Fehlannahme: Logstash sei langsam. Falsch. Falsch konfiguriertes Logstash ist langsam. Der Unterschied liegt fast immer in der JVM, der Batch-Größe und der Filterreihenfolge.
Was ist Logstash und wofür wird es eingesetzt?
Logstash ist eine serverbasierte Datenverarbeitungs-Pipeline, die Ereignisse aus beliebigen Quellen aufnimmt, in Filterketten transformiert und an ein oder mehrere Ziele ausgibt — typischerweise Elasticsearch, Kafka oder S3.
Die drei Stufen heißen Input, Filter und Output. Jede Stufe läuft in eigenen Threads. Das ist wichtig, weil ein blockierender Filter die Input-Stufe nicht ausbremst, solange Sie die Worker-Anzahl korrekt setzen.
Was ist Kafka und welche Rolle spielt es in einer Echtzeit-Architektur?
Kafka ist eine verteilte, partitionierte Commit-Log-Plattform, die Nachrichten mit hohem Durchsatz persistent speichert und Konsumenten unabhängig voneinander lesen lässt — das Rückgrat jeder robusten Echtzeit-Datenanalyse.
Ein Topic ist in Partitionen unterteilt. Innerhalb einer Partition gilt eine strikte Reihenfolge. Über Partitionen hinweg nicht. Merken Sie sich das, denn es entscheidet später über Ihre Konsistenzgarantien.
Die Datenflussarchitektur: vom Producer bis zum Analyse-Dashboard
Der typische Pfad verläuft vom Producer über den Kafka-Topic, durch Logstash mit Filtern und Codecs, weiter in den Elastic Stack und schließlich in ein Dashboard — jede Station hat eigene Latenz- und Fehlerprofile.
Ich stelle mir das gerne wie ein Wasserleitungssystem vor. Kafka ist der Stausee. Logstash ist die Kläranlage. Elasticsearch ist der Wasserturm. Wenn die Kläranlage zu klein dimensioniert ist, hilft der größte Stausee nichts.
Wie bereiten Sie die technische Umgebung vor?
Sie benötigen einen Linux-Server mit mindestens 8 GB RAM, Java 17 oder neuer, offene Ports 9092 für Kafka und 9600 für die Logstash-API — ohne diese Voraussetzungen startet keine der beiden Komponenten zuverlässig.
Die Voraussetzungen für die Installation
- Betriebssystem: Debian 12, Ubuntu 22.04 LTS oder RHEL 9.
- Java: OpenJDK 17 oder 21 (Logstash 8.x unterstützt beide).
- RAM: mindestens 8 GB für Testaufbauten, 32 GB für produktive Pipelines.
- Festplatte: SSD mit mindestens 100 GB für Kafka-Logs und persistente Queues.
- Netzwerk: Ports 9092, 9093, 2181 und 9600 erreichbar.
Die Installation von Kafka auf einem Linux-Server
Laden Sie das Kafka-Binary von der offiziellen Apache-Seite, entpacken Sie es unter /opt/kafka und starten Sie zunächst den KRaft-Modus, der ohne ZooKeeper auskommt und seit Kafka 3.3 produktionsreif ist.
Der klassische ZooKeeper-Modus funktioniert weiterhin, aber ich empfehle ihn niemandem mehr. KRaft reduziert die Anzahl der beweglichen Teile erheblich. Weniger Teile, weniger Ausfälle.
bin/kafka-storage.sh random-uuid
bin/kafka-storage.sh format -t <UUID> -c config/kraft/server.properties
bin/kafka-server-start.sh config/kraft/server.propertiesDie Installation von Logstash und die Überprüfung der Java-Version
Installieren Sie Logstash über das offizielle APT- oder YUM-Repository und prüfen Sie anschließend mit java -version, dass die JVM-Version zu den Anforderungen Ihrer Logstash-Version passt.
Die Konfiguration der Netzwerkports und der Firewall
Öffnen Sie Port 9092 für Kafka-Clients, 9093 für den Controller und 9600 für die Logstash-Monitoring-API — Letzteren nur intern, denn er liefert detaillierte Metriken ohne Authentifizierung.
Wie erstellen Sie einen Kafka-Topic für die Datenaufnahme?
Erstellen Sie den Topic mit kafka-topics.sh, wählen Sie mindestens 3 Partitionen und einen Replikationsfaktor von 2, damit ein einzelner Broker-Ausfall die Verfügbarkeit nicht beeinträchtigt.
bin/kafka-topics.sh --create \ --topic logstash-events \ --bootstrap-server localhost:9092 \ --partitions 6 \ --replication-factor 2Wie viele Partitionen und welcher Replikationsfaktor sind sinnvoll?
Die Partitionsanzahl bestimmt den maximalen Parallelismus Ihrer Konsumenten: Mehr Partitionen erlauben mehr Logstash-Worker, kosten aber mehr Dateihandles und Speicher im Broker.
| Szenario | Partitionen | Replikationsfaktor | Empfohlener Durchsatz |
|---|---|---|---|
| Entwicklung und Test | 1 | 1 | bis 5 MB/s |
| Kleine Produktion | 3 | 2 | 5–25 MB/s |
| Mittlere Produktion | 6 | 3 | 25–100 MB/s |
| Hochlast | 12+ | 3 | über 100 MB/s |
Wie konfigurieren Sie die Logstash-Pipeline für die Aufnahme aus Kafka?
Eine Logstash-Konfigurationsdatei besteht aus den drei Blöcken input, filter und output, wobei das Kafka-Input-Plugin die Verbindung zum Broker, die Consumer-Gruppe und den Codec definiert.
input { kafka { bootstrap_servers => "localhost:9092" topics => ["logstash-events"] group_id => "logstash-consumer-group" codec => "json" auto_offset_reset => "earliest" consumer_threads => 4 decorate_events => true }
}Das Feld decorate_events hängt Metadaten wie Topic, Partition und Offset an das Event. Für Debugging ist das Gold wert. Für produktive Pipelines kostet es etwas Speicher, aber ich aktiviere es fast immer.
Welche Rolle spielt die Consumer-Gruppe und der Offset?
Die Consumer-Gruppe sorgt dafür, dass jede Partition nur von einem Konsumenten gleichzeitig gelesen wird — mehrere Logstash-Instanzen mit derselben group_id verteilen die Last automatisch.
Der Offset bestimmt, ab welcher Position gelesen wird. earliest liest alles ab Anfang, latest nur neue Nachrichten. Für Backfills brauchen Sie earliest, für reine Live-Verarbeitung latest.
Wie transformieren Sie die Daten mit Logstash-Filtern?
Der Mutate-Filter bereinigt Felder, Grok extrahiert strukturierte Werte aus unstrukturiertem Text, der Date-Filter normalisiert Zeitstempel und bedingte Anweisungen leiten Events abhängig vom Inhalt weiter.
Die Bereinigung der Felder mit dem Mutate-Filter
remove_fieldlöscht überflüssige Felder wie@versionoderhost.renamebenennt Felder um, um einheitliche Schemata zu erzwingen.convertwandelt Strings in Zahlen oder Booleans um.lowercasenormalisiert Werte für Gruppierungen.stripentfernt Leerzeichen an den Rändern.
Die Handhabung der Zeitstempel mit dem Date-Filter
Der Date-Filter liest ein Zeitfeld aus dem Event und schreibt es in @timestamp — Voraussetzung für korrekte Zeitreihenanalysen im Elastic Stack.
filter { date { match => ["event_time", "ISO8601", "UNIX_MS"] target => "@timestamp" }
}Die bedingte Weiterleitung der Daten je nach Inhalt
Mit if-Blöcken können Sie Events nach Feldwerten filtern und an unterschiedliche Outputs senden — etwa Fehlerlogs an einen separaten Index und normale Ereignisse an den Standardindex.
Wie starten Sie die Pipeline und testen die Echtzeitverarbeitung?
Starten Sie Logstash mit bin/logstash -f /etc/logstash/conf.d/pipeline.conf, senden Sie Testnachrichten mit dem Kafka-Producer und prüfen Sie die Ausgabe im Zielsystem sowie in den Logstash-Logs.
echo '{"level":"info","msg":"test","event_time":"-01-15T10:00:00Z"}' | \ bin/kafka-console-producer.sh --broker-list localhost:9092 --topic logstash-eventsWorauf sollten Sie in den Logstash-Protokollen achten?
Achten Sie auf die Zeilen Pipeline started, Successfully started logstash API endpoint und auf Warnungen zu nicht erreichbaren Brokern — diese drei Meldungen decken 80 % der Startprobleme ab.
Wie optimieren Sie Leistung und Zuverlässigkeit der Pipeline?
Passen Sie die Anzahl der Worker auf die Anzahl der CPU-Kerne an, erhöhen Sie die Batch-Größe schrittweise und aktivieren Sie die persistente Queue, um Datenverluste bei Neustarts zu vermeiden.
Die Anpassung der Arbeiter und der Batch-Größe
Die Standardeinstellung von einem Worker nutzt moderne Hardware kaum aus: Setzen Sie pipeline.workers auf die Anzahl der physischen Kerne und pipeline.batch.size auf 250 bis 500.
Ich habe in eigenen Messungen gesehen, dass sich der Durchsatz durch diese zwei Änderungen oft verdoppelt. Ohne eine Zeile Code. Nur Konfiguration.
Die Verwaltung des persistenten Warteschlangenspeichers
Aktivieren Sie queue.type: persisted und setzen Sie queue.max_bytes auf mindestens 2 GB, damit Logstash bei einem Absturz keine ungelesenen Kafka-Nachrichten verliert.
Die Überwachung der Pipeline mit den Metriken von Logstash
- events.in: Anzahl der aufgenommenen Events pro Sekunde.
- events.out: Anzahl der ausgegebenen Events.
- queue.backpressure: Zeigt an, ob die Pipeline überlastet ist.
- jvm.gc.collection_time: Garbage-Collection-Zeit in Millisekunden.
- pipeline.duration: Verarbeitungszeit pro Batch.
Welche Fehler sollten Sie vermeiden?
Die häufigsten Probleme entstehen durch falsche Consumer-Gruppen, fehlende Deserialisierungs-Fehlerbehandlung, zu kleinen JVM-Heap und unzureichende Überwachung der Echtzeit-Pipeline.
Die falsche Konfiguration der Konsumentengruppe
Zwei Logstash-Instanzen mit unterschiedlichen group_id lesen dieselben Nachrichten doppelt — ein klassischer Fehler, der zu doppelten Einträgen im Analyseindex führt.
Die fehlende Behandlung von Deserialisierungsfehlern
Wenn eine Nachricht kein gültiges JSON ist, wirft der Codec einen Fehler und das gesamte Event geht verloren, sofern Sie kein dead_letter_queue_enable aktiviert haben.
Die Vernachlässigung der Speicherverwaltung der JVM
Setzen Sie -Xms und -Xmx auf denselben Wert, idealerweise 50–60 % des verfügbaren RAM, und verwenden Sie den G1GC-Garbage-Collector für gleichmäßige Pausenzeiten.
Häufig gestellte Fragen
Was ist der Unterschied zwischen dem Kafka-Eingabe-Plugin und dem Kafka-Ausgabe-Plugin in Logstash?
Das Input-Plugin liest Nachrichten aus Kafka-Topics als Konsument, das Output-Plugin schreibt Events als Produzent in Topics — beide nutzen dieselbe Client-Bibliothek, aber mit umgekehrter Datenrichtung.
Kann Logstash mehrere Kafka-Topics gleichzeitig verarbeiten?
Ja, das Feld topics akzeptiert ein Array, und jedes Topic wird als eigene Partition behandelt — die Consumer-Gruppe verteilt die Partitionen automatisch auf die verfügbaren Worker.
Wie handhabt man Nachrichten, die nicht in das JSON-Format konvertiert werden können?
Aktivieren Sie die Dead-Letter-Queue mit dead_letter_queue_enable => true, damit fehlerhafte Nachrichten separat gespeichert und später analysiert werden können, statt verloren zu gehen.
Welche Ressourcen werden für die Echtzeitverarbeitung mit Logstash und Kafka empfohlen?
Für mittlere Last empfehle ich 16 CPU-Kerne, 32 GB RAM, NVMe-SSD und getrennte Server für Kafka und Logstash — getrennte Rollen erleichtern Skalierung und Fehlersuche erheblich.
Ist es möglich, Logstash und Kafka in einem Docker-Container einzusetzen?
Ja, beide Komponenten sind offiziell als Container verfügbar, und mit Docker Compose oder Kubernetes lassen sich vollständige Pipelines reproduzierbar betreiben — achten Sie auf persistente Volumes für Kafka-Logs und Logstash-Queues.
Ich hoffe, dieser Leitfaden hilft Ihnen, Ihre Pipeline robust aufzusetzen. Fangen Sie klein an, messen Sie, und skalieren Sie erst dann. Das ist der einzige Weg, der wirklich funktioniert.
Um die Effizienz dieser Kombination zu maximieren, ist ein gezieltes Logstash Performance-Tuning für hohe Datenvolumen unerlässlich.
Die sichere Konfiguration der Logstash-Pipeline ist entscheidend, um die Integrität der Datenströme von Kafka bis zum Zielsystem zu gewährleisten.
Zudem ist es wichtig, die Logstash Pipeline Leistung zu optimieren, um den hohen Durchsatz von Kafka effizient verarbeiten zu können.
Schon als Kind war ich fasziniert von der Logik hinter Computern und der unendlichen Welt der Daten. Was als spielerische Neugier mit dem Zerlegen alter PCs begann, entwickelte sich schnell zu einer tiefen Leidenschaft für die Informatik. Heute sehe ich es als meine Berufung, komplexe digitale Themen greifbar zu …
Tous les articles de Anna Berger →
