Kubernetes Observability Stack 2026 — Von Logs zu OpenTelemetry

Die drei Säulen der Observability — Logs, Metriken, Traces — waren ein guter Anfang. Aber im Jahr 2026, wenn der durchschnittliche Kubernetes-Cluster Hunderte von Gigabytes an Telemetriedaten täglich generiert, reichen sie nicht mehr aus. Sie brauchen Signalkorrelation, eBPF-basierte Instrumentierung ohne Code, AI-gestütztes Alerting und vor allem: Kontrolle über die Kosten, die Ihr Observability-Stack verursacht. Dieser Artikel ist ein Leitfaden zum modernen Observability-Stack für Kubernetes — vom OpenTelemetry Collector Pipeline über den LGTM-Stack bis hin zu eBPF und AI Alerting.

1. Warum drei Säulen nicht ausreichen¶

Das Konzept der „Three Pillars of Observability” — Logs, Metriken, Traces — definierte 2018 die Richtung der gesamten Branche. Doch die Praxis hat gezeigt, dass die Säulen allein, ohne gegenseitige Korrelation, wie drei Bücher in drei verschiedenen Sprachen sind. Jedes erzählt die gleiche Geschichte, aber niemand kann alle gleichzeitig lesen.

Das Problem isolierter Signale: Sie haben einen Alert auf hohe Latenz (Metrik). Sie öffnen einen Trace und sehen, dass der Engpass in einem Datenbankaufruf liegt. Aber was tat dieser Aufruf? Sie brauchen Logs von diesem spezifischen Request. Und versuchen Sie jetzt, das richtige Log unter Millionen von Zeilen zu finden — ohne Trace ID im Log-Kontext sind Sie verloren. Das ist die Realität von 60 % der Kubernetes-Deployments, die wir in den letzten zwei Jahren auditiert haben.

72 % Der Organisationen haben 3+ Observability-Tools ohne Korrelation (CNCF Survey 2025)

43 Min. Durchschnittliche MTTR bei manueller Signalkorrelation

35 % Des Observability-Budgets fließt in die Speicherung von Daten, die niemand liest

Moderne Observability geht von drei Säulen zu Unified Telemetry über. Jedes Signal — Log, Metrik, Trace, Profil — trägt einen gemeinsamen Kontext: Trace ID, Span ID, Resource Attributes (Cluster, Namespace, Pod, Container). Das ermöglicht es, von einem Metrik-Alert direkt zum relevanten Trace und vom Trace zu den Logs eines spezifischen Spans durchzuklicken. Und genau das ermöglicht OpenTelemetry nativ.

Zusätzlich gewinnt ein viertes Signal an Bedeutung: Continuous Profiling. Projekte wie Pyroscope (jetzt Teil von Grafana Labs) ermöglichen die direkte Korrelation von CPU- und Speicherprofilen mit Traces. Sie wissen nicht nur wo ein Request langsam ist, sondern auch warum — welche Funktion CPU verbraucht, wo Speicherallokations-Spitzen auftreten.

2. OpenTelemetry Collector Pipeline — Das Herz des gesamten Stacks¶

OpenTelemetry (OTel) wurde 2026 zum De-facto-Standard für Instrumentierung und Telemetrieerfassung. Traces- und Metriken-APIs sind stabil (GA), die Logs-API erreichte Stabilität in Q3 2025. Die Schlüsselkomponente ist der OpenTelemetry Collector — ein herstellerneutraler Agent, der Telemetriedaten empfängt, verarbeitet und exportiert.

Schlüsselprinzipien einer Produktions-Pipeline:

• Receivers akzeptieren Daten aus verschiedenen Quellen — OTLP (natives OTel-Protokoll), Prometheus Scrape für Abwärtskompatibilität, Filelog für Container-Logs
• Processors sind das Gehirn der Pipeline — k8sattributes reichert Telemetrie automatisch mit Kubernetes-Metadaten an, tail_sampling sampelt Traces intelligent (100 % der Fehler, 100 % der langsamen Requests, 5 % Baseline)
• Exporters senden Daten an das Backend — im LGTM-Stack sind das Tempo für Traces, Mimir für Metriken, Loki für Logs
• Filter Processor eliminiert Rauschen vor dem Export — Health Checks, Readiness Probes, Debug-Logs in der Produktion. Das ist der Haupthebel für Kostenkontrolle

