Monitoring und Observability: Software im Betrieb im Blick behalten

Ihre Anwendung läuft, der Launch ist geschafft, und alle atmen auf. Doch was passiert, wenn der erste Kunde anruft, weil die Bestellung hängt, und Sie keine Ahnung haben, warum? Genau hier trennt sich gut betriebene Software von Systemen, die im Blindflug laufen. Monitoring und Observability sorgen dafür, dass Sie nicht erst von Ihren Nutzern erfahren, dass etwas kaputt ist. In diesem Artikel erkläre ich Ihnen den Unterschied zwischen beiden Konzepten, die drei Säulen Logs, Metrics und Traces, welche Werkzeuge sich lohnen und wie Sie Alarme so gestalten, dass nachts nur das Telefon klingelt, was wirklich klingeln muss.

Warum Monitoring überlebenswichtig ist

Software ist nie wirklich fertig. Sie wird deployt, sie läuft, und dann beginnt der eigentlich kritische Teil: der Betrieb. In dieser Phase entscheidet sich, ob Ihre Anwendung zuverlässig Geld verdient oder ob jeder Ausfall zu Umsatzverlust, frustrierten Kunden und nächtlichen Notfalleinsätzen führt. Wer den Betrieb seiner Software nicht im Blick hat, fliegt im Blindflug.

Die unangenehme Wahrheit lautet: Ohne Monitoring erfahren Sie von Problemen zuletzt. Erst meldet sich ein Kunde, dann der Support, und am Ende stehen Sie unter Druck, ein Problem zu finden, das schon seit Stunden oder Tagen besteht. Mit einem durchdachten Monitoring drehen Sie diese Reihenfolge um. Sie erkennen Auffälligkeiten, bevor sie zu echten Störungen werden, und können reagieren, bevor Ihre Nutzer überhaupt etwas merken.

Es geht aber nicht nur um Ausfälle. Monitoring liefert Ihnen die Datengrundlage für fundierte Entscheidungen. Wächst die Antwortzeit langsam, weil die Datenbank an ihre Grenzen stößt? Lohnt sich eine teure Infrastruktur-Investition oder reicht eine Optimierung? Welche Funktion wird tatsächlich genutzt? All diese Fragen lassen sich nur beantworten, wenn Sie messen, was im Betrieb wirklich passiert.

Monitoring vs. Observability: Wo liegt der Unterschied?

Die beiden Begriffe werden oft synonym verwendet, beschreiben aber unterschiedliche Dinge. Vereinfacht gesagt: Monitoring sagt Ihnen, dass etwas nicht stimmt. Observability hilft Ihnen zu verstehen, warum es nicht stimmt.

Monitoring überwacht bekannte Zustände. Sie definieren vorab, was gemessen werden soll, etwa die CPU-Auslastung, die Fehlerrate oder die Antwortzeit, und schlagen Alarm, wenn ein Schwellwert überschritten wird. Monitoring beantwortet Fragen, die Sie sich schon vorher gestellt haben. Das ist wertvoll, stößt aber an Grenzen, sobald ein Problem auftritt, an das niemand gedacht hat.

Observability geht weiter. Der Begriff stammt ursprünglich aus der Regelungstechnik und beschreibt, wie gut sich der innere Zustand eines Systems aus seinen äußeren Signalen ableiten lässt. Ein gut beobachtbares System sammelt so reichhaltige Daten, dass Sie auch Fragen beantworten können, die Sie sich vorher gar nicht gestellt haben. Genau das brauchen Sie, um die berühmten „unbekannten Unbekannten“ aufzuspüren, also Probleme, deren Existenz Sie nicht einmal vermutet hätten. In komplexen, verteilten Systemen ist das keine Spielerei, sondern eine Notwendigkeit.

In der Praxis ist die Grenze fließend. Observability baut auf Monitoring auf und erweitert es. Sie sollten Monitoring nicht gegen Observability ausspielen, sondern beides als zwei Reifegrade derselben Disziplin verstehen. Wer klein anfängt, beginnt mit klassischem Monitoring und entwickelt sich Schritt für Schritt zu einer echten Observability-Kultur.

