Observability und SLOs
Überblick
Sie können nicht betreiben, debuggen oder verbessern, was Sie nicht sehen können. Observability wird entworfen, nicht nach dem ersten Ausfall nachgerüstet. Die erste Frage bei jedem Vorfall ist „Was hat sich geändert und wer ist betroffen“ – ein System, das das nicht beantworten kann, macht aus einer Fünf-Minuten-Reparatur eine archäologische Ausgrabung.
Die Prinzipien (universell)
- Die drei Signale. Erzeugen Sie strukturierte Logs (maschinenlesbar, nicht Freitext), Metriken (Zählungen, Raten, Dauern) und Traces (den Pfad einer Anfrage über Dienste hinweg). Eine Anfrage trägt eine Korrelations-/Trace-ID Ende-zu-Ende.
- Instrumentieren Sie die goldenen Signale für jede Oberfläche: Rate, Fehler, Dauer (RED) pro Endpunkt/Operation, plus Ressourcensättigung. Ein neuer Endpunkt ist nicht „fertig“, bis er observabel ist.
- Health ist ein Endpunkt, keine Vermutung. Stellen Sie Liveness („Läuft mein Prozess?“) und Readiness („Kann ich Traffic bedienen?“) als separate Prüfungen bereit.
- Definieren Sie SLOs für kritische Journeys, mit SLIs, die sie messen, und einem Error Budget, das die Abwägung zwischen Zuverlässigkeit und neuen Features explizit und datengesteuert macht.
- Alertieren Sie auf Symptome, nicht auf Ursachen. Pagern Sie, wenn Nutzer leiden (SLO-Burn, Readiness schlägt fehl), nicht bei jedem internen Aussetzer. Jeder Alert muss handlungsrelevant sein – ein Alert, auf den niemand reagiert, trainiert Menschen, Alerts zu ignorieren.
Die Mechanismen (dieser Stack)
- Strukturierte JSON-Logs nach stdout, von der Plattform gesammelt (z.B. AKS → Azure Monitor / Log Analytics). Kein Freitext-Logging in Diensten.
- OpenTelemetry im App-Server und PostGraphile; Export von Traces/Metriken an Azure Monitor / Application Insights (oder Prometheus/Grafana).
- Korrelations-ID propagiert über den Datenpfad – am Edge generiert, vom Browser über die App zu PostGraphile zusammen mit Kontext-Headern weitergegeben, an jede Log-Zeile und jeden Span angehängt.
- RED-Metriken pro HTTP-Route und GraphQL-Operation; Postgres-Slow-Query-Log +
pg_stat_statements. - Liveness/Readiness-Endpoints, an Kubernetes-Probes angebunden (siehe
cloud-delivery-aks). Readiness spiegelt die tatsächliche Abhängigkeitsgesundheit wider (kann die Datenbank erreicht werden?), nicht nur, dass der Prozess läuft. - Frontend: Melden Sie Web Vitals und Client-Fehler an dasselbe Backend.
- SLOs pro Journey mit Dashboards und Burn-Rate-Alerts.
Wann skalieren
Ein Pre-Launch-/Lokalprojekt implementiert jetzt strukturierte Logs + Health-Endpoints und verschiebt SLOs/Alerting, bis echte Nutzer zu schützen sind. Geben Sie den Modus im ersten Entscheidungsdokument an.
Vollständige Begründung: Artikel IX und XVI der Verfassung, gebündelt in engineering-constitution/references/engineering-constitution.md.