DaemonSet vs. Sidecar vs. Gateway: In Kubernetes deployen Sie den Collector als DaemonSet für Logs und Node-Level-Metriken und als Deployment (Gateway) für zentrale Trace-Verarbeitung. Das Sidecar-Pattern fügt 50–100 MB RAM Overhead pro Pod hinzu — verwenden Sie es nur bei Per-Pod-Konfiguration oder strikter Tenant-Isolation.

3. LGTM Stack — Loki, Grafana, Tempo, Mimir¶

Der LGTM-Stack von Grafana Labs wurde 2026 zur beliebtesten Open-Source-Observability-Plattform für Kubernetes. Und das aus gutem Grund: Alle Komponenten teilen architektonische Prinzipien (horizontale Skalierung, Object Storage Backend, Multi-Tenancy) und Grafana vereint sie in einer einzigen UI mit nativer Signalkorrelation.

Loki — Logs ohne Inhaltsindizierung¶

Loki ist „Prometheus für Logs”. Es indiziert keinen Log-Inhalt (im Gegensatz zu Elasticsearch), sondern nur Metadata-Labels. Das bedeutet deutlich geringere Speicher- und Compute-Anforderungen. In der Praxis: Wo Elasticsearch 3 Nodes mit 64 GB RAM braucht, kann Loki mit einem einzigen Node und einem S3-Bucket auskommen. Die LogQL-Abfragesprache ist ähnlich wie PromQL, sodass die Lernkurve für Teams, die bereits Prometheus kennen, minimal ist.

Produktions-Tipp: Deployen Sie Loki im Simple Scalable oder Microservices Modus. Typische Produktionskonfiguration: 3 Write-Replicas, 2 Read-Replicas, S3/GCS als Langzeitspeicher.

Tempo — Verteilte Traces¶

Tempo speichert Traces in Object Storage (S3, GCS, Azure Blob) ohne Indizierung. Die Suche funktioniert über Trace ID (direktes Lookup) oder über TraceQL — eine Abfragesprache zum Filtern von Traces nach Attributen, Dauer und Status. Dank der Grafana-Integration können Sie von einem Metrik-Panel direkt zu relevanten Traces über Exemplars durchklicken.

Mimir — Long-term Metrics Storage¶

Mimir ist horizontal skalierbarer Speicher für Prometheus-Metriken. Kompatibel mit PromQL, unterstützt Multi-Tenancy, globale Ansicht über Cluster hinweg und Langzeit-Retention (Monate bis Jahre) auf Object Storage. Für die meisten Kubernetes-Deployments ersetzt es Thanos oder Cortex mit einfacherer Architektur und besserer Performance.

Grafana — Vereinheitlichte UI¶

Grafana 11+ bringt die Schlüsselfunktion: Explore Traces → Logs → Metrics Korrelation. Von einem einzigen Dashboard aus sehen Sie Metriken, klicken zu Traces durch und von Traces zu Logs eines bestimmten Spans. Dies eliminiert Context Switching zwischen Tools und reduziert MTTR dramatisch. Grafana Alerting ersetzt den eigenständigen Alertmanager und ermöglicht Multi-Signal-Alerts — zum Beispiel „Alert, wenn Error Rate > 5 % UND p99-Latenz > 2s UND Logs ‚connection refused’ enthalten.”

4. eBPF-basierte Observability — Instrumentierung ohne Code¶

eBPF (extended Berkeley Packet Filter) ist ein Game-Changer für Kubernetes Observability. Statt Instrumentierung im Anwendungscode laufen eBPF-Programme direkt im Linux-Kernel und erfassen Systemaufrufe, Netzwerkverkehr und Performance — ohne jegliche Anwendungsmodifikation. Für das SRE-Team bedeutet das: Sichtbarkeit in Services, die Sie nicht kontrollieren (Drittanbieter, Legacy, kompilierte Binaries).

Cilium Hubble — Network Observability¶

Cilium ist heute das am weitesten verbreitete eBPF-basierte CNI für Kubernetes. Seine Observability-Schicht Hubble bietet L3/L4/L7-Sichtbarkeit in den gesamten Netzwerkverkehr ohne Sidecar Proxy (Goodbye Istio-Sidecar-Overhead). Was Hubble kann:

