Monitoring und Observability für Webanwendungen im Betrieb

Kurz gefasst: Monitoring sagt Ihnen, dass etwas nicht stimmt, Observability hilft Ihnen herauszufinden, warum. Für eine produktive Webanwendung brauchen Sie dafür strukturierte Logs, ein paar aussagekräftige Metriken, Fehler-Tracking und bei verteilten Systemen Traces. Entscheidend ist, dass Alarme nur bei echten Problemen für Nutzer auslösen, damit Ihr Team sie ernst nimmt.

Monitoring und Observability: der Unterschied

Klassisches Monitoring prüft bekannte Zustände: Ist der Server erreichbar, ist die CPU-Last zu hoch, ist die Festplatte voll? Das ist nötig, reicht aber bei modernen Webanwendungen nicht aus. Die meisten Störungen sind deutlich unauffälliger als ein kompletter Ausfall: ein langsamer Checkout bei einer bestimmten Zahlungsart oder Fehler nur für Nutzer eines bestimmten Browsers.

Observability beschreibt die Fähigkeit, solche unbekannten Probleme aus den Daten heraus zu verstehen, ohne vorher zu wissen, wonach man sucht. Dafür muss die Anwendung genug Kontext über sich selbst preisgeben.

Die drei Signale: Logs, Metriken und Traces

Logs

Logs erzählen, was passiert ist. Damit man sie durchsuchen kann, sollten sie strukturiert sein, also als JSON mit festen Feldern wie Zeitpunkt, Level, Request-ID und Nutzer-ID statt als freier Text. Eine Request-ID, die durch alle Dienste weitergereicht wird, macht aus verstreuten Zeilen eine zusammenhängende Geschichte.

Metriken

Metriken sind Zahlen über die Zeit: Anfragen pro Sekunde, Antwortzeiten, Fehlerquote, Auslastung. Das Site-Reliability-Engineering-Handbuch von Google nennt vier "Golden Signals" als guten Ausgangspunkt: Latenz, Traffic, Fehler und Auslastung. Antwortzeiten sollten Sie als Perzentile betrachten (etwa p95), weil Durchschnittswerte langsame Ausreißer verdecken.

Traces

Ein Trace verfolgt eine einzelne Anfrage durch alle beteiligten Komponenten: Frontend, API, Datenbank, externe Dienste. Damit sehen Sie, welcher Schritt die Zeit kostet. Bei einem Monolithen mit einer Datenbank ist das weniger wichtig als bei mehreren Diensten, aber auch dort zeigen Traces langsame Abfragen sehr deutlich.

Werkzeuge, die sich bewährt haben

OpenTelemetry hat sich als herstellerneutraler Standard für das Erfassen von Logs, Metriken und Traces durchgesetzt. Wenn Sie Ihre Anwendung damit instrumentieren, können Sie das Backend später wechseln, ohne den Code anzufassen.

Für die Auswertung gibt es zwei Wege. Selbst betrieben: Prometheus für Metriken, Grafana für Dashboards, Loki für Logs und Tempo für Traces. Das gibt volle Kontrolle über die Daten, erfordert aber Betriebsaufwand. Als Dienst: Anbieter wie Grafana Cloud, Datadog oder Better Stack nehmen Ihnen den Betrieb ab. Fehler-Tracking mit Sentry (gehostet oder selbst betrieben) gehört in fast jedes Projekt, weil es Ausnahmen mit Stacktrace, Release und betroffenem Nutzer gruppiert.

Ergänzend lohnt sich Uptime-Monitoring von außen, das wichtige Seiten und Endpunkte aus mehreren Regionen prüft. Und im Frontend zeigen Real-User-Messungen der Core Web Vitals, wie schnell Ihre Seite bei echten Besuchern ist. Wie Sie daraus feste Grenzen ableiten, erklärt unser Beitrag zu Performance-Budgets.

Alarme, die man ernst nimmt

Auf Symptome alarmieren

Alarmieren Sie auf das, was Nutzer spüren: steigende Fehlerquote, langsame Antworten, fehlgeschlagene Bestellungen. Eine kurz hohe CPU-Last ohne Auswirkung auf Nutzer ist ein Fall für das Dashboard, nicht für den nächtlichen Anruf.

Ziele definieren

Service Level Objectives (SLOs) legen fest, welche Verfügbarkeit und Geschwindigkeit Sie anstreben. Ein Alarm löst aus, wenn Sie dieses Ziel zu schnell verbrauchen. Das reduziert Fehlalarme spürbar.

Deployments sichtbar machen

Markieren Sie jedes Deployment in Ihren Dashboards. Viele Störungen beginnen mit einer Auslieferung, und eine Markierung im Diagramm spart lange Suche. Wie Deployments sauber automatisiert werden, steht in unserem Beitrag zu CI/CD-Pipelines.

Datenschutz bei Logs und Monitoring

Logs enthalten schnell personenbezogene Daten: IP-Adressen, E-Mail-Adressen, manchmal ganze Formularinhalte. Nach DSGVO brauchen Sie dafür eine Rechtsgrundlage, klare Aufbewahrungsfristen und bei externen Diensten einen Auftragsverarbeitungsvertrag. In der Praxis heißt das: Passwörter, Tokens und Zahlungsdaten nie loggen, IP-Adressen kürzen oder pseudonymisieren, Logs nach einer festen Frist löschen und Anbieter mit Speicherort in der EU bevorzugen.

Häufige Fragen (FAQ)

Ab wann braucht eine Webanwendung Monitoring?

Ab dem ersten echten Nutzer. Mindestens Uptime-Monitoring und Fehler-Tracking sollten vom Start an laufen. Metriken, Dashboards und Traces kommen mit wachsender Nutzung und Komplexität hinzu.

Was kostet Observability?

Das hängt fast vollständig von der Datenmenge ab. Wer jede Debug-Zeile speichert, zahlt bei Cloud-Anbietern schnell viel. Sinnvolle Log-Level, Sampling bei Traces und kurze Aufbewahrungsfristen halten die Kosten im Rahmen.

Reicht nicht einfach ein Uptime-Check?

Nein. Ein Uptime-Check bemerkt, dass Ihre Seite komplett ausgefallen ist. Er bemerkt nicht, dass der Login für einen Teil der Nutzer fehlschlägt oder eine Seite plötzlich mehrere Sekunden braucht, und genau das sind die häufigeren Probleme.

Sollten wir Monitoring selbst betreiben oder einkaufen?

Für kleine Teams ist ein gehosteter Dienst meist wirtschaftlicher, weil der Betrieb eines eigenen Stacks Zeit kostet. Selbst betreiben lohnt sich, wenn Datenschutzvorgaben es verlangen oder die Datenmengen so groß sind, dass Dienste teuer werden. Mit OpenTelemetry bleiben Sie in beiden Fällen flexibel.

Fazit

Gutes Monitoring erkennt man daran, dass Ihr Team Probleme vor den Kunden bemerkt und in Minuten statt Stunden die Ursache findet. Das gelingt mit wenigen, gut gewählten Signalen und Alarmen, die nur bei echten Auswirkungen auslösen. Wie sich das bei wachsender Last entwickelt, beschreibt unser Artikel zur Skalierung von Webanwendungen. Wenn Sie eine Webanwendung betriebssicher aufstellen möchten, sprechen Sie mit uns über Webentwicklung.