Die drei Säulen: Logs, Metrics und Traces

Observability ruht klassisch auf drei Säulen, die jeweils eine andere Perspektive auf Ihr System liefern. Erst im Zusammenspiel ergeben sie ein vollständiges Bild. Wer nur eine davon einsetzt, sieht das System wie durch ein Schlüsselloch.

Logs: Die Chronik der Ereignisse

Logs sind diskrete, zeitgestempelte Aufzeichnungen einzelner Ereignisse. Wenn ein Nutzer sich anmeldet, eine Zahlung fehlschlägt oder eine Ausnahme geworfen wird, landet das im Log. Logs sind die detailreichste Säule und liefern den Kontext, den Sie für die Fehlersuche brauchen. Ihr großer Nachteil: Sie wachsen schnell zu unüberschaubaren Datenmengen an. Deshalb empfehle ich strukturiertes Logging, etwa im JSON-Format, damit sich Logs maschinell durchsuchen und filtern lassen, statt in endlosen Textdateien zu wühlen.

Metrics: Zahlen über die Zeit

Metriken sind numerische Messwerte, die über die Zeit aggregiert werden. Wie viele Anfragen pro Sekunde, wie hoch die durchschnittliche Antwortzeit, wie viel Speicher belegt ist. Metriken sind sparsam im Speicherverbrauch und eignen sich hervorragend für Dashboards und Alarme. Sie zeigen Trends und Anomalien auf einen Blick, geben aber selten Auskunft über die Ursache. Eine Metrik sagt Ihnen, dass die Fehlerrate gestiegen ist, nicht aber, welcher konkrete Request fehlgeschlagen ist.

Traces: Der Weg einer Anfrage

Ein Trace verfolgt eine einzelne Anfrage auf ihrem Weg durch das System. Gerade in verteilten Architekturen, wo ein Klick im Browser über mehrere Dienste, Datenbanken und externe APIs läuft, ist das unverzichtbar. Ein Trace zeigt Ihnen, wo die Zeit tatsächlich verbraucht wurde und an welcher Station es geklemmt hat. Damit füllt die dritte Säule genau die Lücke, die Logs und Metriken offenlassen. Sie erklärt, warum ein bestimmter Request langsam war oder fehlschlug, und nicht nur dass es passiert ist.

Übrigens nennen manche inzwischen eine vierte Säule: das Profiling. Dabei wird der Ressourcenverbrauch bis auf die Ebene einzelner Code-Funktionen aufgeschlüsselt. Für die meisten Projekte sind die drei klassischen Säulen aber völlig ausreichend, um ein robustes Fundament zu legen.

OpenTelemetry: Der neue Standard

Bevor wir zu den konkreten Werkzeugen kommen, lohnt sich ein Blick auf OpenTelemetry, kurz OTel. Dabei handelt es sich um einen offenen Standard für die Erfassung von Logs, Metriken und Traces. OpenTelemetry definiert einheitliche Schnittstellen, SDKs und Datenformate sowie einen sogenannten Collector, der Telemetriedaten empfängt, verarbeitet und an beliebige Backends weiterleitet.

Der entscheidende Vorteil liegt in der Entkopplung. Sie instrumentieren Ihren Code einmal gegen OpenTelemetry und bleiben anschließend frei in der Wahl des Backends. Wenn Sie heute Ihre Daten zu einem selbst gehosteten System schicken und in zwei Jahren zu einem SaaS-Anbieter wechseln möchten, müssen Sie Ihre Anwendung nicht neu instrumentieren. Das schützt Sie wirksam vor Anbieterabhängigkeit. OpenTelemetry hat sich bis 2026 zum zweitaktivsten Projekt der Cloud Native Computing Foundation entwickelt, gleich hinter Kubernetes, und wird von praktisch allen großen Anbietern unterstützt. Wer heute eine Observability-Praxis aufbaut, sollte zuerst mit OpenTelemetry instrumentieren und das Backend danach wählen.

Was sollten Sie messen? RED und USE