• Service Map — automatisch generierte Dependency-Map zwischen Services, basierend auf tatsächlichem Netzwerkfluss, nicht deklarativen Konfigurationen
• DNS Observability — Sie sehen jede DNS-Abfrage von jedem Pod, einschließlich Latenz und Fehlerrate. DNS-Probleme sind der #1 versteckte Killer der Kubernetes-Performance
• HTTP/gRPC-Metriken — L7-Metriken (Request Rate, Error Rate, Duration) ohne Service-Mesh-Sidecar. Hubble extrahiert sie direkt aus eBPF-Hooks im Kernel
• Network Policy Audit — Sie sehen, welche Verbindungen erlaubt sind, welche blockiert werden und wo eine NetworkPolicy fehlt

In der Produktion kombinieren wir Hubble-Metriken mit Prometheus/Mimir und Hubble-Flows mit Grafana-Dashboards. Ergebnis: vollständige Netzwerk-Observability mit Overhead unter 2 % CPU (verglichen mit 10–15 % beim Istio-Sidecar-Modell).

Pixie — Application-Level eBPF Observability¶

Pixie (Open Source, CNCF Sandbox Projekt) geht noch weiter als Hubble. Nicht nur Netzwerkverkehr, sondern auch Anwendungsprotokolle — es parst automatisch HTTP, gRPC, MySQL, PostgreSQL, Kafka, Redis und mehr. Ohne eine einzige Zeile Instrumentierungscode sehen Sie:

• Komplette Request/Response-Payloads für jede Datenbankabfrage
• Flamegraph-CPU-Profile für jeden Pod im Cluster
• Verteilte Traces, rekonstruiert aus eBPF-Daten (ohne OTel SDK in der Anwendung)
• Netzwerkverkehr einschließlich verschlüsseltem TLS (Pixie hookt in SSL_read/SSL_write)

Pixie speichert Daten Edge-Side (direkt im Cluster, nicht in der Cloud), was für regulierte Umgebungen essenziell ist. Retention ist typischerweise 24 Stunden (begrenzt durch RAM), aber für das Debugging aktueller Probleme reicht das. Für Langzeitspeicherung Export in den OTel Collector.

eBPF ≠ Ersatz für OTel-Instrumentierung: eBPF glänzt bei Netzwerk- und System-Sichtbarkeit. Aber Business-Level-Kontext (User ID, Order ID, Custom-Attribute) muss weiterhin im Code über das OTel SDK instrumentiert werden. Die beste Architektur kombiniert beides.

5. AI-gestütztes Alerting — Das Ende der Alert Fatigue¶

Das durchschnittliche SRE-Team erhält 500–2.000 Alerts täglich. Davon sind 80–90 % False Positives oder Duplikate. Alert Fatigue ist ein echtes Problem — wenn Sie 50 Alerts pro Stunde bekommen, hören Sie auf, sie zu lesen. Und der eine wichtige Alert geht unter. AI-gestütztes Alerting ändert das.

Anomalieerkennung statt statischer Schwellenwerte¶

Ein statischer Schwellenwert „Alert wenn CPU > 80 %” ist einfach, aber dumm. ML-basierte Anomalieerkennung lernt normale Verhaltensmuster für jeden Service und alertiert nur bei tatsächlichen Abweichungen. Erkennt:

• Saisonale Anomalien — unterscheidet „Freitags-Traffic-Spike” (normal) von „unerwarteter Spike am Mittwoch um 3 Uhr” (Incident)
• Trend-Anomalien — langsamer Latenzanstieg von 5 ms pro Tag, der nach einem Monat +150 ms wird. Ein statischer Schwellenwert fängt das nicht, ML schon
• Korrelationsanomalien — Error Rate hat sich nicht geändert, aber die Error-Verteilung — statt üblicher 404s plötzlich 500s

Alert-Gruppierung und Root-Cause-Analyse¶

Wenn eine Datenbank ausfällt, bekommen Sie Alerts von allen abhängigen Services. Das können 50 Alerts pro Minute sein. AI-gestütztes Alert Grouping gruppiert automatisch nach Dependency-Graph, priorisiert die Root Cause und schlägt Remediation vor.

