Während die Branche darüber streitet, wie der moderne Observability-Stack heißen soll — Observability 2.0 oder schon 3.0 —, verbergen sich hinter der Terminologie drei konkrete Verschiebungen. Die Instrumentierung ist aus dem Code in den Kernel gewandert (eBPF). Die Telemetrie hat sich um OpenTelemetry standardisiert. Und die Ursachenanalyse beginnt, vom Menschen auf die Maschine überzugehen. Jede nächste Schicht zahlt sich nur aus, wenn die darunter in Ordnung ist — und genau die Reihenfolge der Investitionen verwechseln Teams am häufigsten.
Monitoring beantwortet «läuft es?». Observability beantwortet «warum nicht?»
Monitoring beantwortet die Fragen «läuft das System und wie schnell?». Observability beantwortet «warum ist es langsam und wo genau?». In Kubernetes lassen sich komponentenübergreifende Vorfälle ohne das Zweite nicht schließen: Das Symptom «Latenz gestiegen» lässt sich nicht mit der Ursache «Node unter MemoryPressure, Kubelet hat Pods evictet, Service-Endpoints flappten» verbinden, wenn man nur Anwendungsmetriken sieht.
Deshalb kommt in Kubernetes zu den klassischen drei Säulen — Metriken, Logs, Traces — ein viertes Signal hinzu: Cluster-Events und Workload-Metadaten. OOMKills, Evictions, HPA-Entscheidungen, Scheduler-Fehler, Admission-Ablehnungen — das ist das Entscheidungsprotokoll des Orchestrators, und ohne es verkommt die Vorfallanalyse zu «neu gestartet, lief wieder».
Die Instrumentierung ist in den Kernel gewandert
Jahrelang war der Eintrittspreis für Distributed Tracing hoch: ein SDK in jedem Service, ein Release, ein Regressionszyklus. eBPF hat diese Barriere beseitigt. OBI — OpenTelemetry eBPF Instrumentation — wird als DaemonSet ausgerollt und liefert dem Cluster innerhalb eines Tages eine Baseline ohne eine einzige Codeänderung: RED-Metriken, HTTP- und gRPC-Traces, Service-to-Service-Flows, Datenbankaktivität und — ein unerwarteter Bonus — Sichtbarkeit des TLS-Traffics ohne Entschlüsselung, weil das Abfangen auf Syscall-Ebene vor der Verschlüsselung stattfindet. Die Anforderungen sind bescheiden: Linux-Kernel 5.8+ und BPF-Rechte.
eBPF hat eine Obergrenze: Es sieht Netzwerk und Syscalls, aber keinen Geschäftskontext — welche order_id, welcher Tenant. Daraus folgt die Arbeitsregel «Observe first. Instrument later.»: zuerst eine eBPF-Baseline für den gesamten Cluster, dann Auto-Instrumentierung auf Infrastrukturebene für die polyglotte Flotte, und nur auf kritischen, umsatzrelevanten Pfaden das manuelle SDK mit eigenen Attributen. Instrumentierung hört auf, Sache der Entwickler zu sein, und wird Sache der Plattform.
OpenTelemetry ist ein Vertrag, kein Werkzeug
OTel ist ein Standard: einheitliche SDKs, semantische Konventionen und ein Wire-Protokoll. Die Anwendung wird einmal instrumentiert — exportiert wird überallhin, von Tempo bis zum kommerziellen APM, ohne Lock-in. Semantische Konventionen (service.name, k8s.pod.name, http.status_code) geben allen Signalen ein gemeinsames Vokabular — und ein gemeinsames Vokabular plus eine durchgängige trace_id machen aus drei Speichersystemen ein System.
Wichtig für Brownfield: OTel verlangt nicht, das bestehende Prometheus oder VictoriaMetrics wegzuwerfen. Der Exporter prometheusremotewrite schreibt Metriken in dieselbe TSDB; das Scraping bleibt für Legacy-Ziele, der Collector kommt für neue hinzu. Die Migration ist Evolution, nicht Revolution.
Die KI-Schicht: Das LLM sieht eine Metrik nie zuerst
Die Versuchung «schicken wir die Metriken an GPT, es findet die Anomalien» zerbricht an echten Daten: zu langsam, zu teuer, nicht deterministisch. Das Produktionsmuster ist ein anderes — filter cheap, escalate smart. Billige Detektoren fangen 95–99 % der Ereignisse ab, bevor irgendeine KI ins Spiel kommt: Isolation Forest auf Metriken (Inferenz in Mikrosekunden), Drain3-Template-Mining auf Logs, Frequenz-Baselines. Das LLM bekommt nur den eskalierten Rest — das «Unbekannte» und die «Spikes» — und tut, was es kann: über unordentlichen Kontext schlussfolgern, das Signal mit jüngsten Deploys verknüpfen, den Postmortem-Entwurf schreiben. Das ist Arbeitsteilung, keine Konkurrenz: ML macht numerisches Thresholding im Maßstab, das LLM das Reasoning.
Die zweite Stütze der KI-Schicht ist die Change-Korrelation: 70–80 % der Produktionsvorfälle sind change-bedingt. Deploy-Marker aus ArgoCD, Konfigurationsänderungen, IAM-Mutationen aus dem Audit-Log — ein eigener Ereignisstrom neben der Telemetrie. Bei einer Anomalie stellt die Maschine dieselbe erste Frage wie ein erfahrener SRE: «Was wurde in der letzten Stunde deployt?»
Die Branchenzahlen sind ernüchternd: Führende Teams senken die MTTR um 40–70 %, doch nur 4 % der Organisationen haben KI vollständig operationalisiert, die Hälfte steckt in Pilotprojekten fest. Das Paradox: Die Observability-Budgets wuchsen um 70 %, der manuelle Toil um 30 %. Der Grund — KI, die auf einen fragmentierten Stack ohne einheitliche Kontextschicht geschraubt wird, arbeitet durch ein Schlüsselloch statt mit dem Gesamtbild.
Die Reihenfolge der Investitionen
Die Schichten zahlen sich strikt von unten nach oben aus. Zuerst die einheitliche Signalschicht: OTel, eine durchgängige trace_id, das vierte Signal aus Cluster-Events. Dann Abdeckung ohne Code: eBPF-Baseline und Auto-Instrumentierung durch die Plattform. Danach billige ML-Filter und ein Change-Event-Strom. Und erst auf diesem Fundament — ein LLM für Root Cause. KI in der Observability ist das Dach, nicht das Fundament: Wer mit dem Dach anfängt, bezahlt Tokens für das Durchsehen von zehntausend Metriken — eine Aufgabe, die ein Modell aus fünfzig Zeilen erledigt.