Eine der häufigsten Fragen lautet: Was genau soll ich überhaupt überwachen? Hier helfen zwei bewährte Methoden, die verhindern, dass Sie sich in unzähligen Metriken verlieren. Beide sind einfach zu merken und decken zusammen den Großteil dessen ab, was im Betrieb relevant ist.

Die RED-Methode für Services

RED steht für Rate, Errors und Duration, also Anfragerate, Fehlerrate und Antwortzeit. Diese drei Werte eignen sich hervorragend für alles, was Anfragen verarbeitet, etwa Web-Services und APIs. Wie viele Anfragen kommen rein, wie viele davon scheitern und wie lange dauert die Bearbeitung? Mit diesen drei Größen erkennen Sie eine Verschlechterung der Service-Gesundheit nahezu sofort und haben gleichzeitig die idealen Kennzahlen, um daraus später Service-Ziele abzuleiten.

Die USE-Methode für Ressourcen

USE steht für Utilization, Saturation und Errors, also Auslastung, Sättigung und Fehler. Diese Methode richtet den Blick auf die Infrastruktur-Ressourcen wie CPU, Arbeitsspeicher, Festplatte und Netzwerk. Wie stark ist eine Ressource ausgelastet, wie voll ist ihre Warteschlange und treten Fehler auf? Während RED die Perspektive Ihrer Nutzer einnimmt, schaut USE auf die technische Basis darunter. Zusammen ergeben sie ein rundes Bild.

Mein Rat: Fangen Sie nicht mit fünfzig Metriken an. Beginnen Sie mit den RED-Werten für Ihre wichtigsten Services und ergänzen Sie nach Bedarf. Wer von Anfang an alles misst, ertrinkt in Daten und übersieht das Wesentliche.

Health Checks: Lebt der Dienst noch?

Eine der einfachsten und gleichzeitig wirkungsvollsten Maßnahmen sind Health Checks. Das sind kleine Endpunkte in Ihrer Anwendung, die auf Anfrage Auskunft über den eigenen Zustand geben. Ein einfacher Liveness-Check meldet schlicht, dass der Prozess läuft. Ein Readiness-Check geht weiter und prüft, ob die Anwendung auch wirklich arbeitsbereit ist, also etwa eine Verbindung zur Datenbank und zu benötigten externen Diensten hat.

Diese Endpunkte sind die Grundlage für vieles andere. Container-Orchestrierer wie Kubernetes nutzen sie, um kaputte Instanzen automatisch neu zu starten. Load Balancer leiten Traffic nur an gesunde Instanzen weiter. Und ein externer Uptime-Monitor kann Ihre Health Checks regelmäßig abfragen und Alarm schlagen, sobald die Anwendung nicht mehr antwortet. Gerade dieses externe Uptime-Monitoring von außerhalb Ihrer eigenen Infrastruktur ist wichtig, denn wenn Ihr gesamtes Rechenzentrum ausfällt, kann Ihr internes Monitoring Ihnen das schlecht melden.

Tool-Überblick: Self-hosted vs. SaaS

Bei den Werkzeugen stehen Sie vor einer grundlegenden Entscheidung: Wollen Sie alles selbst betreiben oder einen Dienstleister bezahlen, der Ihnen den Betrieb abnimmt? Beide Wege haben ihre Berechtigung, und dank OpenTelemetry sind Sie nicht für immer an Ihre erste Wahl gebunden. Die folgende Tabelle gibt Ihnen einen Überblick über die wichtigsten Vertreter und ihre Einordnung.

Werkzeug	Schwerpunkt	Modell	Einordnung
Prometheus	Metriken	Self-hosted, Open Source	De-facto-Standard für Metriken, riesiges Ökosystem
Grafana	Dashboards, Visualisierung	Self-hosted oder Cloud	Bindet diverse Datenquellen zusammen, sehr flexibel
Loki	Logs	Self-hosted, Open Source	Log-Aggregation, eng mit Grafana verzahnt
ELK / OpenSearch	Logs, Suche	Self-hosted oder Cloud	Mächtige Volltextsuche, ressourcenhungrig
Jaeger / Tempo	Traces	Self-hosted, Open Source	Distributed Tracing, OTel-kompatibel
Sentry	Fehler, Exceptions	SaaS oder Self-hosted	Hervorragend für Error-Tracking im Code
Datadog	Alles in einem	SaaS	Sehr umfangreich, komfortabel, aber kostspielig
SigNoz / OpenObserve	Alles in einem	Self-hosted oder Cloud	Unified-Plattformen, OTel-nativ, junge Alternativen

