Das Ende der Observability naht (und ich bin damit einverstanden)

• Das zentrale Ziel von Observability-Tools in den vergangenen Jahrzehnten war es, große heterogene Telemetriedaten für Menschen verständlich zu machen
• Mit dem Aufkommen von AI und LLMs verändert sich das bisherige Paradigma rund um „Dashboards + Alerts + Sampling“, da der Analyseprozess zunehmend durch Automatisierung ersetzt wird
• Tatsächlich hat ein AI-Agent in nur 80 Sekunden mit 8 Tool-Aufrufen die Ursache eines Latenz-Spikes analysiert und damit Aufgaben aus klassischen Demos automatisiert – für Kosten von lediglich 60 Cent
• Bisherige hübsche Dashboards oder komfortable Instrumentierung sind kein besonderer Mehrwert mehr, weil LLMs die Analyse und OpenTelemetry die Instrumentierung zur Commodity machen
• Die Observability der Zukunft wird durch schnelle Feedback-Loops und AI-Mensch-Kollaborations-Workflows bestimmt und eine Ära von mehr Software und mehr Automatisierung antreiben

---

Die Geschichte von Observability-Tools und das Aufkommen von AI

• Über Jahrzehnte hinweg bestand der Hauptzweck von Observability-Tools darin, gewaltige Mengen heterogener Daten (Telemetry) auf ein für Menschen verständliches Niveau zu verdichten bzw. zusammenzufassen
• Jedes Mal, wenn neue Software-Abstraktionen entstanden (z. B. Rails, AWS, Kubernetes, OpenTelemetry usw.),
  wurden verschiedene Werkzeuge wie Monitoring, Messung, Dashboards, adaptive Alerts und dynamisches Sampling entwickelt, um diese Komplexität zu verbergen und die Datenkomplexität passend zur menschlichen Kognition verdichtet bereitzustellen

LLM = universeller Funktionsapproximator, und jetzt wirklich nützlich

• Mathematisch gesehen ist ein LLM lediglich ein universeller Funktionsapproximator (universal function approximator), in der Praxis aber äußerst nützlich zur Lösung von Observability-Problemen
• Als Beispiel dient eine Honeycomb-Demo, in der ein AI-Agent per natürlicher Sprache gebeten wurde, einen Latenz-Spike in einer Heatmap zu analysieren
  • „Analysiere die Ursache der Latenz-Spikes, die im Frontend-Service im Abstand von vier Stunden auftreten“
  • Ein Off-the-shelf-LLM (Claude Sonnet 4) wurde mit dem Model Context Protocol (MCP) von Honeycomb verbunden
  • In 80 Sekunden, mit 8 Tool-Aufrufen und Kosten von 60 Cent wurde die Ursache automatisch analysiert
• Das Niveau ist inzwischen so weit, dass reale Szenarien ohne zusätzliche Prompts, separates Training oder Anleitungen zero-shot gelöst werden können
• Kommoditisierung der Analyse:
  • Wenn LLMs Analyseaufgaben automatisieren, verlieren bisherige Differenzierungsmerkmale von Observability-Produkten (schöne Grafiken, einfache Instrumentierung usw.) an Bedeutung
  • OpenTelemetry kommoditisiert die Instrumentierung, LLMs kommoditisieren die Analyse
  • Künftig wird der „schnelle Feedback-Loop“ den zentralen Wert von Observability-Tools ersetzen

Die Rolle des Menschen und der künftige Wandel

• Die Rolle des Menschen verschwindet nicht vollständig
  • So wie das Aufkommen der Cloud die Existenz der IT nicht abgeschafft hat, wird auch AI Entwickler:innen und Operatoren nicht ersetzen
  • Produktivitätssteigerungen erweitern das gesamte Feld und führen dazu, dass noch mehr Software entsteht
• Die zentrale Frage ist:
  Wohin bewegt sich das Wesen der Observability in einer Welt, in der
  die Kosten für Code schreiben/Refactoring/Analyse drastisch sinken und Analyse zu einer Konstante wird?

Wirklich wichtig ist „schnelles Feedback“

• Am wichtigsten ist es, in allen Phasen von Entwicklung und Betrieb schnelle, engmaschige Feedback-Loops zu haben
  • AI wird Menschen bei der Geschwindigkeit immer voraus sein
  • LLMs stellen schnell Dutzende Hypothesen auf, verwerfen sie wieder und finden schließlich das richtige Ergebnis
    (und das zu sehr geringen Kosten)
