Cloud & Infrastruktur
Drei Dashboards statt dreissig
Observability scheitert selten am Werkzeug. Sie scheitert daran, dass niemand mehr hinschaut.
Fast jede Umgebung, die wir übernehmen, hat Grafana. Und fast jede hat Dashboards, die seit Monaten niemand geöffnet hat. Das Problem ist nicht zu wenig Beobachtung – es ist zu viel davon, ohne Frage dahinter.
Jedes Dashboard beantwortet genau eine Frage
Bevor ein Panel entsteht, muss klar sein, welche Entscheidung es unterstützt. „Ist der Dienst gesund?“ ist eine Frage. „CPU-Auslastung aller Pods“ ist keine – es ist eine Zahl.
Wir kommen fast immer mit drei Ansichten aus:
- Geht es dem Nutzer gut? Fehlerrate, Latenz an der Kante, erfolgreiche Kernaktionen pro Minute.
- Geht es dem System gut? Sättigung der knappen Ressourcen: Verbindungen, Queue-Länge, Speicher.
- Was hat sich zuletzt geändert? Deployments, Konfigurationsänderungen, Feature-Flags – als Marker in der Zeitachse.
Alles Weitere ist Diagnose. Diagnose gehört in Ad-hoc-Abfragen, nicht auf ein Dashboard.
Alarme, die man ernst nehmen kann
Ein Alarm, der wöchentlich fehlfeuert, wird stummgeschaltet. Dann ist er kein Alarm mehr. Unsere Regel: Jeder Alarm hat einen Namen, eine Schwelle, die aus dem Nutzerversprechen abgeleitet ist, und ein Runbook. Fehlt eines davon, wird er gelöscht, nicht ergänzt.
Ein Alarm ist eine Bitte um menschliche Aufmerksamkeit. Man verschickt sie sparsam.
Logs mit Kontext, nicht mit Volumen
Strukturiert, mit Request-ID, mit dem Warum – nicht dem Was. payment declined: limit exceeded, limit=500 amount=620 sagt alles. error in handler sagt nichts, und es steht trotzdem in jedem zweiten Log, das wir sehen.
Was am Ende bleibt
Weniger Panels, weniger Alarme, weniger Logzeilen – und ein Team, das bei einem Vorfall in dreissig Sekunden weiss, wo es hinschauen muss. Das ist Observability. Der Rest ist Speicherplatz.