Der Agent ist installiert, das Dashboard offen, und seit Tagen scrollt jemand durch Metriken in der Hoffnung, dass ihm etwas Sinnvolles entgegenspringt. Es springt nichts entgegen. Sichtbarkeit auf mehrere hundert Services, aber keine Ahnung, welche davon irgendjemanden interessieren — das ist kein Monitoring, das ist teures Rauschen. So lief unser erster größerer Observability-Einsatz, und der Fehler daran war nicht technisch. Ein Observability-Projekt verliert Monate, wenn drei Fragen am Anfang nicht gestellt werden.
Ausgangslage: Hunderte Services, ein Agent und keine einzige Frage
Die Situation ist typisch für einen Einstieg mit Werkzeug, aber ohne Auftrag. Ein kommerzieller APM-Agent lief auf mehreren hundert Services, dazu Call-Graphs, Baselines und Dashboards für alles. Technisch war das sauber. Der Agent ließ sich bedienen, die Begriffe waren klar, die Daten kamen an.
Was fehlte, war jede Vorstellung davon, welche Frage das System beantworten sollte. Niemand hatte vorher geklärt, welche Services kritisch sind, welche Störungen es zuletzt gab und wie die Architektur tatsächlich aussieht. Ohne diese Klärung produziert jede Instrumentierung nur mehr Fläche, über die man sich verirren kann.
Wir haben dieses Muster seitdem in vielen Projekten wiedergesehen, auch in solchen, die wir selbst mitverantwortet haben. Nach zwei Monaten stand das Monitoring, technisch einwandfrei, und trotzdem konnte niemand im Team sagen, ob die Anwendung gerade gesund war. Weil am Anfang niemand gefragt hatte, was „gesund" für dieses System überhaupt bedeutet.
Warum Daten allein keine Antworten sind
Die Annahme dahinter, gerade bei Einsteigern, lautet: Observability ist eine Tool-Frage. Man kauft oder baut den Stack, instrumentiert die Anwendung, und dann „hat man Observability". In der Praxis bekommt man erst einmal Daten. Daten sind nicht dasselbe wie Antworten.
Der Mechanismus dahinter ist simpel. Jede Metrik, jeder Trace und jedes Dashboard ist eine Antwort auf eine Frage, die irgendjemand vorher gestellt haben muss. Fehlt die Frage, entsteht ein Dashboard, das niemand ansieht, und ein Alert, der für etwas feuert, das keinen interessiert. Aus solchen Alerts wird Alert Fatigue: die Abstumpfung eines Teams, das so viele belanglose Benachrichtigungen bekommt, dass es auch die relevanten nicht mehr wahrnimmt.
Irgendwann schaltet jemand die Benachrichtigungen stumm. Dann kommt die nächste echte Störung, und das teuer aufgebaute Monitoring trägt exakt nichts dazu bei, sie schneller zu finden. An diesem Punkt fragt das Management zu Recht, wofür das Geld ausgegeben wurde.
Drei Fragen, die vor der ersten Instrumentierung geklärt sein müssen
Wir gehen in keinen Kickoff mehr ohne diese drei Fragen. Sie klingen banal. Die meisten Kunden haben die Antworten trotzdem nicht sofort parat, und das ist für sich schon ein Signal.
Die erste Frage gilt dem aktuellen Architekturdiagramm. Gemeint ist nicht die Folie von vor drei Jahren, sondern das echte Bild: welche Services mit welchen sprechen, wo synchrone Aufrufe laufen, wo etwas an einer Datenbank hängt, die längst hätte abgelöst werden sollen. In neun von zehn Fällen existiert kein aktuelles Diagramm. Dann ist die erste Aufgabe nicht Instrumentierung, sondern gemeinsam mit dem Kundenteam dieses Diagramm zu zeichnen. Das ist unbequem, aber es ist die Karte, ohne die man im Gelände blind ist.
Die zweite Frage gilt den Störungen der letzten Monate. Bekannte Störungen zeigen, wo das System real bricht, nicht wo es theoretisch brechen könnte. Erzählt der Kunde, dass einmal im Monat nachts ein Batch-Job aus dem Ruder läuft und dann das halbe System steht, ist klar, was zuerst sichtbar werden muss. So entsteht Monitoring, das eine Frage beantwortet, die schon jemand gestellt hat, und zwar schmerzhaft.
Die dritte Frage gilt den kritischen Stellen, also allem, was auf keinen Fall ausfallen darf. Login, Bezahlvorgang, die eine Schnittstelle zum Partnersystem, an der Verträge hängen: dort wird zuerst gemessen. Wer das nicht klärt, instrumentiert den Service, der einmal am Tag eine E-Mail verschickt, mit derselben Tiefe wie den, der pro Sekunde tausend Requests trägt. Der Overhead landet dann an genau der falschen Stelle, dazu in einem eigenen Artikel dieser Serie mehr.
Die Bestandsaufnahme in drei Queries
Die Antworten auf die drei Fragen sind Gespräche, aber der technische Ist-Zustand lässt sich am ersten Tag messen. Wo bereits ein Prometheus läuft, beantworten drei Abfragen im Expression Browser, was das bestehende Monitoring überhaupt abdeckt. Die Abfragen gelten für Prometheus 3.5, die verwendeten Zeitreihen up und ALERTS gibt es seit Jahren unverändert.
sum by (job) (up) / count by (job) (up)Die Zeitreihe up erzeugt Prometheus für jedes Scrape-Target selbst: 1, wenn das Target erreichbar war, 0, wenn der Scrape fehlschlug. Die Abfrage liefert je Job den Anteil erreichbarer Targets. Ein Job mit 0,6 bedeutet, dass 40 Prozent seiner Targets seit dem letzten Scrape nicht antworten, und zeigt damit, welche Teile der Landschaft heute schon unbeobachtet sind.
count by (alertstate) (ALERTS)Prometheus hält für jeden aktiven Alarm eine synthetische Zeitreihe ALERTS mit dem Label alertstate, das pending oder firing ist. Die Abfrage zählt beides. Stehen dort dauerhaft dreißig feuernde Alarme, ist Alert Fatigue nicht das Risiko, sondern der Zustand, und die vorhandenen Regeln gehören vor jeder neuen Instrumentierung auf den Prüfstand.
prometheus_tsdb_head_seriesDie dritte Abfrage zeigt die Zahl der aktiven Zeitreihen im Head-Block, also die Größenordnung dessen, was der bestehende Prometheus gerade trägt. Diese Zahl gehört ins Kickoff-Protokoll, weil jede neue Instrumentierung sie vergrößert und weil sie später zeigt, ob eine Konfiguration außer Kontrolle geraten ist.
Was sich ändert, wenn die Fragen am ersten Tag gestellt werden
Wir haben beide Verläufe erlebt, und der Unterschied ist deutlich. Werden die Fragen erst nach Monaten gestellt, ist innerhalb einer Woche klar, dass die halbe bisherige Instrumentierung am Bedarf vorbeiging, und die Arbeit beginnt von vorn. Werden sie am ersten Tag gestellt, ergibt sich die Priorisierung fast von selbst: bekannte Störungen und kritische Stellen zuerst, der Rest später.
Harte Zahlen zum Zeitgewinn haben wir bewusst nicht erhoben, weil sich zwei Projekte nie sauber vergleichen lassen. Qualitativ ist das Bild eindeutig. Die drei Fragen kosten am Anfang einen halben Tag Gespräch, sie nicht zu stellen kostet Monate.
In der Praxis sieht der gute Verlauf so aus: Der erste Sprint liefert eine Alarmregel für genau die Störung, die der Kunde im Kickoff beschrieben hat, und ein Dashboard für den einen kritischen Pfad, nicht für alles. Beides wird gegen die nächste echte Störung getestet, nicht gegen eine Checkliste. Erst wenn das trägt, kommt die Breite dazu.
Ein Observability-Projekt ist ein Projekt, kein Tool-Setup
Der eigentliche Lerneffekt aus dem ersten Einsatz war nicht technisch, sondern methodisch. Das unstrukturierte Reingehen und Schauen funktioniert nicht, egal wie gut man das Werkzeug beherrscht. Was funktioniert, ist ein Observability-Projekt wie ein Softwareprojekt zu behandeln: mit einer Bestandsaufnahme, mit klaren Zulieferungen des Kundenteams und mit priorisierten Arbeitspaketen. Das Architekturdiagramm liefert dabei der Kunde, nicht die Beratung.
Wir halten die Ergebnisse der ersten Gespräche schriftlich fest und übersetzen sie in Tickets mit Akzeptanzkriterien. Nicht aus Prozessliebe, sondern weil das die stille Annahme aufbricht, alle wüssten ohnehin, was wichtig ist. Sobald eine kritische Stelle in ein Ticket mit Akzeptanzkriterium gegossen wird, kommen die Unklarheiten an die Oberfläche, und genau das ist der richtige Zeitpunkt dafür.
Das Kickoff-Protokoll hat bei uns deshalb immer dieselben vier Anhänge: das gezeichnete Architekturdiagramm, die Liste der Störungen der letzten zwölf Monate mit Ursache und Dauer, die priorisierte Liste der kritischen Stellen und die drei Messwerte aus der Bestandsaufnahme. Fehlt einer davon, ist das Projekt nicht gestartet, sondern nur begonnen.
Wo dieser Ansatz an Grenzen stößt
Die drei Fragen setzen voraus, dass jemand sie beantworten kann. In Organisationen, in denen das Wissen über Architektur und Störungen mit den Leuten gegangen ist, die sie gebaut haben, liefert der Kickoff nur Lücken. Dann muss die Bestandsaufnahme aus den Systemen selbst kommen, etwa aus Traces, die Abhängigkeiten sichtbar machen, und das dauert länger als ein halber Tag.
Bei Greenfield-Systemen gibt es außerdem noch keine Störungshistorie. Dort ersetzt eine Risikoabschätzung entlang der kritischen Pfade die zweite Frage, und sie ist naturgemäß weniger verlässlich als gelebte Erfahrung. Und die Bestandsaufnahme per PromQL greift nur, wo bereits ein Prometheus läuft; bei einem kommerziellen APM ohne offene Schnittstelle bleibt an dieser Stelle nur das Gespräch.
Schließlich sind die drei Fragen ein Startpunkt, keine Methode für die gesamte Laufzeit. Sie priorisieren die ersten Wochen. Was danach kommt, etwa die Frage, wie tief instrumentiert werden darf, bevor der Overhead das System belastet, braucht eigene Regeln.
Das Fazit: Verstehen kommt vor Messen
Der Erfolg eines Observability-Projekts entscheidet sich nicht zwischen kommerziellem APM und Open-Source-Stack und nicht in der Eleganz der Dashboards. Er entscheidet sich in der ersten Woche an der Frage, ob das System verstanden wurde, bevor gemessen wird. Architekturdiagramm, bekannte Störungen und kritische Stellen sind die drei Antworten, die jede weitere Entscheidung tragen.
Wir haben das auf die harte Tour gelernt. Kunden, die uns zum Start eines Observability-Projekts holen, bekommen deshalb zuerst diese drei Fragen und die Bestandsaufnahme, nicht zuerst einen Agenten.