Observability: Verstehen was deine Systeme wirklich tun
Observability bedeutet: du kannst jeden Systemzustand aus den vorhandenen Daten rekonstruieren – ohne manuell SSH-Sessions zu öffnen. Metriken, Logs und Traces sind die drei Säulen die zusammen vollständiges Verständnis geben.
PrometheusGrafanaLokiMetrikenAlerting
Der Observability-Stack: Prometheus, Grafana, Loki
Die drei wichtigsten Open-Source-Tools für vollständige Observability:
Prometheus: Metriken-Datenbank die regelmäßig Endpunkte scrapet. Services exponieren /metrics-Endpunkte, Prometheus sammelt und speichert Zeitreihen.
Grafana: Visualisierung für Prometheus-Metriken, Loki-Logs und viele weitere Quellen. Dashboards, Alerting, Exploration – die zentrale Anlaufstelle.
Loki: Log-Aggregation von Grafana Labs. Speichert Logs mit Labels, abfragbar mit LogQL. Keine Index-Erstellung für Log-Inhalte – günstiger als Elasticsearch für ähnliche Use Cases.
Der komplette Stack läuft als Docker Compose Stack auf einem normalen VPS. Für Self-Hosting-Setups: Prometheus + Grafana + Loki + Promtail (Log-Shipper) ist das Standard-Rezept.
Was man messen sollte – und was nicht
Metriken sammeln ist einfach – die richtigen sammeln ist die Kunst. Die vier goldenen Signale:
Latenz: Wie lange dauern Requests? Percentile (p50, p95, p99) sind aussagekräftiger als Durchschnitte.
Traffic: Wie viele Requests kommen rein? Trends erkennen, Kapazität planen.
Saturation: Wie ausgelastet ist das System? CPU, RAM, Disk I/O, Netzwerk-Bandbreite.
Für KI-Automatisierungen zusätzlich: Token-Verbrauch, Modell-Latenz pro Request, Queue-Länge. Diese Business-Metriken sind oft wertvoller als technische Infrastruktur-Metriken.
Alerting: Benachrichtigungen die wirklich helfen
Schlechtes Alerting ist schlimmer als gar keins – Alert Fatigue führt zu ignorierten Benachrichtigungen. Prinzipien für sinnvolles Alerting:
Nur actionable Alerts: Wenn kein Mensch eingreifen muss, kein Alert. Automatische Recovery-Mechanismen zuerst, dann Alert.
Symptome, nicht Ursachen: Alert auf „Nutzer können sich nicht einloggen" statt „Datenbank CPU hoch".
Grafana Alerting: Regeln direkt in Grafana definieren, Benachrichtigungen per Telegram, Slack, E-Mail oder Webhook – alles ohne externe Dienste
Uptime Kuma: Einfaches Monitoring für externe Erreichbarkeit – HTTP-Checks, Ping, Port-Checks mit Telegram-Benachrichtigung bei Ausfall
Häufige Fragen zu Observability
Monitoring fragt vorher bekannte Fragen: „Ist der Server up?" Observability erlaubt unbekannte Fragen zu beantworten: „Warum ist Request XY langsam?" Monitoring ist reaktiv auf bekannte Probleme, Observability ist proaktive Exploration. Beide sind komplementär.
Prometheus + Grafana + Loki auf einem kleinen Server: ca. 1–2 GB RAM. Mit Retention von 15 Tagen und normaler Metrik-Dichte braucht Prometheus ca. 2–5 GB Disk. Loki komprimiert Logs gut – 10 GB reichen für Wochen auf einem kleinen Setup.
Für Self-Hosting-Setups und kleine Teams: nein – Prometheus direkte Instrumentierung reicht. OpenTelemetry (OTel) lohnt sich wenn: mehrere Sprachen/Services instrumentiert werden sollen, vendor-neutrale Traces nötig sind, oder in ein größeres Observability-Platform-Ökosystem eingebunden wird.
prometheus-client Library: Counter, Gauge, Histogram, Summary als Python-Objekte definieren, `/metrics`-Endpoint in FastAPI/Flask exposen. Prometheus scrapet dann automatisch. Fünf Zeilen Code – danach sind alle Metriken in Grafana verfügbar.