Praktisches Ergebnis: 2.000 Alerts pro Tag werden zu 3–5 sinnvollen Alert-Gruppen, jede mit vorgeschlagener Root Cause und Links zu relevanten Dashboards und Traces. MTTR sinkt von 43 Minuten auf 12.

6. Kostenkontrolle — Observability muss kein Vermögen kosten¶

Das größte schmutzige Geheimnis der Observability 2026: Kosten. Enterprise-Unternehmen zahlen üblicherweise $50–200K jährlich für Datadog, Splunk oder New Relic. Und mit steigendem Datenvolumen steigen die Rechnungen — linear, manchmal exponentiell. So bekommen Sie es unter Kontrolle.

Strategie #1: Intelligentes Sampling¶

Senden Sie nicht 100 % der Traces an das Backend. Tail Sampling im OTel Collector behält 100 % der Fehler und langsamen Requests bei, sampelt aber Baseline-Traffic nur mit 1–5 %. Für die meisten Services bedeutet das eine 95 % Reduktion des Trace-Volumens ohne Verlust diagnostischen Werts.

Strategie #2: Log-Pipeline-Optimierung¶

Logs sind typischerweise 60–70 % der gesamten Observability-Kosten. Die meisten Logs werden von niemandem gelesen. Konkrete Schritte:

• Debug/Info-Logs in Produktion droppen auf der OTel Collector Filter Processor Ebene — nicht in der Anwendung (Sie wollen sie beim Debugging aktivieren können)
• Strukturiertes Logging — JSON-Logs statt Plaintext. Kleinerer Speicher, schnelleres Abfragen, bessere Korrelation
• Tiered Retention — Hot-Daten (7 Tage) auf SSD, Warm (30 Tage) auf S3, Cold (1 Jahr) auf Glacier. Loki unterstützt das nativ
• Label-Cardinality-Kontrolle — in Loki ist Label-Cardinality der Hauptkostentreiber. Setzen Sie Request ID oder User ID nicht in Labels, sie gehören in strukturierte Metadaten

Strategie #3: Self-Hosted vs. SaaS Trade-off¶

Self-Hosted LGTM-Stack auf Kubernetes kostet typischerweise 30–50 % des Preises kommerzieller SaaS-Lösungen. Aber Sie fügen operativen Overhead hinzu. Empfehlungen:

• < 50 Services, kleines Team: Grafana Cloud (Managed LGTM) — einfacher, Free Tier deckt kleine Projekte ab
• 50–500 Services, dediziertes Plattform-Team: Self-Hosted LGTM auf Kubernetes — bestes Kosten/Kontroll-Verhältnis
• Regulierte Umgebung (Banken, Gesundheitswesen): Self-Hosted obligatorisch — Daten dürfen die Infrastruktur nicht verlassen

60 % Typische Einsparung beim Wechsel von Datadog zu Self-Hosted LGTM

95 % Trace-Volume-Reduktion via Tail Sampling

10x niedriger Speicherkosten Loki vs. Elasticsearch

Fazit: Observability als Wettbewerbsvorteil¶

Kubernetes Observability im Jahr 2026 dreht sich nicht um Tools — sondern um architektonische Entscheidungen. OpenTelemetry als universeller Instrumentierungsstandard. LGTM-Stack als kosteneffektives Backend. eBPF für Zero-Code-Infrastruktur-Sichtbarkeit. AI-gestütztes Alerting für Rauschbeseitigung.

Schlüsselerkenntnis: Beginnen Sie bei den Signalen, die Sie brauchen, nicht bei den Tools, die gerade im Trend liegen. Definieren Sie SLOs, identifizieren Sie kritische User Journeys, instrumentieren Sie diese — und kümmern Sie sich erst dann um Storage, Dashboards und Alerts. Ein Observability-Stack ist eine Investition, keine Kosten. Unternehmen, die es richtig machen, haben 3x niedrigere MTTR, 40 % weniger Incidents und deutlich zufriedenere Engineering-Teams.

Brauchen Sie Hilfe bei Observability? Bei CORE SYSTEMS entwerfen und deployen wir Observability-Stacks für Kubernetes — von Greenfield-Implementierung bis zur Migration von Legacy-Monitoring. Kontaktieren Sie uns.