Wenn Ihre Anwendung um 3 Uhr morgens ausfällt – wissen Sie es vor Ihren Kunden? Wenn nicht, fehlt Monitoring und Observability. Wir bauen Observability-Stacks, die kritische Probleme sofort sichtbar machen, Trends rechtzeitig erkennen und im Incident-Fall die richtigen Informationen in Sekunden liefern – nicht nach Stunden manueller Log-Suche.
Die drei Säulen der Observability
Metrics – was passiert?
Metriken sind numerische Werte über die Zeit: CPU-Last, Memory-Verbrauch, HTTP-Request-Raten, Datenbank-Query-Zeiten, Geschäfts-KPIs. Wir setzen typischerweise Prometheus für Sammlung und Speicherung ein, Grafana für Visualisierung. Bei Cloud-nativen Setups auch Cortex, Thanos oder kommerzielle Alternativen wie Datadog oder New Relic.
Logs – was ist passiert?
Logs dokumentieren einzelne Ereignisse mit Zeitstempel und Kontext. Für Sammlung und Auswertung nutzen wir den ELK-Stack (Elasticsearch, Logstash, Kibana) oder das modernere Loki (Grafana). Bei Cloud-Setups oft AWS CloudWatch Logs, Azure Log Analytics oder GCP Cloud Logging.
Traces – warum ist es passiert?
Distributed Tracing macht Request-Flüsse durch Microservices sichtbar – wo wurde Zeit verbraucht, wo gab es Latenz-Spitzen? Wir setzen Jaeger, Zipkin oder OpenTelemetry ein, manchmal kommerzielle Plattformen wie Datadog APM oder New Relic.
Application Performance Monitoring
Speziell für Applikations-Performance setzen wir APM-Tools ein:
- Sentry – Industriestandard für Error-Tracking mit hervorragender Source-Map-Integration
- New Relic – tiefe APM-Insights inklusive Code-Level-Profiling
- Datadog – integrierter Stack aus Metrics, Logs, Traces und APM
- Blackfire und Tideways – PHP-spezifische Profiler für Performance-Tuning
Was wir an Observability bauen
- Greenfield-Observability-Stacks für neue Anwendungen
- Retrofit-Monitoring für bestehende Systeme ohne Sichtbarkeit
- Custom Dashboards für technische Teams und Business-Stakeholder
- Alert-Strategien mit sinnvoller Schwellenwert-Definition (kein „Alert-Fatigue”)
- On-Call-Setups mit PagerDuty, Opsgenie oder kostenlosen Alternativen
- SLO/SLI-Definitionen für service-orientierte Zuverlässigkeits-Messung
- Incident-Response-Prozesse mit dokumentierten Runbooks
Worauf wir bei Observability achten
Sinnvolle Alerts statt Alert-Fatigue
Wir definieren Alerts nach dem Prinzip „Symptom statt Ursache”: Alarmiert wird, wenn echte User-Probleme auftreten, nicht jedes Mal, wenn eine Festplatte zu 70 Prozent voll ist. Das verhindert Alert-Fatigue und sorgt dafür, dass Alerts ernst genommen werden.
Cardinality im Griff behalten
Prometheus und ähnliche Time-Series-Datenbanken werden langsam und teuer, wenn Cardinality explodiert. Wir achten auf sinnvolle Label-Designs – ohne User-IDs oder Request-IDs als Prometheus-Labels.
Korrelation zwischen Telemetrie-Quellen
Metriken, Logs und Traces sollten korrelierbar sein. Bei einem Spike in der Error-Rate möchte man mit einem Klick zu den passenden Logs und Traces springen können. Wir setzen das über konsistente Trace-IDs und Service-Labels um.
Long-Term Storage
Hot-Storage für die letzten 7 Tage, Cold-Storage für historische Daten. Cortex/Thanos für skalierbare Prometheus-Setups, S3 für Log-Archiv. Damit bleiben Forensik und Trend-Analysen möglich, ohne die laufenden Kosten zu sprengen.
Verwandte Leistungen
Monitoring ist Teil jedes professionellen Setups – siehe Cloud-Infrastruktur und Kubernetes. Alerts werden über CI/CD-Pipelines als Code verwaltet. Sicherheits-Monitoring ist Teil von DevSecOps. Übersicht aller Leistungen: DevOps-Engineering.
Mini-Case aus unserer Praxis
Observability-Stack für E-Commerce-Plattform
Aufbau eines Observability-Stacks für eine mittelständische E-Commerce-Plattform, die bisher nur Server-Monitoring (CPU, RAM, Disk) hatte. Ziel: Sichtbarkeit über Application-Performance, Business-Metriken (Bestell-Conversion, Checkout-Abbrüche), Security-Events. Stack: Prometheus für Metriken, Grafana für Dashboards (Tech-Dashboard + Business-Dashboard), Loki für Logs, Tempo für distributed Tracing, Sentry für Application-Errors, Alertmanager mit PagerDuty-Integration für kritische Alerts. Resultat: Anwendungs-Incidents werden im Schnitt deutlich früher erkannt – meist durch Monitoring, nicht durch Kunden-Beschwerden. Mean Time to Detection (MTTD) von Stunden auf Minuten reduziert.
Häufige Fragen zu Monitoring und Observability
Prometheus + Grafana oder kommerzielle Tools wie Datadog?
Prometheus + Grafana für die meisten Setups: Open-Source, kostenlos im Software-Sinne, unter eigener Kontrolle, hervorragende Integration in Kubernetes. Datadog/New Relic wenn Sie schnellen Setup wollen, sehr viel Tooling im Paket brauchen und das Budget haben (Datadog kann teuer werden).
Was ist Alert-Fatigue, und wie vermeiden Sie das?
Alert-Fatigue entsteht, wenn zu viele unwichtige Alerts kommen – Menschen ignorieren dann auch wichtige. Wir definieren Alerts nach dem Prinzip „Symptom statt Ursache”: Alarmiert wird, wenn echte User-Probleme auftreten, nicht jedes Mal, wenn eine Festplatte 80 Prozent voll ist (das ist ein Warning, kein Alert).
Wie integriert man Logs aus verschiedenen Quellen?
Strukturiertes Logging in JSON ist Standard – damit lassen sich Logs aus Anwendungen, Web-Servern, Datenbanken und Kubernetes-Pods einheitlich indexieren. Sammlung über Fluent Bit oder Promtail, Speicherung in Loki oder Elasticsearch, Visualisierung in Grafana oder Kibana. Trace-IDs in Logs ermöglichen Korrelation zwischen Logs und Traces.
Was sind SLOs und brauchen wir die?
SLO = Service Level Objective. Klare Zuverlässigkeits-Ziele wie „99,9 Prozent der API-Requests in unter 500ms beantwortet”. Daraus leitet sich Error Budget ab. Sehr empfehlenswert für service-orientierte Teams – schafft messbare Ziele und faktenbasierte Prioritäten.