• Die Philosophie von Honeycomb:
  • schnelle Feedback-Loops, kollaborativer Wissensaustausch, experimentelle Entwicklung und Operations
  • Künftig wird AI-Unterstützung über den gesamten Lebenszyklus von Softwareentwicklung und Betrieb hinweg eingeführt
    • Beispiele
      • Beim Schreiben und Deployen von Code geben AI-Agenten in Echtzeit Feedback und schlagen Verbesserungen bei Bugs und Qualität vor
      • Im Betrieb erkennen, analysieren und berichten sie emergent behavior automatisch und setzen nach Freigabe Verbesserungen automatisiert um
      • Führende Organisationen automatisieren SRE-/SWE-Rollen mit AI und Tools und erreichen direkt sogar Business-Ziele
• Zukünftige Voraussetzungen für erfolgreiche Observability
  • Query-Performance mit extrem niedriger Latenz
  • ein integrierter Datenspeicher
  • nahtlose Kollaborations-Workflows zwischen Menschen und AI
• Fazit:
  • Klassische, auf Dashboards, Alerts und Visualisierung fokussierte Observability-Tools
    stehen im AI-Zeitalter nicht mehr im Zentrum;
    nur „schnelle Feedback-Loops“ und AI-Mensch-Kollaborationsplattformen werden bestehen

[redlasha]

So wie Observability nicht das Ende des Monitorings ist, werden LLMs wohl auch nicht das Ende der Observability sein.
So wie sich Observability auf der Grundlage fortgeschrittenen Monitorings entwickelt hat, wird sich auch die LLM-Analyse auf der Grundlage fortgeschrittener Observability weiterentwickeln.

[ethanhur]

Ich freue mich darauf, dass der Observability-Bereich durch LLMs schnell innoviert wird, aber der Titel ist echt ziemlich auf Klicks ausgelegt, haha

[crawler]

Es ist mir etwas peinlich, wenn ein Unternehmen seinen eigenen Service mit „das Ende naht“ bewirbt ...

Persönlich hoffe ich, dass sich Vision-LLMs weiterentwickeln und für Monitoring-Aufgaben eingesetzt werden können.
Kürzlich habe ich einen Beitrag von Eltern gesehen, die ein VLM dafür genutzt haben zu prüfen, ob während des Schlafens ihres Kindes etwas Auffälliges passiert, und das fand ich ziemlich interessant.

[GN⁺]

Hacker-News-Kommentare

• Ich habe das Gefühl, dass wir kollektiv den Wert von Determinismus zu niedrig ansetzen und umgekehrt die Kosten des Nichtdeterminismus unterschätzen. Ich habe kürzlich ein anderes Produkt mit einem ähnlichen Sales-Pitch getestet, und das versucht, meine Vorfälle über Graphen zu korrelieren, um RCA zu betreiben. Am Ende sieht es aus wie die Seite Spurious Correlations — wenn man es direkt sieht, ist es offensichtlich und sogar komisch.
  • Es sollte bekannter sein, dass Zeitreihendaten wirklich anfällig für Scheinkorrelationen sind. Auch ein r²-Wert ist bedeutungslos. Noch schlimmer wird es, wenn man Graphen per Augenmaß interpretiert; bei Daten, die sich über die Zeit verändern, muss man geeignete Metriken verwenden.
  • Vielleicht habe ich den Punkt falsch verstanden, aber auch in LLM-basierten Apps kann man mit gutem Design in wirklich wichtigen Momenten eine deterministische UX umsetzen. Das LLM kann bei Bedarf eine deterministische Spezifikation dafür erzeugen, etwas auszuführen, und diese Aufgabe oder Aktion kann protokolliert werden. Man kann es so aufbauen, dass eine Spezifikation, die der Nutzer jederzeit erneut ausführen kann, zusammen mit dem Gespräch gespeichert wird, und dass die AI Vorschläge macht, wie man eine fehlgeschlagene Spezifikation korrigiert. Das ähnelt dem Einsatz von AI beim Programmieren. Man müsste nur die Spezifikationsdomäne enger fassen und mehr darüber nachdenken, wie man fehlgeschlagene Spezifikationen wiederherstellt. Das ist umsetzbar, ohne vom Nutzer zu verlangen, eigens eine Spezifikationssprache zu lernen.
