Monitoring-Mythen: Was Dashboards nicht zeigen
Grüne Dashboards sind kein Beweis für gesunde Systeme. Wir zeigen, welche Metriken wirklich warnen - und welche nur beruhigen.
Das grüne Trugbild
Warum grüne Dashboards lügen
Ein Dashboard ist ein Ausschnitt. Es zeigt, was jemand vor Monaten für wichtig hielt - nicht zwangsläufig das, was heute schiefläuft. Wer „alles grün“ sagt, meint meist „alles erreichbar“. Das ist nicht dasselbe.
HTTP 200 ist kein Gesundheitszeugnis
Ein Ping aus dem Rechenzentrum nebenan beweist, dass TCP funktioniert. Mehr nicht. Eine Health-Endpoint-Route, die hardcodiert „OK“ zurückgibt, sagt nichts über die dahinterliegende Datenbank, die volle Queue oder den abgelaufenen API-Token zum Payment-Provider. Wir haben Setups gesehen, in denen das Monitoring zwölf Stunden grün war, während Bestellungen still ins Leere liefen.
Durchschnittswerte verstecken die Hälfte des Schmerzes
Wer eine durchschnittliche Antwortzeit von 180 ms feiert, übersieht regelmäßig, dass 5 Prozent der Nutzer 4 Sekunden warten. Mittelwerte glätten Ausreißer weg - genau die Ausreißer, die in Kundenanrufe und Cart-Abbrüche münden. P95 und P99 sind nicht optional, sie sind die Wahrheit.
Vom Symptom zur Aussage
SLI, SLO und der Unterschied zu „läuft halt“
Wer keine SLIs definiert hat, misst zufällig. Wer keine SLOs vereinbart hat, kann nicht entscheiden, ob ein Vorfall wichtig ist.
SLIs sind die Fragen, nicht die Antworten
Ein Service Level Indicator ist eine Zahl, die einen geschäftsrelevanten Aspekt misst: Anteil erfolgreich abgeschlossener Checkouts, P95-Latenz für eingeloggte Nutzer, Verfügbarkeit der Lager-API aus Sicht der Filiale. Nicht „CPU-Auslastung“ - das ist eine Ursache, kein Signal. SLIs werden aus Nutzersicht definiert, nicht aus Sicht des Servers.
SLOs sind Zusagen, keine Hoffnung
Ein Service Level Objective verbindet einen SLI mit einem Zielwert und einem Zeitfenster: „99,5 Prozent erfolgreiche Checkouts, gemessen über 30 rollierende Tage“. Erst damit lässt sich ein Error Budget rechnen - also wie viel Schiefgehen pro Monat tolerierbar ist, bevor wir nicht mehr neue Features deployen, sondern stabilisieren.
Monitoring-Audit gefällig?
Wir lesen Ihr Setup ehrlich gegen - und sagen Ihnen, wo die blinden Flecken sitzen.
Drei Schichten Observability
Metriken, Logs, Traces - und wann was hilft
Prometheus, Grafana und Loki sind keine Strategie. Sie sind ein Werkzeugkasten. Wer sie ohne klares Konzept einschaltet, sammelt Daten und keine Erkenntnisse.
Metriken: aggregiert, billig, gut für Trends
Prometheus speichert numerische Zeitreihen - Requests pro Sekunde, Queue-Tiefen, Histogramme der Antwortzeiten. Günstig, schnell abfragbar, ideal für Dashboards und Alarme. Aber: Metriken sagen, dass etwas passiert ist. Sie sagen selten warum. Wer eine Latenz-Spitze sieht, weiß noch nicht, ob es der Datenbank-Index, der Garbage Collector oder ein Hänger im Drittsystem war.
Logs: detailreich, teuer, gut für Forensik
Strukturierte JSON-Logs in Loki oder einem ELK-Stack sind unverzichtbar, wenn ein Vorfall bereits passiert ist und Sie nachvollziehen müssen, was die Anwendung gesehen hat. Aber Logs sind teuer in Speicher und Index-Kosten - und nichts ist nutzloser als 200 GB unstrukturierter Zeilen ohne Korrelations-ID. Jeder Request bekommt eine Trace-ID, sonst ist die Suche reine Glückssache.
Traces: die Verkettung sichtbar machen
OpenTelemetry-Traces zeigen, durch welche Services und Datenbank-Calls ein einzelner Request lief - und wo die Sekunden verloren gingen. Erst Traces machen sichtbar, dass die langsame API tatsächlich nur 50 ms eigene Logik hat und 1,2 Sekunden auf einen externen Webhook wartet. Ohne Tracing rät man sich an Verteilten-System-Problemen blind.
Alerting, das aufwacht
Alerts, die nachts klingeln dürfen
Ein Alert, der niemanden weckt, ist nutzlos. Ein Alert, der alle weckt, ist ebenfalls nutzlos. Die Wahrheit liegt dazwischen - und wird durch SLOs definiert, nicht durch Bauchgefühl.
Symptom-basiert statt Ursachen-basiert alarmieren
Alerts auf „CPU > 80 Prozent“ sind in der Regel Rauschen - eine CPU darf belastet sein, das ist ihr Job. Alarmiert wird, wenn ein nutzerrelevantes Symptom auftritt: zu viele 5xx-Antworten, gestiegene P95-Latenz, fallende Erfolgsquote der Hauptflows. Wenn ein Alert nicht in einen Satz passt, der einen Schaden für Sie beschreibt, ist es ein Diagnose-Hinweis, kein Pager-Event.
Burn-Rate-Alerts statt Schwellenwerte
Statt „Latenz > 500 ms für 5 Minuten“ definieren wir Alerts auf das Verbrennen des Error Budgets: schnelles Brennen (1 Stunde verbraucht 2 Prozent des Monats-Budgets) weckt jemanden nachts. Langsames Brennen (über 3 Tage 10 Prozent verbraucht) erzeugt nur ein Ticket. Damit bekommt jeder Alert ein klares Kriterium für Dringlichkeit - und Bereitschafts-Teams hören auf, an Alarm-Müdigkeit zu sterben.
Monitoring-Prinzip
Wir messen nicht, damit ein Dashboard hübsch aussieht. Wir messen, damit Sie nachts wissen, ob Sie aufstehen müssen - und wenn ja, was Sie anfassen sollen.
Unser Stack-Kompass
Womit wir bei MARCODES arbeiten
Tools sind Mittel, kein Selbstzweck. Wir wählen so klein wie möglich, so groß wie nötig - und immer mit klaren Backup-Pfaden.
Prometheus plus Grafana als Basis
Für die meisten Setups reichen ein selbst gehostetes Prometheus, Alertmanager und Grafana - gehostet in Deutschland, nicht in irgendeiner US-Cloud. Pro Service exportieren wir Standard-Metriken (RED: Rate, Errors, Duration) plus zwei oder drei fachliche Kennzahlen. Mehr nicht. Dashboards sind nach Diensten geschnitten, nicht nach Personen.
Loki und OpenTelemetry für Tiefe
Strukturierte Logs gehen nach Loki, OpenTelemetry-Traces je nach Größe nach Tempo oder Jaeger. Pro Request eine Trace-ID, in jedem Log-Eintrag der Service-Name und der Hostname. Damit ist eine Forensik in Minuten machbar, nicht in Stunden - und Bereitschafts-Engineers müssen nicht raten, sondern lesen.
Synthetic Checks als Außenperspektive
Internes Monitoring sieht das System aus seiner eigenen Sicht. Was es nicht sieht: DNS-Probleme, abgelaufene Zertifikate, CDN-Aussetzer, einen verschluckten Cloudflare-Pop. Wir setzen synthetische Checks aus drei Regionen - Frankfurt, Amsterdam, Wien - die alle paar Minuten den echten Bestellfluss durchspielen. Wenn dieser Check rot wird, ist es ein realer Kundenschaden, kein Bauchgefühl.
Artikel teilen
Wollen Sie Monitoring, das aufdeckt statt beruhigt?
Wir prüfen Ihr Setup gegen SLOs, Alert-Hygiene und Observability-Tiefe - und sagen offen, wo blinde Flecken liegen.
Ein Monitoring-Audit dauert bei uns typischerweise zwei bis drei Tage und endet mit konkreten Maßnahmen - nicht mit einer 80-seitigen PDF, die niemand liest.