Die 300.000-Dollar-Observability-Frage: Behebt KI wirklich Incidents oder verkauft sie nur bessere Dashboards?
Das Versprechen, das alle überzeugte
In den letzten Jahren haben Observability-Vendoren einen sehr konkreten Traum verkauft. Die Produktion fällt aus, ein Alert feuert, und statt dass sich Engineers durch Logs und Dashboards wühlen, findet eine KI-Engine sofort die Ursache. Ein Service-Dependency-Graph leuchtet auf, eine Deployment-Anomalie taucht auf, und das Tool zeigt genau auf den verantwortlichen Microservice. Der Incident ist gelöst.
Diese Vision, in der KI die MTTR drastisch senkt, ist eines der größten Verkaufsargumente für Plattformen wie Datadog, Dynatrace und andere große Observability-Suiten geworden. Teams, die diese Plattformen bewerten, stehen deshalb oft vor einer unangenehmen Frage: Ist der Preissprung wirklich gerechtfertigt?
Ein Engineer, der diese Tools bewertete, brachte es unverblümt auf den Punkt. Er wollte die MTTR senken, indem KI die erste Phase eines Incidents übernimmt, die schmerzhafte Phase, in der man herausfinden muss, „Was ist passiert?“. Der Haken daran: Die Premium-Plattformen können zwei- bis dreimal so viel kosten wie offene Stacks aus Grafana mit Prometheus, Loki und Tempo.
Bei so einem Preisunterschied müssen sich Teams fragen, ob die KI echten Mehrwert bringt oder nur teures Marketing ist.
Das Dynatrace-Argument: Automatisierung, die tatsächlich funktioniert
Wer Dynatrace verteidigt, spricht meist zuerst über Automatisierung. Mehrere Engineers beschreiben die OneAgent-Instrumentierung als überraschend effektiv. Man installiert den Agent, und das System entdeckt automatisch Services, verfolgt Abhängigkeiten und sammelt Telemetrie, ohne dass wochenlang konfiguriert werden muss.
Das ist wichtiger, als es klingt. Viele Observability-Deployments bleiben stecken, weil Engineers monatelang Tagging-Systeme, Log-Pipelines und Dashboards bauen, bevor die Plattform überhaupt etwas nützt. Dynatrace versucht, genau diesen Weg abzukürzen.
Laut den Befürwortern kann die kausale Analyse-Engine außerdem mehr als simple Korrelation. Statt Alerts über Tags zu verknüpfen, baut das System einen Dependency-Graph aus Services und Infrastruktur und verfolgt bei einem Fehler die Kausalkette entlang dieser Abhängigkeiten. Theoretisch muss man dadurch weniger raten.
Ein Engineer meinte, gerade dieser deterministische Ansatz, der Ursachen statt Korrelationen sucht, mache die Plattform so mächtig. Dank der Data-Lake-Architektur liegen Telemetrie und Business-Events zudem nebeneinander, sodass Teams Incidents direkt dem Impact auf Nutzer zuordnen können. Observability hilft damit beim Reparieren von Servern und zeigt zugleich, wie Ausfälle echte Kunden treffen.
Für Organisationen, die große Plattforminvestitionen rechtfertigen müssen, kann dieser geschäftliche Kontext sehr überzeugend sein.
Der Datadog-Realitätscheck
Diesen Optimismus teilen nicht alle. Manche Engineers aus großen Datadog-Umgebungen erzählen etwas ganz anderes: Selbst nach Jahren, in denen sie Pipelines, Metadaten und Tagging optimiert hatten, kamen die versprochenen KI-Erkenntnisse nie richtig an.
Einer nahm kein Blatt vor den Mund. Obwohl sein Team viel in Tagging und Anreicherung investiert hatte, lieferte die Anomalieerkennung keine sinnvollen automatisierten Erkenntnisse, und die Root-Cause-Analyse zeigte selten auf das echte Problem. Im Alltag taten die Teams weiter, was Engineers schon immer getan haben, und durchsuchten Logs von Hand.
Selbst Funktionen, die eigentlich helfen sollten, etwa die automatisierte Anomalieerkennung, erzeugten manchmal so viel Rauschen, dass Teams sie einfach ignorierten. Ein Engineer beschrieb das fast amüsiert: Technisch gesehen gab es die KI-Funktionen, nur waren sie ungefähr so nützlich wie ein Benachrichtigungssystem, dem niemand traut.
An dieser Kluft zwischen Versprechen und Realität wird die Observability-Debatte unübersichtlich.
Die LGTM-Alternative: Power ohne den Preis
Viele Engineering-Teams ziehen noch eine dritte Option in Betracht. Der LGTM-Stack aus Grafana, Loki, Tempo und Mimir hat sich als offene Alternative zu kommerziellen Observability-Plattformen etabliert. Statt hohe SaaS-Gebühren zu zahlen, bauen Teams ihre Observability-Infrastruktur selbst.
Der Reiz ist offensichtlich. Die Kosten sinken dramatisch, Engineers behalten die volle Kontrolle über ihre Telemetrie-Pipeline, und die Integration offener Standards wie OpenTelemetry wird einfacher.
Der Preis dafür ist operativer Aufwand. Anders als kommerzielle Plattformen kommt der LGTM-Stack selten fertig zusammengebaut. Teams entwerfen ihre Dashboards selbst, verwalten den Storage, tunen Queries und warten die Infrastruktur. Für kleinere Organisationen kann das überwältigend sein.
Manche Engineers halten den Tausch trotzdem für lohnend. Der Stack braucht anfangs mehr Arbeit, erspart einem aber die unberechenbaren Preismodelle vieler kommerzieller Plattformen. Andere sehen es umgekehrt: Ohne eingebaute kausale Analyse oder automatisierte Erkenntnisse verbringen Engineers während Incidents mehr Zeit damit, Signale von Hand zu korrelieren.
Das Preisproblem bei Observability
Kaum ein Thema ist in der Branche so umstritten wie die Preise für Observability. Viele Teams starten mit kleinen Deployments und vernünftigen Monatsrechnungen. Dann wächst die Telemetrie, die Zahl der Services steigt, das Log-Volumen explodiert, und plötzlich hat sich die Rechnung verdreifacht.
Engineers, die Plattformen bewerten, machen sich deshalb oft mehr Sorgen um die Kostenprognose als um Features. Datadog kann durch Custom Metrics und das Volumen der Log-Ingestion unberechenbar teuer werden. Dynatrace rechnet in Host Units ab, die an RAM und Infrastrukturgröße gekoppelt sind. Beide Modelle können Finanzteams überraschen, wenn Workloads unerwartet wachsen.
Dadurch ist Observability genauso ein Budgetthema wie ein technisches. Ein Tool spart bei einem Incident vielleicht zehn Minuten Untersuchungszeit. Kostet es aber jedes Jahr Hunderttausende, will die Führungsebene Belege sehen, dass diese Minuten echten Geschäftswert bringen.
Damit landet die Debatte bei einer grundsätzlicheren Frage.
Die MTTR-Debatte
Jahrelang war die MTTR, die Mean Time to Resolution, die wichtigste Kennzahl für Observability-Tools. Die Logik schien einfach: Weniger MTTR heißt weniger Downtime, und weniger Downtime schützt den Umsatz.
Manche erfahrenen Engineers glauben aber, die Branche optimiere die falsche Zahl. Ein erfahrener SRE wies darauf hin, dass die MTTR misst, wie schnell Teams Probleme beheben, nachdem sie aufgetreten sind. Eigentlich sollte man die Probleme gar nicht erst entstehen lassen.
Statt schnelle Wiederherstellung zu feiern, sollten Organisationen seiner Meinung nach die Erfolgsrate bei der ersten Auslieferung messen. Wird ein Feature beim ersten Versuch sauber deployt, gibt es gar keinen Incident.
Das verändert das Gespräch über Observability. Der Wert einer Plattform liegt dann auch darin, die Qualität der Software-Delivery zu verbessern, und nicht nur im Debuggen von Incidents. Fließt Telemetrie in die Entwicklungszyklen zurück, erkennen Teams riskante Deployments, instabile Services und Performance-Regressionen, bevor daraus Ausfälle werden. Observability wird so zum Entwicklungswerkzeug und ist mehr als ein System zum Feuerlöschen.
Was KI-Observability leisten kann
Wenn man aus den Diskussionen echter Engineering-Teams eine Lehre ziehen kann, dann die, dass KI allein Observability-Probleme selten löst. Eine gute Telemetrie-Architektur zählt mehr.
Plattformen mit gut strukturierten Traces, konsistentem Tagging und klaren Service-Grenzen funktionieren oft besser, ob KI-Funktionen aktiviert sind oder nicht. Umgebungen mit chaotischen Telemetrie-Pipelines bringen dagegen selbst die fortschrittlichsten Analyse-Engines durcheinander. KI kann Muster sichtbar machen, schlechte Instrumentierung reparieren kann sie nicht.
Das erklärt, warum manche Teams nach der Einführung einer Observability-Plattform massive Verbesserungen sehen und andere fast keine. Der Unterschied liegt oft weniger am Tool als an der Umgebung, in der es läuft.
Die eigentliche Entscheidung, die Teams treffen müssen
Die Wahl zwischen Datadog, Dynatrace und einem offenen Stack hängt selten an einem einzelnen Feature. Teams wägen drei konkurrierende Prioritäten gegeneinander ab: Bequemlichkeit, Kosten und Kontrolle.
Kommerzielle Plattformen sind bequem. Sie verkürzen die Einrichtung und bündeln die Telemetrie-Systeme in einer Oberfläche, allerdings zu Premium-Preisen und mit Abhängigkeit vom Vendor. Offene Stacks bieten Kontrolle. Teams verwalten Pipelines und Infrastruktur selbst und sparen dabei oft viel Geld, müssen das System aber auch selbst warten und betreiben.
Die KI liegt im Moment irgendwo dazwischen. In den besten Umgebungen verkürzt sie Untersuchungen und zeigt nützliche Korrelationen. In den schlechtesten wird sie kaum mehr als ein schicker Alert-Feed, den Engineers irgendwann ignorieren.
Am Ende steht deshalb vielleicht eine ganz andere Frage als die nach der KI: Will Ihr Team das System selbst bauen oder lieber kaufen?