Der klassische selbst gehostete Stack besteht aus Prometheus für Metriken, Loki für Logs, Tempo oder Jaeger für Traces und Grafana als gemeinsamer Oberfläche. Dieser Aufbau ist günstig und gibt Ihnen volle Kontrolle über Ihre Daten. Ein einfacher Stack aus Prometheus, Grafana und Loki passt sogar auf einen kleinen Server für wenige Euro im Monat. Der Preis dafür ist der Betriebsaufwand: Sie verwalten mehrere zustandsbehaftete Datenbanksysteme, kümmern sich um Skalierung, Backups und Updates.

SaaS-Lösungen wie Datadog nehmen Ihnen diesen Aufwand vollständig ab. Sie zahlen dafür mit höheren laufenden Kosten und einer gewissen Abhängigkeit vom Anbieter. Bei großen Datenmengen können die Rechnungen schnell in den vierstelligen Bereich pro Monat steigen. Interessant sind die neueren Unified-Plattformen wie SigNoz oder OpenObserve, die alle drei Säulen in einem Produkt vereinen und so den Betriebsaufwand eines selbst gehosteten Stacks deutlich reduzieren.

SLO, SLI und SLA verständlich erklärt

Rund um das Thema Zuverlässigkeit kursieren drei Abkürzungen, die gerne verwechselt werden. Dabei bauen sie logisch aufeinander auf und sind das Werkzeug, mit dem Sie Zuverlässigkeit messbar und steuerbar machen.

Ein wichtiges Konzept in diesem Zusammenhang ist das Error Budget, also das Fehlerbudget. Wenn Ihr SLO 99,9 Prozent Verfügbarkeit pro Monat vorsieht, dürfen Sie sich rund 43 Minuten Ausfall pro Monat leisten. Solange Sie innerhalb dieses Budgets bleiben, können Sie neue Funktionen ausliefern und Risiken eingehen. Ist das Budget aufgebraucht, sollten Sie das Tempo drosseln und sich auf Stabilität konzentrieren. Das Fehlerbudget verwandelt eine emotionale Diskussion zwischen Entwicklung und Betrieb in eine sachliche, datengetriebene Entscheidung.

Alerting und On-Call sinnvoll gestalten

Das beste Monitoring nützt nichts, wenn niemand auf die richtigen Signale reagiert. Gleichzeitig ist schlecht gestaltetes Alerting eine der größten Plagen im Betrieb. Wenn jede Kleinigkeit einen Alarm auslöst, stumpfen die Menschen ab. Diese sogenannte Alarmmüdigkeit ist gefährlich, denn irgendwann wird auch der eine wichtige Alarm im Rauschen übersehen. Studien zeigen, dass ein schlechtes Signal-Rausch-Verhältnis die größte Herausforderung bei der schnellen Reaktion auf Störungen ist.

Die wichtigste Regel lautet daher: Ein Alarm, der jemanden mitten in der Nacht weckt, muss eine sofortige menschliche Handlung erfordern. Alles andere gehört nicht in den Pager, sondern bestenfalls in ein Ticket oder ein Dashboard, das man während der Arbeitszeit prüft. Trennen Sie konsequent zwischen „das muss sofort jemand anschauen“ und „das sollte sich jemand bei Gelegenheit ansehen“.

