Begriff

ELK Stack

DevOps Monitoring S3

2 Quellen 0 Lernpfade 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Deine Server schreiben Millionen von Logzeilen. "Error in Zeile 5..." Niemand kann das lesen (zu viel, zu schnell, verteilt auf 50 Server). Der ELK Stack ist der Staubsauger und das Mikroskop für Logs.

Logstash (Der Schlauch): Saugt Logs von überall auf und putzt sie ("Hier ist das Datum, da ist der Error").
Elasticsearch (Der Speicher): Speichert sie in einer riesigen Suchmaschine (wie Google, aber für Logs).
Kibana (Die Brille): Ein schönes Dashboard. "Zeig mir alle Errors der letzten Stunde als rote Balken."

Merksatz: Eine Sammlung von drei Open-Source-Produkten (Elasticsearch, Logstash, Kibana), die verwendet werden, um Protokolldaten aus verschiedenen Quellen zu sammeln, zu durchsuchen und zu visualisieren.

Wenn der Chef fragt: "Warum war die Seite gestern langsam?" Du öffnest Kibana. Suchst: service="checkout" AND duration > 5000ms. Kibana zeigt dir sofort die 5 Log-Einträge, wo die Datenbank timeoutete. Ursache gefunden in Sekunden statt Stunden.

1. Lucene Segments und Immortality

Unter der Haube von Elasticsearch tickt Apache Lucene. Die Datenstruktur für Suchen ist nicht veränderlich (Immutable). Einmal geschriebene Log-Indizes (Segments) können niemals direkt editiert werden (Updates in ES sind in Realität Löschen + Neuerstellen, was CPU raubt). Da Milliarden von Logzeilen reinkrachen, erzeugt Lucene tausende winzige Such-Graphen. Asynchron im Hintergrund läuft der "Merge Prozess" an, verschmilzt kleine Segmente zu massiven Blöcken und markiert Tombstone-Daten (gelöschte Files) endgültig zum Flush. Falsch konfiguriertes Indexing (zu wenig I/O) führt zum "Merge Hell", in dem die CPU stirbt, bevor die Daten abfragbar werden.

2. Time-Series Data Streams (ILM)

Früher crashte der ELK Stack, weil Administratoren vergaßen, 4 Jahre alte Logs zu löschen. Die Heaps (RAM) der Java-Nodes explodierten (OOM). Modernes ELK managt Logs via Data Streams und ILM (Index Lifecycle Management). Phase 1 (Hot): Heute geschriebene Logs auf SSD-Platten für brutale Schreib-Performance. Phase 2 (Warm): Nach 30 Tagen verschiebt ES sie automatisch auf billige HDDs und setzt sie "Read-Only". Phase 3 (Cold/Frozen): Nach 6 Monaten löscht ES die Logs oder schiebt Snapshots ins AWS S3, aus dem es direkt ohne Re-Indizierung gesucht werden kann (Searchable Snapshots).

3. Grok Filter und CPU-Starvation

Logstash ist der mächtigste, aber gefährlichste Punkt in der Kette. Um unstrukturierten Text (Nginx-Log) zu parsen, nutzt man den Grok Filter (verkettete Regex-Muster). Ein schlecht geschriebenes Regex (Catastrophic Backtracking) in einem Grok-Filter bringt den Java-Heap von Logstash bei einem einzigen komischen Logzeilen-Ausreißer zum Stillstand. Die CPU nagelt auf 100%, der Pipeline-Stau (Backpressure) schwappt zurück zu Filebeat, der Queue-Buffer läuft über, und Server fangen an, Logs in den Müll (Dev/Null) zu droppen. Deshalb wandern heute viele Teams von fernen Grok-Pipelines zum simplen "Fluent Bit" plus strukturiertem JSON-Logging am Ursprung ab.

Quick-Check

Ist es kostenlos?
Jein. Der Kern ist "Open" (aber spezielle Lizenz, nicht ganz Open Source). Viele Hosting-Features (Security, ML) kosten Geld (Elastic Cloud). Amazon hat sich abgespalten (OpenSearch), weil sie Streit um die Lizenz hatten.
Nur für Logs?
Nein. Auch für Volltextsuche im Webshop ("Kunde sucht 'iPhon'"). Elasticsearch ist extrem gut in "Meinten Sie iPhone?".
Unterschied zu Splunk?
Splunk ist teuer und proprietär (Enterprise). ELK ist "gratis" (wenn man es selbst hostet) und flexibler, aber mehr Arbeit.