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

Verwandte Technologien im Techradar