ELK vs Loki: Kubernetes-Logging im Vergleich

TL;DR

ELK Stack (Elasticsearch, Logstash, Kibana) indiziert den gesamten Log-Text und bietet mächtige Volltextsuche, braucht aber viel RAM und Speicher. Grafana Loki indiziert nur Labels und speichert Log-Zeilen komprimiert als Chunks -- deutlich günstiger bei grossen Log-Volumen. Für Kubernetes-Cluster unter 50 Nodes ist Loki meist die bessere Wahl. ELK lohnt sich, wenn komplexe Volltext-Queries über heterogene Log-Formate gebraucht werden.

Architektur-Unterschiede

Der fundamentale Unterschied: Elasticsearch baut einen invertierten Index über jedes Wort in jeder Log-Zeile. Loki verzichtet darauf komplett.

# Loki: Labels werden indiziert, Log-Inhalt NICHT
{namespace="production", app="order-service", pod="order-service-7f8b4"}
  2026-03-10T08:14:22Z level=error msg="payment timeout after 30s" order_id=4821

# Elasticsearch: Jedes Wort wird indiziert
# "payment", "timeout", "after", "30s", "order_id", "4821" -> alle suchbar

Das hat direkte Konsequenzen. Elasticsearch braucht für 100 GB Logs ca. 130-180 GB Speicher (Index + Originaldaten). Loki speichert die gleichen 100 GB als ca. 15-25 GB komprimierte Chunks in Object Storage.

ELK Stack Architektur

Drei Kernkomponenten:

• Elasticsearch: Verteilter Suchindex auf Basis von Apache Lucene. Shards, Replicas, Cluster-Management.
• Logstash (oder FluentBit/Fluentd): Log-Collector, Parser, Transformer.
• Kibana: Web-UI für Suche, Dashboards, Alerting.

Grafana Loki Architektur

Bewusst einfacher:

• Loki: Speichert Logs als komprimierte Chunks, indiziert nur Label-Kombinationen.
• Promtail/FluentBit: Sammelt Logs, fügt Labels hinzu.
• Grafana: Unified UI für Metrics (Prometheus), Logs (Loki) und Traces (Tempo).

Loki mit Helm installieren

Die schnellste Methode für einen produktionsreifen Loki-Stack:

# Helm Repo hinzufuegen
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

# Loki im SimpleScalable-Modus deployen
helm install loki grafana/loki \
  --namespace logging --create-namespace \
  --set loki.auth_enabled=false \
  --set loki.storage.type=s3 \
  --set loki.storage.s3.endpoint=minio.logging:9000 \
  --set loki.storage.s3.bucketnames=loki-chunks \
  --set loki.storage.s3.access_key_id=loki \
  --set loki.storage.s3.secret_access_key=supersecret \
  --set loki.storage.s3.insecure=true \
  --set loki.commonConfig.replication_factor=1

Für S3-kompatiblen Storage in der Cloud (AWS S3, MinIO on-prem) entfällt die Verwaltung von Persistent Volumes komplett.

FluentBit-Konfiguration: Loki vs ELK

FluentBit ist der bevorzugte Log-Collector für Kubernetes -- leichtgewichtig (ca. 15 MB RAM) und als DaemonSet auf jedem Node.

FluentBit nach Loki

# fluent-bit-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: fluent-bit-config
  namespace: logging
data:
  output.conf: |
    [OUTPUT]
        Name        loki
        Match       kube.*
        Host        loki-gateway.logging.svc.cluster.local
        Port        80
        Labels      job=fluentbit
        Label_keys  $kubernetes['namespace_name'],$kubernetes['pod_name']
        Line_Format json
        Auto_Kubernetes_Labels on

FluentBit nach Elasticsearch

# fluent-bit-es-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: fluent-bit-config
  namespace: logging
data:
  output.conf: |
    [OUTPUT]
        Name            es
        Match           kube.*
        Host            elasticsearch-master.logging.svc.cluster.local
        Port            9200
        Index           k8s-logs
        Type            _doc
        Logstash_Format On
        Logstash_Prefix k8s
        Suppress_Type_Name On
        tls             On
        tls.verify      Off
        HTTP_User       elastic
        HTTP_Passwd     ${ES_PASSWORD}

Der wesentliche Unterschied in der Praxis: Die Loki-Konfiguration ist kürzer, weil Loki keine Index-Mappings, ILM-Policies oder Shard-Konfiguration braucht.

Vergleich: Kosten, Komplexität, Queries

Die Kostendifferenz wird bei wachsendem Log-Volumen dramatisch. Bei 1 TB/Tag Logs kostet ein ELK-Cluster schnell 8.000+ EUR/Monat an Infrastruktur, während Loki mit Object Storage bei 800-1.500 EUR bleibt.

Wann ELK, wann Loki?

ELK Stack wählen, wenn:

• Komplexe Volltext-Queries über unstrukturierte Logs nötig sind (z.B. Security-Analyse, Forensik).
• Das Team bereits Elasticsearch-Know-how hat.
• Logs auch von Nicht-Kubernetes-Systemen zentral durchsucht werden müssen.
• Sub-Sekunden-Suche über beliebige Felder geschäftskritisch ist.

Grafana Loki wählen, wenn:

• Kubernetes der primäre Workload ist und Labels natürlich vorhanden sind.
• Budget begrenzt ist oder Log-Volumen schnell wächst.
• Prometheus und Grafana bereits im Einsatz sind (einheitliche Observability-Plattform).
• Die meisten Queries nach Namespace, Pod, Container oder Log-Level filtern.

LogQL in der Praxis

# Alle Error-Logs im production Namespace der letzten Stunde
{namespace="production"} |= "error" | logfmt | level="error"

# Top 5 Pods nach Log-Volumen (Rate-Query)
topk(5, sum by (pod) (rate({namespace="production"}[5m])))

# Latenz-Pattern aus Access-Logs extrahieren
{app="nginx-ingress"} | json | duration > 500ms

LogQL ist für Kubernetes-native Workflows ausreichend. Wer aber regelmässig Queries wie payment AND (timeout OR refused) AND NOT healthcheck über Freitext braucht, wird mit Loki an Grenzen stossen.

FAQ

Kann ich von ELK auf Loki migrieren?

Ja, aber nicht als Drop-in-Replacement. Bestehende Kibana-Dashboards müssen in Grafana neu gebaut werden. Die Log-Pipeline (FluentBit/Fluentd) braucht nur eine Output-Änderung. Historische Daten lassen sich nicht direkt migrieren -- am besten beide Systeme parallel betreiben, bis die ELK-Retention abgelaufen ist.

Wie skaliert Loki bei 500+ Nodes?

Im Microservices-Modus (Ingester, Querier, Compactor als separate Deployments) skaliert Loki horizontal. Ab 500 Nodes empfiehlt sich der Microservices-Modus mit dediziertem Object Storage und mindestens 3 Ingester-Replicas.

Ist Loki DSGVO-konform einsetzbar?

Ja, wenn der Object Storage in der EU liegt. Loki selbst speichert keine Daten ausserhalb des konfigurierten Storage-Backends. Retention-Policies lassen sich per Compactor konfigurieren, um personenbezogene Daten nach definierter Frist zu löschen.

Brauche ich Logstash bei ELK noch?

Für Kubernetes-Workloads nicht zwingend. FluentBit als DaemonSet ist leichtgewichtiger und kann direkt nach Elasticsearch schreiben. Logstash lohnt sich bei komplexen Transformationen, Enrichment aus externen Quellen oder wenn Logs aus Nicht-Container-Quellen (Syslog, Filebeat) verarbeitet werden.