Betrieb & Monitoring
Elastic Stack
Der Elastic Stack (ELK) ist eine integrierte Such-, Analytics- und Observability-Plattform aus Elasticsearch, Kibana, Logstash und Beats bzw. Elastic Agent.
- Elasticsearch + Kibana + Logstash + Beats
- Logs, Observability, SIEM, APM
- Verteilte Lucene-Such-Engine
- Elastic Agent + Fleet (Beats-Nachfolger)
- SSPL + Elastic License + AGPLv3
Der Elastic Stack, oft noch „ELK“ genannt, ist eine integrierte Plattform für Suche, Analytics und Observability. Kern ist Elasticsearch als verteilte Such-Engine, ergänzt um Kibana (Visualisierung), Logstash (Datenpipeline) und Beats bzw. den neueren Elastic Agent (Daten-Shipper). Bekannt ist der Stack auch für seine wechselhafte Lizenz-Geschichte, die 2021 den OpenSearch-Fork auslöste.
Dieser Artikel erklärt die Komponenten, die Elasticsearch-Architektur mit Shards und Replicas, die Anwendungsfälle Log-Management, Observability, SIEM und APM, das Index Lifecycle Management mit Data Tiers, die Ablösung der Beats durch Elastic Agent und Fleet sowie die Lizenz-Historie von Apache über SSPL/Elastic License bis AGPLv3. Eine sachliche Abgrenzung zu OpenSearch gehört dazu.
1. Die Komponenten
Der Stack besteht aus vier (heute fünf) Bausteinen, die zusammenspielen:
- Elasticsearch verteilte Such- und Analytics-Engine auf Lucene-Basis; speichert JSON-Dokumente, durchsucht sie über einen invertierten Index und die Query DSL.
- Kibana Visualisierung und Verwaltung: Discover, Dashboards, Dev Tools, Alerting.
- Logstash serverseitige Pipeline (Input → Filter → Output); mächtig, aber JVM-basiert und ressourcenintensiv.
- Beats / Elastic Agent leichtgewichtige Shipper (Filebeat, Metricbeat u. a.); der Elastic Agent fasst sie in einem zentral über Fleet verwalteten Agent zusammen.
2. Elasticsearch-Architektur
Elasticsearch verteilt Daten über einen Cluster aus Nodes. Ein Index wird in Primary Shards aufgeteilt (jeder ist eine vollständige Lucene-Instanz), Replica Shards sind Kopien auf anderen Nodes für Ausfallsicherheit und Lese-Last. Fällt ein Node aus, wird automatisch eine Replica zum Primary befördert. Die Zahl der Primary Shards wird bei Index-Erstellung festgelegt und ist danach nicht mehr änderbar, weshalb das Shard-Sizing eine frühe und wichtige Entscheidung ist.
JVM-Heap und Shard-Sizing
Elasticsearch läuft auf der JVM: Heap höchstens etwa die Hälfte des RAM und unter rund 30 GB halten (Compressed-OOP-Grenze), Xms und Xmx gleich setzen. Empfohlene Shard-Größe etwa 10 bis 50 GB. Falsches Sharding und zu kleine Heaps sind die häufigsten Betriebsprobleme.
3. Anwendungsfälle: Logs, SIEM, APM, Suche
Klassisch ist das Log-Management: Logs per Beats/Elastic Agent sammeln, in Elasticsearch indizieren, in Kibana auswerten. Darüber hinaus deckt der Stack Observability inklusive APM (Application Performance Monitoring mit Distributed Tracing) ab, ein vollwertiges SIEM über Elastic Security mit einer Detection Engine sowie klassische Volltextsuche und zunehmend semantische/Vektorsuche. Neuere Versionen unterstützen nativ OpenTelemetry-Daten.
4. Datenmanagement: ILM und Data Tiers
Das Index Lifecycle Management (ILM) steuert den Lebenszyklus von Indizes über Phasen: Hot (aktives Schreiben/Lesen, schnelle Hardware), Warm (seltener Zugriff), Cold (kostenoptimiert) und Frozen (Searchable Snapshots, Daten primär im Objektspeicher), zuletzt Delete. Snapshots sichern Daten ohne Downtime in S3, GCS, Azure Blob oder ein gemeinsames Dateisystem. So lassen sich Speicherkosten über die Aufbewahrungsdauer steuern.
5. Lizenz-Historie
Die Lizenzlage ist der heikelste Punkt: Bis Version 7.10 standen Elasticsearch und Kibana unter Apache 2.0. Ab 7.11 (Januar 2021) wechselte Elastic auf die nicht-quelloffenen Lizenzen SSPL und Elastic License 2.0, was AWS zum OpenSearch-Fork bewog. Seit 2024 bietet Elastic zusätzlich AGPLv3 als OSI-anerkannte Open-Source-Option an, ohne die anderen beiden zu entfernen. Es gelten also drei Lizenzen parallel; welche zutrifft, hängt vom gewählten Bezug ab.
Beim Elastic Stack entscheidet oft nicht die Technik über den Einsatz, sondern die Lizenz. Drei nebeneinander gültige Lizenzen sind eine Compliance-Aufgabe, und wer Elasticsearch als Dienst für Dritte anbieten will, muss die Bedingungen sehr genau lesen.
6. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Mächtige Volltextsuche plus Analytics und Vektorsuche | Ressourcenhungrig (Elasticsearch-JVM, Logstash 4 bis 8 GB Heap) |
| Observability, SIEM und APM aus einer Datenbasis | Lizenz-Komplexität: SSPL, Elastic License, AGPLv3 parallel |
| Horizontal skalierbar über Sharding/Replikation | Cluster-Betrieb anspruchsvoll (Shard-Sizing, Rolling Upgrades) |
| Kostensteuerung über ILM und Data Tiers | SSPL/Elastic License untersagen Managed-Service-Weitergabe |
| Großes Ökosystem, OTel-native in neueren Versionen | Einige Funktionen erst in kostenpflichtigen Subscriptions |
Häufige Fragen zu Elastic Stack
Teils. Bis Version 7.10 war er Apache-2.0-lizenziert, danach SSPL und Elastic License 2.0 (beide nicht OSI-quelloffen). Seit 2024 bietet Elastic zusätzlich AGPLv3 als echte Open-Source-Option an. Es gelten also drei Lizenzen nebeneinander, und welche greift, hängt vom gewählten Bezug ab.
Technisch sind beide sehr ähnlich (gemeinsamer Ursprung bis 7.10). Der Elastic Stack ist funktional oft etwas voraus, hat aber die komplexere Lizenzlage. OpenSearch steht durchgehend unter Apache 2.0 und unter der Linux Foundation, was es bei Lizenzbedenken und Managed-Service-Szenarien attraktiv macht.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Elastic Stack im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.