• Als jemand, der gut in RCA ist, mache ich mir Sorgen, dass meine Kollegen, denen das peinlich wäre, einem Tool blind vertrauen könnten, das mit großer Sicherheit Ergebnisse liefert, die zu 10 % falsch sind, und dadurch alles noch schlimmer machen. Ich sorge mich, dass man sich nur noch auf das Tool verlässt, weil man nicht mehr öffentlich zugeben muss, etwas wirklich nicht zu wissen. Weniger schlimm wäre es, wenn das Tool nach seiner Schlussfolgerung auch nach Daten suchen würde, die seine eigene Interpretation widerlegen, und belastbarere Belege oder Unsicherheit klarer benennen würde.
  • Mit einem gut formulierten System-Prompt kann man diesen Punkt ziemlich gut abfedern. Ich habe tatsächlich schon Custom Prompts/Anweisungen gebaut, die aus einem LLM standardmäßig deutlich rigorosere und besser recherchierte Antworten herausholen, und die Erfahrung war ziemlich gut. Der Prompt, den ich in ChatGPT nutze, lautet: "Priorisiere Substanz, Klarheit und Tiefe. Behandle jeden Vorschlag, jedes Design und jede Schlussfolgerung als Hypothese und hinterfrage sie scharf. Lege versteckte Annahmen, Trade-offs und Failure Cases früh offen. Lass unnötiges Lob weg, wenn es nicht belegt ist. Wenn Unsicherheit besteht, benenne sie klar. Biete immer alternative Perspektiven an. Behaupte Fakten nur dann eindeutig, wenn es Zitate oder belastbare Belege gibt. Wenn du dich auf Schlussfolgerungen oder unvollständige Informationen stützt, weise klar darauf hin. Genauigkeit ist wichtiger als Selbstsicherheit." Damit verbessern sich Qualität und Tiefe der Antworten in der Praxis deutlich.
• Eine Geschichtserzählung nach dem Muster „New Relic in der Rails-Revolution, Datadog beim Aufstieg von AWS, Honeycomb führte OpenTelemetry an“ ist eine verzerrte Interpretation. OpenTelemetry (OTel) entstand, als OpenCensus von Google und OpenTracing von LightStep offiziell zusammengeführt wurden. Verschiedene Organisationen wie Google, LightStep, Microsoft und Uber waren an der frühen Governance beteiligt. Honeycomb hat zwar Code, Community und technologische Einführung stark vorangetrieben, aber „führte an“ ist übertrieben.
  • Ich lese das als jemand, der Honeycomb kürzlich eingeführt hat, und es ist wirklich ein erstaunliches Tool. Vor allem dank der automatischen otel-Instrumentierung kann man innerhalb weniger Stunden zu Erkenntnissen kommen. Auch bei den Dashboard-/Query-Funktionen merkt man, dass sie aus einer Philosophie tiefer Observability kommen. Unser ganzes Team war von der Reife des Tools schockiert. Datadog wirkt eher auf Marketing und eine „Observability“-Checkliste fokussiert.
• Wenn man den „Sales-Pitch“ beiseitelässt, ist das eine der Anwendungen, in denen LLMs wirklich wertvoll sind. Monitoring und Observability waren bisher das Feld großer Enterprise-SRE-Teams, und für kleinere Organisationen war die Hürde hoch — zumindest aus IT-Sicht. Schon die Auswahl sinnvoller Metriken sowie das Aufsetzen von Heartbeat und Baseline erforderten Zeit, Spezialtools, umfangreiche Entwicklungsumgebungen und Prozesse zur Änderungsvalidierung, sodass normale IT-Teams das kaum angehen konnten. Dank LLMs, die auf den verbreitetsten Tools trainiert wurden, können nun auch IT-Teams mit wenig Budget oder begrenzten Fähigkeiten auf Basis offener Frameworks/Tools ein „echtes“ Observability-System umsetzen. Man braucht nicht länger eine glitzernde Abo-Lösung. Wenn man Dashboards bauen oder praktikables Monitoring einrichten muss, sind LLMs wirklich ein Segen. Für IT-Leute, die Anleitungen lesen und Troubleshooting betreiben können, aber keine Zeit haben, sich tief in die vielen vom CIO gepushten Produktfamilien einzuarbeiten, ist das extrem nützlich. Wenn an PagerDuty-Alerts sogar noch Vorschläge zur wahrscheinlichsten Ursache hängen, wäre das aus Sicht von SMB/SME eine Observability-Revolution.
  • Das Auffinden sinnvoller Metriken ist kein Bereich, in dem LLMs gut sind, aber der Rest — etwa Heartbeat oder Baseline — war schon vor langer Zeit mit ConvNets (Convolutional Neural Networks) ausreichend automatisierbar. Themen wie Änderungsvalidierung oder Stabilitätskontrolle bei Deployments liegen außerhalb des Bereichs von Observability-Tools.
  • Ich erwarte auch für kleine SRE-Teams enorme Wirkung. Unser Team aus zwei Leuten verwaltet Hunderte Bare-Metal-Server, und wenn eine Störung auftritt, ist der Prozess, die Ursache einzugrenzen, extrem stressig. Wir haben sogar darüber nachgedacht, selbst ein Tool wie MCP (Master Control Program) zu bauen. Mehrfach hatten wir Fälle, in denen ein Problem lange latent blieb und dann schließlich als Fehler ausbrach; bei solchen Fällen würden LLMs erheblich helfen.
