Was ist Log-Management und warum ist es wichtig?
In modernen Infrastrukturen – ob auf Kubernetes, in der Cloud oder im Homelab – entstehen täglich Gigabytes an Log-Daten. Ohne ein zentrales Log-Management-System verliert man schnell den Überblick. Fehler bleiben unentdeckt, Debugging wird zur Detektivarbeit, und Compliance-Anforderungen lassen sich kaum erfüllen.
Die drei populärsten Open-Source-Lösungen für zentrales Log-Management sind Grafana Loki, der ELK Stack (Elasticsearch, Logstash, Kibana) und Graylog. Jede hat ihre Stärken – und ihre Grenzen.
Grafana Loki: Der schlanke Kubernetes-Native
Loki wurde 2018 von Grafana Labs entwickelt und verfolgt eine radikale Idee: keine Volltextindexierung der Log-Inhalte. Stattdessen werden Logs nur anhand von Labels indiziert (ähnlich wie Prometheus Metriken behandelt). Die eigentlichen Log-Zeilen werden in einem Objektspeicher (z.B. S3, MinIO) abgelegt.
Stärken von Loki
- Minimaler Ressourcenbedarf: Kein aufwändiger Index – deutlich günstigerer Betrieb als ELK
- Native Kubernetes-Integration: Mit Promtail oder Alloy läuft die Log-Erfassung out-of-the-box
- Nahtlose Grafana-Integration: Logs, Metriken und Traces in einem Dashboard
- LogQL: Mächtige Abfragesprache ähnlich PromQL
- Skalierbar: Horizontale Skalierung über Microservice-Modus möglich
Schwächen von Loki
- Keine Volltextsuche: Suche im Log-Inhalt erfordert teure Grep-ähnliche Abfragen über alle Daten
- Steile Lernkurve: LogQL und das Label-Modell sind anfangs ungewohnt
- UI begrenzt: Grafana Explore reicht für viele Fälle, ist aber kein vollwertiges SIEM-Tool
- Cold Queries langsam: Abfragen über große Zeiträume ohne Label-Filter können sehr langsam sein
Ressourcenbedarf (minimal)
| Komponente | RAM | CPU | Storage |
|---|---|---|---|
| Loki (Monolith) | 512 MB – 2 GB | 0,5–2 Cores | Objektspeicher |
| Promtail (pro Node) | 50–100 MB | minimal | – |
| Grafana | 256 MB – 1 GB | 0,5 Core | – |
ELK Stack: Der Platzhirsch mit Volltext-Power
Der ELK Stack – bestehend aus Elasticsearch (Speicher & Suche), Logstash (Ingest & Transformation) und Kibana (Visualisierung) – ist der etablierte Standard für Enterprise-Log-Management. Moderne Setups ersetzen Logstash oft durch den leichtgewichtigeren Beats-Client oder Elastic Agent.
Stärken des ELK Stacks
- Leistungsstarke Volltextsuche: Jede Log-Zeile ist vollständig indiziert und durchsuchbar
- Mächtiges Ökosystem: Filebeat, Metricbeat, APM Server, Security Analytics (SIEM)
- Kibana Dashboards: Professionelle Visualisierungen und vorgefertigte Dashboards
- Alerting & Machine Learning: Eingebaute Anomalieerkennung (teilweise mit Enterprise-Lizenz)
- Reife & Community: Über 10 Jahre Entwicklungsgeschichte
Schwächen des ELK Stacks
- Hoher Ressourcenbedarf: Elasticsearch braucht viel RAM (min. 4–8 GB für Produktion)
- Lizenz-Komplexität: Elastic NV wechselte 2021 zu SSPL/Elastic License 2.0 – kein echtes Open Source mehr
- Operativer Aufwand: Shard-Management, Cluster-Health, Index-Lifecycle-Management
- Kosten: Die Self-Hosted-Variante ist kostenlos, aber das Elastic Cloud-Angebot teuer
Ressourcenbedarf (typisch, 3-Node-Cluster)
| Komponente | RAM | CPU | Storage |
|---|---|---|---|
| Elasticsearch (3x) | 4–16 GB each | 2–8 Cores | SSD, 3× Retention-Größe |
| Logstash | 1–4 GB | 1–2 Cores | – |
| Kibana | 1–2 GB | 1 Core | – |
Graylog: Der Mittelweg mit gutem UI
Graylog ist eine europäische Open-Source-Lösung (ursprünglich aus Hamburg), die auf Elasticsearch/OpenSearch als Backend setzt, aber eine eigene Ingestion-Schicht und ein deutlich benutzerfreundlicheres UI mitbringt.
Stärken von Graylog
- Intuitives UI: Streams, Alerts und Dashboards einfacher zu konfigurieren als Kibana
- GELF-Format: Eigenes strukturiertes Log-Format mit gutem Ökosystem
- Open Source: Graylog Open ist wirklich kostenlos (SSPL, aber keine versteckten Features)
- Alerting: Einfachere Alert-Konfiguration als in Kibana (Open-Version)
- Inputs-System: Syslog, GELF, Beats, AWS S3, Kafka – alles direkt eingebaut
Schwächen von Graylog
- Elasticsearch-Abhängigkeit: Graylog braucht Elasticsearch/OpenSearch als Backend – höherer Gesamtbedarf
- MongoDB: Für Metadaten wird MongoDB benötigt – ein weiterer Dienst zu betreiben
- Community kleiner: Weniger Tutorials und Community-Ressourcen als ELK
- Enterprise Features: Einige wichtige Features (LDAP, Archivierung, Compliance) nur in Graylog Operations/Security
Ressourcenbedarf (typisch)
| Komponente | RAM | CPU |
|---|---|---|
| Graylog Server | 2–4 GB | 2 Cores |
| Elasticsearch/OpenSearch | 4–8 GB | 2–4 Cores |
| MongoDB | 512 MB – 2 GB | 1 Core |
Direktvergleich: Loki vs. ELK Stack vs. Graylog
| Kriterium | Grafana Loki | ELK Stack | Graylog |
|---|---|---|---|
| Volltextsuche | ❌ Label-basiert | ✅ Vollständig | ✅ Vollständig |
| Ressourcenbedarf | ✅ Sehr gering | ❌ Hoch | ⚠️ Mittel |
| Kubernetes-Native | ✅ Ja | ⚠️ Möglich | ⚠️ Möglich |
| Dashboards | ✅ Grafana | ✅ Kibana | ✅ Graylog UI |
| Alerting | ✅ Grafana Alerts | ✅ (teils Enterprise) | ✅ Open verfügbar |
| Self-Hosting | ✅ Sehr einfach | ⚠️ Komplex | ⚠️ Mittel |
| Lizenz | ✅ AGPL-3.0 | ⚠️ Elastic License 2.0 | ⚠️ SSPL |
| Setup-Aufwand | Gering | Hoch | Mittel |
| Compliance/SIEM | ❌ Begrenzt | ✅ Enterprise | ✅ Graylog Security |
| Streaming Ingest | ✅ Kafka möglich | ✅ Gut | ✅ Kafka eingebaut |
Wann sollte ich was einsetzen?
Nimm Grafana Loki, wenn…
- du bereits Grafana für Metriken nutzt (Prometheus-Stack)
- du auf Kubernetes oder Docker/Podman arbeitest
- dein Budget begrenzt ist (Homelab, Startups, kleine Teams)
- du primär Container-Logs aus strukturierten Quellen aggregierst
- Volltextsuche in Log-Inhalten weniger kritisch ist
Typisches Setup: Kubernetes + Promtail → Loki → Grafana
Nimm ELK Stack, wenn…
- du mächtige Volltextsuche über alle Log-Felder brauchst
- du ein großes Enterprise-Environment mit vielen Compliance-Anforderungen hast
- du Elastic APM für Application Performance Monitoring nutzen willst
- du bereit bist, mehr Ressourcen und operativen Aufwand zu investieren
Typisches Setup: Beats → Elasticsearch → Kibana (oder Elastic Cloud)
Nimm Graylog, wenn…
- du Volltext-Log-Suche willst, aber Kibana zu komplex findest
- du einfaches Alerting ohne Enterprise-Features brauchst
- du Syslog von Netzwerkgeräten, Firewalls oder Legacy-Systemen aggregierst
- du ein Team mit wenig ELK-Erfahrung hast
Typisches Setup: Syslog/GELF → Graylog → OpenSearch-Backend
Praktische Empfehlung: Der Stack für verschiedene Szenarien
Homelab/Kleinunternehmen (< 50 GB Logs/Monat): → Loki + Grafana — minimaler Overhead, perfekt für Container-Logs
Mittelgroßes DevOps-Team (50–500 GB/Monat): → Graylog + OpenSearch — gute Balance aus Features und Aufwand, oder Loki wenn bereits Grafana im Einsatz
Enterprise / Security Operations Center: → ELK Stack (Elastic Security) oder Graylog Security — vollständige SIEM-Features, Compliance, ML-Alerting
Migration zwischen den Tools
Ein Wechsel ist möglich, aber aufwändig:
- Von ELK zu Loki: Verlust der Volltextindizierung, aber massiv reduzierter Ressourcenbedarf. Tool:
elk2loki-Skripte, historische Daten meist nicht migrierbar - Von ELK zu Graylog: Einfacher, da Graylog auf Elasticsearch/OpenSearch aufsetzt. Dashboards müssen neu gebaut werden
- Von Graylog zu Loki: Ähnlich wie ELK-Migration – Architekturwechsel, historische Daten neu laden
Fazit: Der richtige Stack hängt von deinen Anforderungen ab
Es gibt keinen universellen Gewinner:
- Loki gewinnt bei Ressourceneffizienz und Kubernetes-Integration
- ELK Stack gewinnt bei Volltext-Suchkraft und Enterprise-Features
- Graylog gewinnt bei Benutzerfreundlichkeit und einfachem Alerting
Für die meisten DevOps-Teams, die bereits auf Grafana setzen, ist Loki die pragmatische Wahl. Wer auf vollständige Log-Durchsuchbarkeit und ein gutes UI angewiesen ist, ohne den ELK-Overhead zu wollen, sollte Graylog + OpenSearch ernsthaft in Betracht ziehen.
Weiterführende Artikel
- Warum ich Grafana + Loki statt ELK-Stack nutze
- OpenTelemetry: Observability-Standard für moderne Infrastrukturen
- Prometheus vs. Datadog: Monitoring-Tools im Vergleich