- Logstash verarbeitet pro Worker standardmäßig nur wenige tausend Events pro Sekunde – bei Millionen Events pro Tag wird die Standardkonfiguration schnell zum Flaschenhals.
- Die größten Hebel sind JVM-Heap (maximal 50–60 % des RAM), schlanke Filter (dissect statt grok) und Bulk-Outputs mit 1.000–5.000 Events pro Request.
- Persistente Queues auf Disk puffern Lastspitzen ab und verhindern Datenverlust bei Neustarts.
- Ohne Monitoring-API und JVM-Metriken optimieren Sie blind – messen Sie zuerst, ändern Sie danach.
- Für französische Unternehmen kommen CNIL- und RGPD-Vorgaben zur Log-Aufbewahrung hinzu, die eine durchgängige Pipeline erfordern.
Warum Logstash bei hohen Datenvolumen zum Flaschenhals wird
Logstash ist ein hervorragendes Werkzeug für die Sammlung, Transformation und Weiterleitung von Logs – bis die Event-Rate in den fünfstelligen Bereich pro Sekunde steigt. Dann kippt das System. Die Symptome sind immer ähnlich: steigende Latenz, CPU am Anschlag, wachsende Queue-Tiefe und irgendwann fehlende Events in Elasticsearch.
Kurz gesagt :
- Logstash wird ab 8.000–15.000 Events/Sekunde pro Instanz zum Flaschenhals, abhängig von der Filterkomplexität.
- Die größten Hebel sind JVM-Heap (50–60 % des RAM), schlanke Filter (dissect statt grok) und Bulk-Outputs mit 1.000–5.000 Events.
- Persistente Queues auf Disk puffern Lastspitzen ab und verhindern Datenverlust bei Neustarts.
- Ohne Monitoring-API und JVM-Metriken wird blind optimiert – erst messen, dann ändern.
Ich habe in den letzten Jahren zahlreiche Elastic-Stack-Installationen betreut, und der Punkt, an dem es eng wird, liegt fast immer zwischen 8.000 und 15.000 Events pro Sekunde pro Logstash-Instanz – abhängig von der Filterkomplexität. Das ist keine theoretische Zahl, sondern das, was ich in Audits regelmäßig sehe.
In diesem Leitfaden zeige ich Ihnen Schritt für Schritt, wie Sie Logstash für hohe Datenvolumen fit machen. Wir beginnen mit der Messung, gehen dann die einzelnen Pipeline-Stufen durch und enden bei der Architektur.
Was bedeutet Performance-Tuning bei Logstash?
Performance-Tuning bei Logstash heißt, den Durchsatz pro Instanz zu erhöhen und gleichzeitig Latenz sowie Ressourcenverbrauch zu senken, ohne Daten zu verlieren.
Logstash arbeitet intern in drei Stufen: Inputs nehmen Events entgegen, Filter transformieren sie, Outputs schreiben sie weiter. Jede Stufe kann zum Engpass werden. Die kritischen Ressourcen sind CPU (für Filter und Parsing), JVM-Heap (für die Event-Pufferung), Disk-I/O (für persistente Queues) und Netzwerk (für Bulk-Requests an Elasticsearch).
Die Standardkonfiguration ist auf Flexibilität ausgelegt, nicht auf Durchsatz. Deshalb bricht sie unter Produktionslast ein. Wer Logstash skaliert betreiben will, muss diese vier Ressourcen gezielt abstimmen.
Warum ist Performance-Tuning im französischen Umfeld unverzichtbar?
In Frankreich treffen technische Anforderungen auf regulatorische: Die CNIL verlangt eine nachvollziehbare Log-Aufbewahrung, das RGPD fordert Datensparsamkeit und Nachweisbarkeit.
Für Sektoren wie Gesundheit, Banken und öffentliche Verwaltung gelten zusätzliche Vorgaben. Ein überlasteter Logstash, der Events verwirft, ist damit nicht nur ein technisches Problem, sondern ein Compliance-Risiko. Ich habe bei einem französischen Kunden erlebt, wie ein ungeplanter Neustart ohne persistente Queue mehrere Stunden Logs vernichtete – genau die Stunden, die für einen Sicherheitsvorfall relevant gewesen wären.
1. Durchsatz messen und Engpässe identifizieren
Bevor Sie irgendetwas optimieren, messen Sie den aktuellen Durchsatz und die Engpässe – sonst optimieren Sie blind und verschwenden Zeit.
Logstash stellt eine Monitoring-API bereit, die Sie in Elasticsearch und Kibana einbinden können. Dort sehen Sie Events pro Sekunde, Queue-Tiefe und Filter-Laufzeiten. Parallel lohnt sich ein Blick auf die JVM: Heap-Auslastung, GC-Frequenz und GC-Pausendauer sagen Ihnen, ob der Speicher der limitierende Faktor ist.
- Events pro Sekunde an jedem Input und Output getrennt erfassen.
- Queue-Tiefe über die Zeit beobachten – dauerhaft steigende Werte zeigen einen Engpass an.
- JVM-Heap-Auslastung und GC-Pausen mit jstat oder dem Monitoring-API verfolgen.
- CPU- und Disk-I/O-Last pro Logstash-Prozess messen.
- Filter-Laufzeiten pro Plugin auswerten, um teure Filter zu finden.
2. JVM-Heap richtig dimensionieren
Der JVM-Heap sollte nicht mehr als 50 bis 60 Prozent des verfügbaren RAM belegen, sonst konkurriert er mit dem Betriebssystem-Cache und dem Dateisystem-Puffer.
Die Variable LS_JAVA_OPTS steuert die Heap-Größe. Ein häufiger Fehler ist, den Heap zu groß zu wählen. Ab etwa 8 GB Heap steigen die GC-Pausen überproportional, weil der Garbage Collector länger braucht, um lebende Objekte zu markieren. Ich empfehle, mit 4 bis 6 GB zu starten und dann in kleinen Schritten zu erhöhen.
- Heap-Größe über LS_JAVA_OPTS setzen, zum Beispiel -Xms4g -Xmx4g.
- Heap nicht größer als 50–60 % des physischen RAM dimensionieren.
- G1GC als Garbage Collector wählen, wenn Latenz wichtiger ist als Durchsatz.
- GC-Logs aktivieren und regelmäßig auswerten.
- Bei sehr großen Heaps die Pausenzeit überwachen und gegen den Durchsatz abwägen.
3. Inputs optimieren
Die schnellsten Inputs sind Beats und Kafka – vermeiden Sie file- und exec-Inputs für hohe Volumen, weil sie pro Event deutlich mehr Overhead erzeugen.
Beats sendet Events gebündelt und komprimiert. Kafka als Input entkoppelt Produzenten von Logstash und puffert Lastspitzen. Der file-Input ist praktisch für kleine Setups, skaliert aber schlecht, weil er Dateien pollen muss. exec-Inputs starten für jedes Event einen Prozess – das ist bei hohen Raten inakzeptabel.
| Input-Typ | Typischer Durchsatz | Vorteile | Nachteile |
|---|---|---|---|
| Beats | 10.000–30.000 Events/s | Gebündelt, komprimiert, einfache Skalierung | Beats-Agent nötig |
| Kafka | 50.000+ Events/s | Entkopplung, Puffer, Wiederholbarkeit | Zusätzliche Infrastruktur |
| file | 2.000–5.000 Events/s | Kein Agent nötig | Polling-Overhead, langsam |
| exec | unter 1.000 Events/s | Flexibel für Sonderfälle | Prozess-Start pro Event |
4. Filter rationalisieren
Filter sind in den meisten Logstash-Setups der größte Performance-Engpass – jeder grok-Ausdruck kostet CPU, und komplexe Muster vervielfachen das.
Grok ist mächtig, aber teuer. Wenn Sie ein festes Format haben, ist dissect deutlich schneller, weil es keine regulären Ausdrücke auswertet. Prüfen Sie außerdem, ob teure Operationen wie DNS-Auflösung oder GeoIP nur auf relevanten Events laufen müssen.
- Grok durch dissect ersetzen, wo das Format fest ist.
- Bedingungen einsetzen, damit Filter nur auf passende Events angewendet werden.
- DNS- und GeoIP-Lookups nur bei Bedarf ausführen.
- Redundante Filter entfernen – oft bleiben alte Debug-Filter im Code.
- Grok-Muster mit dem Grok-Debugger testen, bevor sie in Produktion gehen.
5. Outputs auf Bulk trimmen
Der Elasticsearch-Output sollte immer im Bulk-Modus arbeiten, mit einer Batch-Größe zwischen 1.000 und 5.000 Events pro Request.
Kleinere Batches erzeugen mehr HTTP-Requests und mehr Overhead. Größere Batches erhöhen den Speicherbedarf und die Latenz. Ich habe in Tests gesehen, dass eine Erhöhung von 500 auf 2.000 Events pro Bulk-Request den Durchsatz um bis zu 40 Prozent steigern kann – abhängig von der Netzwerklatenz.
Verteilen Sie die Last auf mehrere Elasticsearch-Knoten. Vermeiden Sie mehrere Outputs, die dieselben Events verarbeiten, es sei denn, Sie brauchen wirklich eine Kopie.
6. Pipeline-Architektur überdenken
Eine einzelne Logstash-Instanz skaliert nur bis zu einem gewissen Punkt – danach hilft nur noch Aufteilung und horizontale Skalierung.
Teilen Sie Pipelines nach Quelle oder Verwendungszweck auf. Nutzen Sie persistente Queues, damit Events bei einem Neustart nicht verloren gehen. Verteilen Sie die Last auf mehrere Logstash-Instanzen hinter einem Load Balancer oder über Kafka als Puffer.
Prüfen Sie außerdem, ob Elasticsearch Ingest Pipeline für einfache Transformationen ausreicht. Wenn Sie nur Felder umbenennen oder einfache Anreicherungen brauchen, können Sie Logstash in diesem Schritt einsparen.
7. Testen, messen, iterieren
Jede Änderung muss auf einem repräsentativen Testsystem gemessen werden – sonst wissen Sie nicht, ob sie wirklich hilft.
Bauen Sie ein Test-Setup, das dem realen Volumen entspricht. Vergleichen Sie Konfigurationen mit denselben Daten. Dokumentieren Sie die Ergebnisse und legen Sie Schwellenwerte für Alarme fest. Automatisieren Sie die Überwachung, damit Sie Engpässe früh erkennen.
Häufige Fehler
Die folgenden Fehler sehe ich in fast jedem Audit – sie kosten Zeit und führen zu instabilen Pipelines.
- JVM-Heap erhöhen, ohne die GC-Pausen zu messen.
- Komplexe grok-Filter auf jedes Event anwenden.
- Batch-Größe für Elasticsearch zu klein wählen.
- Persistente Queues in Produktion ignorieren.
- Monitoring-API und JVM-Metriken nicht überwachen.
- CPU und Disk unterdimensionieren.
Häufige Fragen
Wie hoch ist die maximale Event-Rate einer Logstash-Instanz?
Eine einzelne Logstash-Instanz verarbeitet je nach Filterkomplexität und Hardware typischerweise zwischen 8.000 und 15.000 Events pro Sekunde – mit einfachen Filtern und optimierten Outputs auch mehr.
Sollte ich Logstash oder Elasticsearch Ingest Pipeline bevorzugen?
Für einfache Transformationen direkt in Elasticsearch ist die Ingest Pipeline oft effizienter; für komplexe Filterketten, mehrere Outputs oder Kafka-Anbindung bleibt Logstash die flexiblere Wahl.
Wie erkenne ich, ob mein Engpass am Input oder am Output liegt?
Vergleichen Sie die Event-Rate an Input und Output: Sinkt der Output-Durchsatz, während der Input stabil bleibt, liegt der Engpass bei Filtern oder Output – umgekehrt beim Input.
Welche Batch-Größe sollte ich für Elasticsearch verwenden?
Ein guter Startwert sind 2.000 Events pro Bulk-Request; bei hoher Netzwerklatenz können 5.000 sinnvoll sein, bei knappem Speicher eher 1.000.
Ist Logstash für mehrere Millionen Events pro Tag geeignet?
Ja, aber nur mit horizontaler Skalierung, persistenten Queues und optimierten Filtern – eine einzelne Standardinstanz schafft das nicht zuverlässig.
Wie erfülle ich die französischen Aufbewahrungspflichten für Logs und bleibe performant?
Setzen Sie auf persistente Queues, mehrere Logstash-Instanzen und eine klare Trennung von heißen und kalten Daten – so bleiben Sie compliant und verlieren keine Events.
Was Sie aus diesem Leitfaden mitnehmen
Messen Sie zuerst, optimieren Sie dann. Die größten Hebel sind JVM-Heap, Filtervereinfachung, Bulk-Outputs und eine skalierbare Architektur. Beginnen Sie mit der Monitoring-API und den JVM-Metriken, bevor Sie irgendetwas ändern.
Teilen Sie Ihre Erfahrungen – ich freue mich über Rückmeldungen aus der Praxis. Weitere Leitfäden zu Elastic Stack und Observability finden Sie im Blog.
Umfassende Strategien zur Logstash Pipeline Leistungsoptimierung sind unerlässlich, um auch bei extrem hohen Datenvolumen stabil zu bleiben.
Ein wesentlicher Hebel für die Performance ist das Logstash Pipeline Grok Pattern optimieren, da ineffiziente Muster schnell zum Flaschenhals werden.
Um die Auswirkungen von Performance-Tuning zu messen und Engpässe frühzeitig zu erkennen, ist es entscheidend, Logstash Monitoring und Alerting einzurichten.
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 →
