Das Ziel ist, dein System ist unhealthy zu wissen, bevor es deine Nutzer dir sagen. Gutes Observability ermöglicht es dir, Fragen zu beantworten, die du nicht vorhergesehen hast — nicht nur eine feste Reihe von Dashboards zu überprüfen. Als Tech Lead richtest du das vor dem Incident ein, nicht während.
Die drei Säulen
- Metrics — günstige numerische Zeitreihen (Request Rate, Error Rate, Latency, Queue Depth). Großartig für Trends, Alerting und SLOs.
- Logs — detaillierte Event-Datensätze für warum etwas passiert ist. Mache sie strukturiert (JSON) und füge eine Correlation ID bei, damit du eine einzelne Request über Services hinweg verfolgen kannst.
- Traces — der Pfad einer einzelnen Request über Services, zeigt, wo Zeit tatsächlich verwendet wird. Essentiell in verteilten Systemen.
Auf Symptome, nicht auf Rauschen alerten
Page auf das, was der Nutzer spürt, nicht auf internes Jitter. Verankere Alerts an SLOs: Error Rate, Latency (p95/p99) und Availability. Ein CPU-Spike ist kein Incident; Checkout fällt für 2% der Nutzer aus ist.
| Alert auf | Nicht pagen auf |
|---|---|
| Error Rate breitet SLO-Verletzung | Einzelner CPU-Spike |
| p99 Latency über Budget | Eine langsame Request |
| Fehlgeschlagene Health Checks | Festplatte bei 60% |
Mache Alerts umsetzbar
Jeder Alert sollte dringend, real und umsetzbar sein — er nennt, was falsch ist und zeigt auf einen nächsten Schritt. Alerts, die ständig auslösen, trainieren das Team, sie zu ignorieren; Alert Fatigue ist, wie echte Incidents übersehen werden. Füge Health Checks und Dashboards hinzu, die die Golden Signals auf einen Blick zeigen.
Warum es wichtig ist
Teams, die nur nach einem Incident beobachten, fliegen blind: Sie erfahren von Ausfällen von wütenden Kunden und debuggen mit Raterei. In Observability vorab zu investieren verwandelt 3-Uhr-Morgens-Mysterien in 5-Minuten-Diagnosen, verringert Downtime und befreit das Team zum Ausliefern statt Feuerlöschen.