• Der Titel wirkt zu reißerisch. Bestehende Observability-Tools werden dadurch nicht nutzlos. Es könnte nur sein, dass man weniger Zeit damit verbringt, Graphen zu bauen und ständig anzustarren. Das ist ähnlich wie der Effekt von LLMs in allen möglichen Bereichen. Sie helfen dabei, Aufgaben, die man ohnehin schon kann, schneller zu erledigen, oder dabei, überhaupt zu lernen, wie man etwas macht — aber sie ersetzen nicht eine bestimmte Technik vollständig.
  • „Aufgaben, die man ohnehin schon kann, schneller erledigen“, „dabei helfen, neue Dinge zu lernen“ — genau diese Schlussfolgerung höre ich heute schon zum zweiten Mal. Dass sie Punkt 2 per Inference leisten und die Effizienz von Punkt 1 extrem steigern, ist aus meiner Sicht die produktivste Richtung für die Zukunft.
  • Der Titel ist reißerisch, aber die Botschaft ist klar — der Burggraben der Einstiegshürden wird immer flacher.
  • Dieses Phänomen nennt man den „Charity-Majors-Effekt“.
• In der Demo heißt es: „Das ist kein künstliches Beispiel. Wir haben dem LLM-Agenten einfach genau die Fragen gestellt, die wir dem Nutzer in der Demo stellen, und es hat ohne zusätzliche Prompts, Training oder Hinweise sofort die richtige Antwort gefunden.“ Tatsächlich war dieses Szenario aber schon Teil der Demo, und die Lösung existiert in diesem Fall bereits. Eigentlich hätte man eher ein künstliches Beispiel verwenden sollen, um zu zeigen, ob das Modell auf neue Situationen generalisieren kann, die nicht exakt in den Trainingsdaten enthalten sind. Die tatsächlichen Fähigkeiten von LLMs sind nützlich, aber für eine extreme Aussage wie „das Ende der Observability“ müsste das Tool Generalisierungsfähigkeit zeigen.
• Ich glaube nicht, dass es das „Ende der Observability“ ist. Aber die im Artikel genannten Punkte sind auch nicht völlig aus der Luft gegriffen. Es ist gut möglich, dass eine neue Schicht von AI-Agenten entsteht, die in SRE verschiedene Rollen übernehmen können, insbesondere auch bei RCA. Selbst wenn das Realität wird, wird aber der Großteil des bestehenden Observability-Stacks — wenn nicht sogar alles davon — weiterhin gebraucht. Außerdem wird man, solange die Probleme mit Halluzinationen/Zuverlässigkeit/Stabilität von LLMs nicht grundlegend gelöst sind, für tiefgehende Problemanalyse weiterhin Menschen brauchen.
• „Mit AI kann man mit ein bisschen Mühe alles machen, wofür früher Experten nötig waren“ — als Geschäftsstrategie ist das wirklich attraktiv. Traurig, aber bei 80 % der heutigen AI-Startups könnte man diesen Pitch einkopieren, ohne dass es seltsam wirkt.
  • Ich weiß, dass das spöttisch gemeint ist, aber diese „halbwegs fähigen Experten“ sind eine <i>extrem</i> teure Ressource. Wenn diese Automatisierung tatsächlich gelingt, ist es auch nachvollziehbar, warum es so viele fragwürdige AI-Startups gibt.
• Dieser Artikel wirkt, als wäre er komplett von AI geschrieben. „AI beendet dieses Paradigma, sie tut es bereits, und sogar Systemdesign und Betriebsweise werden sich grundlegend ändern“ — ich frage mich wirklich, wie das Interpretieren eines Teils der Daten gleich das „Ende der Observability“ sein soll.
• Die Logik „Man muss sich Daten nicht mehr über Graphen und UIs ansehen“ hat in der Praxis Grenzen. Wenn LLMs gut funktionieren, ist das großartig, aber wenn sie scheitern, müssen Menschen eingreifen und sich Graphen und andere Visualisierungen selbst ansehen. Graphen und Visualisierungen sind schon schwierig, aber die eigentliche Datenerfassung sowie das Design komplexer Queries und Speicherverfahren sind noch einmal deutlich anspruchsvoller. Erst in dem Moment, in dem echte künstliche Intelligenz fast alles nahezu perfekt beurteilen kann, wird Observability wirklich „verschwinden“. Letztlich käme dann ein kultureller Wandel, bei dem sich die gesamte gesellschaftliche Struktur vollständig verändert — vielleicht keine Auslöschung, aber ein schmerzhafter Übergang. Dass AI die Observability-Landschaft verändert, stimmt definitiv. Das passiert schon jetzt, aber der Weg ist noch lang.