Statt auf rohe technische Schwellwerte zu alarmieren, hat sich das Alerting auf Basis von SLOs durchgesetzt. Besonders bewährt ist die sogenannte Multi-Window-Burn-Rate-Methode. Dabei wird beobachtet, wie schnell das Fehlerbudget aufgebraucht wird, und zwar über mehrere Zeitfenster gleichzeitig, etwa über eine Stunde und über sechs Stunden. Ein kurzer Ausschlag löst dann keinen Fehlalarm aus, während ein echter, anhaltender Vorfall sofort gemeldet wird. So alarmieren Sie auf die tatsächliche Auswirkung für Ihre Nutzer und nicht auf jede vorübergehende Schwankung.

Gute Alarme erkennt man an folgenden Eigenschaften

Wenn Sie eine Rufbereitschaft, also On-Call, organisieren, achten Sie auf Menschlichkeit. Eine faire Rotation, klare Eskalationswege und das Vermeiden von Dauerstress sind keine Nettigkeiten, sondern Voraussetzung dafür, dass Ihr Team langfristig motiviert bleibt. Ein ausgebrannter Bereitschaftsdienst reagiert schlechter, nicht besser.

Observability bei Microservices und Distributed Tracing

Solange Ihre Anwendung ein einzelner Block ist, kommen Sie mit Logs und Metriken weit. Sobald Sie aber auf eine verteilte Architektur mit vielen kleinen Diensten setzen, ändert sich das grundlegend. Eine einzige Nutzeranfrage durchläuft dann womöglich ein Dutzend Services, jeder mit eigener Datenbank und eigenen Logs. Wenn diese Anfrage langsam ist, helfen isolierte Metriken einzelner Dienste kaum weiter, weil sie die Verbindung zwischen den Stationen nicht zeigen.

Genau hier wird Distributed Tracing unverzichtbar. Jede Anfrage erhält beim Eintritt ins System eine eindeutige Trace-ID, die an alle beteiligten Dienste weitergereicht wird. Am Ende können Sie den kompletten Weg der Anfrage nachvollziehen und sehen auf einen Blick, welcher der zwölf Dienste die Verzögerung verursacht hat. Ohne Tracing ist die Fehlersuche in einer Microservice-Landschaft ein mühsames Stochern im Nebel.

Das ist auch ein Grund, warum man den Schritt zu Microservices nicht leichtfertig gehen sollte. Die zusätzliche Komplexität im Betrieb verlangt einen entsprechend höheren Reifegrad bei der Beobachtbarkeit. Wer mehr zu dieser Architekturentscheidung lesen möchte, findet in meinem Artikel über Monolith vs. Microservices eine ausführliche Abwägung. Und wer wissen will, ob seine Architektur den erwarteten Lasten standhält, sollte sich mit Load Testing beschäftigen, das hervorragend mit gutem Monitoring zusammenspielt.

Typische Fehler, die Sie vermeiden sollten

In vielen Projekten begegnen mir immer wieder dieselben Stolpersteine. Wenn Sie diese kennen, ersparen Sie sich viel Frust und Geld.

Meine Praxis-Empfehlung für den Einstieg

Wenn Sie heute mit Observability starten, müssen Sie nicht gleich die volle Komplexität aufbauen. Mein Rat: Gehen Sie schrittweise vor und schaffen Sie zuerst ein solides Fundament, bevor Sie verfeinern.

Beginnen Sie mit einem externen Uptime-Monitoring und einfachen Health Checks. Das kostet wenig und liefert sofort den größten Sicherheitsgewinn. Ergänzen Sie als Nächstes ein Error-Tracking wie Sentry, das Ihnen Ausnahmen im Code mit vollem Kontext meldet. Damit fangen Sie die häufigsten und ärgerlichsten Probleme bereits ab. Im dritten Schritt instrumentieren Sie Ihre Anwendung mit OpenTelemetry und erfassen die RED-Metriken Ihrer wichtigsten Services. Erst wenn das steht, lohnt sich der Einstieg in Distributed Tracing und die Definition von SLOs.

Wichtig ist die Reihenfolge: Erst Sicherheit schaffen, dann Tiefe gewinnen. Ein kleines, gut gepflegtes Monitoring schlägt ein riesiges, das niemand versteht. Und denken Sie daran, dass Observability kein Projekt mit Enddatum ist, sondern eine Praxis, die mit Ihrer Anwendung mitwächst.