Betrieb & Monitoring
Grafana Loki
Grafana Loki ist ein skalierbares Log-Aggregationssystem, das nur Label-Metadaten indiziert und Logs komprimiert im Objektspeicher ablegt, günstiger als Volltext.
- Log-Aggregation, nur Label-Index
- Komprimierte Chunks im Objektspeicher
- LogQL (an PromQL angelehnt)
- Günstig und horizontal skalierbar
- AGPLv3 (seit 2021)
Grafana Loki ist ein Log-Aggregationssystem von Grafana Labs, das oft als „Prometheus für Logs“ beschrieben wird. Sein entscheidender Unterschied zu Elasticsearch/OpenSearch: Loki indiziert nicht den Log-Inhalt, sondern nur Metadaten in Form von Labels. Der eigentliche Text wird komprimiert als Chunks in günstigen Objektspeicher gelegt. Das macht Loki deutlich ressourcen- und kostensparender, verschiebt aber die Suche von „Volltext-Index“ zu „grep-artigem Filtern“.
Dieser Artikel erklärt das Label-statt-Volltext-Prinzip, die Speicherung in Objektspeicher, die Abfragesprache LogQL, die Komponenten und Deployment-Modi, die Agenten (Alloy als Promtail-Nachfolger), Structured Metadata und Bloom-Filter, die Einordnung im LGTM-Stack sowie das zentrale Betriebsrisiko Kardinalität. Visualisiert wird über Grafana.
1. Label-Index statt Volltext
Loki indiziert ausschließlich Labels (Schlüssel-Wert-Paare) und den Zeitstempel, nicht den Inhalt der Log-Zeilen. Alle Zeilen mit identischer Label-Kombination bilden einen Stream und werden als komprimierter Chunk gespeichert. Weil der teure invertierte Volltext-Index entfällt, braucht Loki viel weniger Speicher und Rechenleistung als Elasticsearch/OpenSearch. Der Preis: Eine unspezifische Suche scannt die Chunks sequenziell (grep-artig), statt sie über einen Index sofort zu finden.
2. Speicherung im Objektspeicher
Loki legt zwei Dateitypen ab: einen schlanken Index (Labels auf Speicherorte) und die Chunks (komprimierte Log-Zeilen). Beides landet in günstigem Objektspeicher: S3, GCS, Azure Blob oder lokales Dateisystem. Das empfohlene Index-Format ist TSDB (aus Prometheus übernommen), das ältere BoltDB-Format gilt als veraltet. Über Commodity-Objektspeicher wird Langzeit-Aufbewahrung von Logs wirtschaftlich darstellbar.
3. LogQL
LogQL ist an PromQL angelehnt. Jede Abfrage beginnt mit einem Stream-Selektor in geschweiften Klammern (Pflicht) und kann eine Pipeline aus Filtern anhängen. Operatoren sind |= (enthält), != (enthält nicht), |~ (Regex) und !~. LogQL kann nicht nur Log-Zeilen zurückgeben, sondern aus ihnen auch Metriken ableiten (etwa Raten und Zählungen über Zeit).
LogQL: Fehler-Rate aus nginx-Logs der Produktion
sum(rate({app="nginx", env="prod"} |= "error" [5m]))4. Komponenten und Deployment-Modi
Alle Komponenten stecken in einer Binärdatei, die über ein -target-Flag in verschiedenen Modi startet. Die Kernteile sind Distributor (nimmt Logs an, validiert, verteilt), Ingester (puffert und schreibt Chunks), Querier (führt LogQL aus), Query Frontend (teilt große Abfragen, cacht) und Compactor (Index-Konsolidierung, Retention).
- Monolithic alle Komponenten in einem Prozess, geeignet bis etwa 20 GB Logs/Tag.
- Simple Scalable getrennt nach read/write/backend; skaliert bis in den TB-Bereich (als veraltet markiert, soll mit Loki 4.0 entfernt werden).
- Microservices jede Komponente als eigener Prozess; höchste Skalierbarkeit, vor allem für Kubernetes.
5. Agenten, Structured Metadata und Kardinalität
Logs liefern Agenten an Loki. Der frühere Standard-Agent Promtail ist abgekündigt; Nachfolger ist Grafana Alloy (eine OpenTelemetry-Collector-Distribution). Daneben funktionieren Fluent Bit, Fluentd und der OTLP-Empfang. Structured Metadata erlaubt es, hochkardinale Felder (Trace-IDs, Pod-Namen) an Zeilen zu hängen, ohne sie zu indizieren, und ist Voraussetzung für die experimentellen Bloom-Filter, die gezielte Suchen über große Zeiträume beschleunigen.
Kardinalität bricht Loki
Der häufigste Loki-Fehler ist hohe Label-Kardinalität: Wer veränderliche Werte (IP-Adressen, User-IDs, Zeitstempel) als Labels verwendet, erzeugt einen riesigen Index und unzählige winzige Chunks. Faustregel: wenige, stabile Labels (cluster, namespace, app, env), hochkardinale Werte als Structured Metadata statt als Label.
Loki ist günstig, aber nicht anspruchslos. Der gesamte Kostenvorteil hängt an konsequenter Label-Disziplin; wer Labels wie Volltext-Felder behandelt, verliert den Vorteil und destabilisiert das System.
6. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Sehr günstig: Label-Index plus Objektspeicher | Kein Volltext-Index: unspezifische Suchen sind langsamer |
| LogQL nah an PromQL, geringe Einstiegshürde für Prometheus-Teams | Empfindlich gegenüber hoher Label-Kardinalität |
| Native Grafana-Integration, Teil des LGTM-Stacks | Bloom-Filter (gezielte Suche) noch experimentell |
| Horizontal skalierbar, OTLP-Empfang nativ | Simple-Scalable-Modus veraltet, Entfernung mit Loki 4.0 geplant |
| Langzeit-Logs wirtschaftlich über Commodity-Storage | Promtail abgekündigt: Migration auf Alloy nötig |
Häufige Fragen zu Grafana Loki
Weil Loki nur Labels indiziert, nicht den Log-Inhalt. Der teure invertierte Volltext-Index entfällt, und die Logs liegen komprimiert in günstigem Objektspeicher. Das spart Speicher und RAM erheblich, geht aber zulasten der schnellen Volltextsuche.
Nur eingeschränkt. Loki filtert über Labels und scannt dann die passenden Chunks sequenziell (grep-artig). Für gezielte Volltextsuche über beliebige Felder und große Zeiträume ist ein Volltext-System wie OpenSearch besser; die experimentellen Bloom-Filter mildern das nur für spezielle Fälle.
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
Grafana Loki 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.