Die „vier goldenen Signale" von Google SRE — Latency, Traffic, Errors, Saturation — sind die Baseline jedes Architektur-Interviews. In der Praxis werden sie auswendig aufgezählt und ein Häkchen wird gesetzt; ein Jahr später zeigt das Incident-Postmortem, dass keines der vier in der Produktion erwischt hat, was es erwischen sollte.
Was jedes Signal tatsächlich erfasst
Latency. Nicht der Mittelwert — der maskiert den Tail. Nur p95 / p99. Ein Request, der jedes zehnte Mal fünf Sekunden braucht, ist im Mittelwert unsichtbar; der unglückliche Nutzer geht. Latency erfolgreicher Requests von Latency fehlerhafter Requests trennen: ein 500 in 50 ms und ein 200 in 5 Sekunden sind zwei verschiedene Brände.
Traffic. Nicht „wie viele RPS", sondern wohin sie gehen. Per-Target-Imbalance am Load Balancer von mehr als 40 % bedeutet versteckte Degradation: eine Node wird zum digitalen schwarzen Loch, 99 % des Traffics werden bedient, 1 % hängt ohne Alert. Slowness ist schlimmer als ein Ausfall — Retention sinkt lautlos.
Errors. Explizite 5xx ist die halbe Wahrheit. Implizite Fehler — Timeouts, abgestürzte Upstreams, Retries, die im sechsten Anlauf „erfolgreich" wurden — erreichen den Standard-5xx-Counter nie. Das Error Budget steht auf der Success-Rate, nicht auf 5xx.
Saturation. Die irreführendste Metrik. Ein I/O-bound Service (wartet auf die Datenbank oder eine externe API) zeigt bei p99-Latenz von 8 Sekunden CPU bei 12 %. Die Pods sind nicht ausgelastet — sie warten. HPA autoscaling/v2 auf CPU/Memory ist hier komplett blind; für den Autoscaler sieht es aus wie „ein System ohne Traffic", also skaliert er herunter. Saturation misst man über Request Rate, Queue Depth, SLO Burn Rate — also über KEDA, nicht über den nativen HPA.
Ursache-Wirkungs-Kette eines Ausfalls: traffic↑ → saturation↑ → latency↑ → errors↑. Wer sie verfolgt, fängt das Problem vor dem Nutzer-Impact ab. Das Aufzählen der Signale aus dem Kopf nicht.
Warum der Stack VictoriaMetrics + Loki heißt
Prometheus als Referenzimplementierung der vier goldenen Signale ist nach wie vor Standard. In Produktion 2026 fällt die Wahl häufiger auf VictoriaMetrics: 10-fache Storage-Dichte, 10-mal mehr aktive Series, MetricsQL als Obermenge von PromQL, eingebauter Long-Term-Storage ohne separates Thanos/Cortex. vmagent ist als Scraper leichter als Prometheus, vmauth deckt Multi-Tenancy ab.
Logs — Loki. Nicht weil es OpenSearch „schlägt", sondern weil Full-Text-Indexing teuer und selten nötig ist. Loki indexiert nur Labels und speichert den Log-Körper günstig. Die Korrelation zwischen Metrik und Log läuft über eine gemeinsame trace_id oder request_id, nicht über einen Full-Text-Join. Promtail ist im Maintenance-Mode: auf frischen Clustern steht Grafana Alloy — ein einziger Pipeline-Collector in River-Language, der Promtail + node-exporter + OTel Collector durch ein DaemonSet ersetzt.
Die Erklärung „wir haben Monitoring" über Tool-Namen ist ein schwaches Signal. Stark ist die Erklärung über den Data Flow:
Application → OTel SDK / OBI
→ Collection (vmagent / Alloy)
→ Storage (VictoriaMetrics / Loki)
→ Visualization (Grafana)
→ Alerting (Alertmanager)Das Schema hält beim Austausch von Knoten: Loki gegen OpenSearch, VictoriaMetrics gegen Datadog — die Struktur bleibt gleich. Ein Architekt erklärt den Flow und die Trade-offs an jedem Knoten; ein Engineer zählt Tool-Namen auf.
Drei Fallen hinter „wir haben Monitoring"
Producer überwachen, nicht den Output. Die ALB-Target-Group ist vier Tage lang grün, während sitemap.xml stale ist, weil der Hintergrundservice, der sie erzeugt, seinen Alias verloren hat. Der Producer-Health-Check fängt das nie. Jedes extern konsumierte Artefakt bekommt einen eigenen Freshness-Probe — eine Last-Modified-Age-Prüfung. Den Output überwachen, nicht nur den Producer.
Cardinality-Explosion in Labels. user_id, session_id, request_id, pod_uid, path ohne Normalisierung — innerhalb von Wochen ein sofortiger TSDB-Tod. Diese Labels werden im Metrics-Code-Review mit derselben Disziplin geblockt wie Produktionscode. High-Cardinality-Daten leben in Trace-Attributen (sampled) und Log-Feldern, nicht in Metric-Labels.
Local Alerting auf demselben Cluster. Fällt der Cluster aus, fallen auch die Alerts aus, die vor dem Ausfall hätten warnen sollen. Control-Plane-Observability — ein separater Cluster, ein Managed Service oder ein externer Receiver. Push, nicht Pull. Wenn der beobachtete Cluster fällt, sieht der Beobachter die Stille als Signal — nicht als fehlende Daten.
Das Minimum, das „wir haben Monitoring" wirklich bedeutet
Nicht 50 Alerts, sondern 5–8 actionable. Jeder Alert trägt eine runbook_url in den Annotations. Jeder Critical-Alert ist eine SLO Burn Rate mit Multi-Window-Setup, kein Threshold-Flap. Jeder Service liefert strukturierte JSON-Logs mit trace_id, service, team, env. Und einmal pro Quartal ein Disaster-Visibility-Test: ein simulierter Cluster-Ausfall. Wenn die Alerts nicht ankommen und die Dashboards dunkel bleiben, hinkt Observability ein bis zwei Stufen hinterher — und ein echter Incident zeigt das teurer als eine Übung.