Monitoring bedeutet, laufend Signale aus einem System zu sammeln und daraus eine einzige Frage zu beantworten: Funktioniert es gerade — und merke ich es, wenn es aufhört? Dieser Leitfaden erklärt, was Monitoring eigentlich ist, welche Signale zählen, wie man alarmiert, ohne das Team zu überfluten, und wo fast jedes Setup einen blinden Fleck hat: bei der Arbeit, die im Hintergrund läuft.
Im Softwarebetrieb bedeutet Monitoring, Daten über ein laufendes System zu sammeln — Messwerte, Ereignisse, Logs —, sie mit Erwartungen abzugleichen und einen Menschen zu benachrichtigen, wenn Realität und Erwartung auseinanderlaufen. Ziel ist nicht, möglichst viele Daten zu sammeln. Ziel ist, zwei Zeitspannen zu verkürzen:
Der schlimmste Fall ist ein Problem, das ein Kunde vor Ihnen bemerkt. Jede Entscheidung in diesem Leitfaden lässt sich daran messen: Macht sie es unwahrscheinlicher, dass die erste Meldung von aussen kommt?
Die beiden Begriffe werden oft synonym verwendet, meinen aber Verschiedenes. Monitoring beantwortet Fragen, die man vorher kannte: Liegt die Fehlerrate über 2 %? Ist der nächtliche Import gelaufen? Observability ist eine Eigenschaft eines Systems — wie gut man Fragen beantworten kann, die man nicht vorhergesehen hat, indem man seine Telemetrie im Nachhinein untersucht.
Man braucht beides. Observability ohne Monitoring heisst: Man kann hervorragend analysieren, aber erst, wenn einem jemand sagt, dass es etwas zu analysieren gibt. Monitoring ohne Observability heisst: Der Alarm geht los, und man findet nicht heraus, warum. In der Praxis bringen einige gut gewählte Monitore kleinen und mittleren Teams meist mehr als eine teure Observability-Plattform, für die niemand Zeit hat.
Fast alles, was ein Monitoring-System verarbeitet, gehört in eine von vier Kategorien:
Zahlen, die über die Zeit gemessen werden: Anfragen pro Sekunde, CPU-Auslastung, Queue-Länge, Fehleranzahl. Metriken sind günstig zu speichern und schnell abzufragen — das Rückgrat von Dashboards und Schwellwert-Alerts. Ihre Schwäche ist der Kontext: Eine Metrik zeigt, dass sich die Fehlerrate verdoppelt hat, nicht welcher Kunde oder welcher Codepfad betroffen ist.
Zeitgestempelte Einträge über einzelne Vorgänge, idealerweise strukturiert (JSON mit benannten Feldern) statt Freitext. Logs liefern die Details, die Metriken fehlen, werden bei grossem Volumen aber teuer und unübersichtlich. Sie sind der Ort, an den man nach einem Alert geht — nicht der Alert selbst.
Ein Trace verfolgt eine einzelne Anfrage über Dienste, Queues und Datenbanken hinweg und hält fest, wie lange jeder Schritt gedauert hat. In verteilten Systemen ist das der schnellste Weg zur Antwort auf „wo ist die Zeit geblieben?". OpenTelemetry ist dafür zum Standard geworden.
Die oft vergessene vierte Kategorie: einzelne fachliche oder technische Ereignisse wie Deploy abgeschlossen, Job eingereiht, Job fehlgeschlagen, Zahlung verbucht. Erst sie machen das Überwachen von Abläufen möglich — dass ein Job hängt, sieht man nicht an der CPU, wohl aber daran, dass er vor zwanzig Minuten eingereiht und nie gestartet wurde.
Ein hilfreiches Denkmodell: ein System von unten nach oben und von aussen nach innen überwachen.
Sie brauchen nicht alle sechs ab dem ersten Tag. Aber Sie sollten wissen, welche Sie nicht abdecken — und wie ein Ausfall in dieser Schicht von aussen aussehen würde.
Drei Modelle helfen bei der Entscheidung, welche Metriken zählen — damit am Ende nicht 400 Dashboards existieren und niemand weiss, welches man ansehen soll.
| Modell | Signale | Geeignet für |
|---|---|---|
| Vier Golden Signals (Google SRE) | Latenz, Traffic, Fehler, Sättigung | Jeden nutzerseitigen Dienst |
| RED | Rate, Errors, Duration | Anfragebasierte Dienste und APIs |
| USE | Utilization, Saturation, Errors | Ressourcen: CPU, Speicher, Festplatten, Pools, Queues |
Die Modelle überschneiden sich bewusst. RED beschreibt die Arbeit, die ein Dienst erledigt, USE die Ressourcen, mit denen er sie erledigt. Ein langsamer Endpunkt (RED: Duration) zusammen mit einem ausgelasteten Connection-Pool (USE: Saturation) ist eine Diagnose; jedes Signal für sich allein ist nur ein Symptom.
Ein Detail zählt mehr als jedes Modell: Messen Sie Latenz als Perzentil, nicht als Durchschnitt. Ein Mittelwert von 200 ms kann verbergen, dass jede zwanzigste Anfrage acht Sekunden dauert. Das p95 oder p99 ist das, was Ihre unzufriedensten Nutzer erleben.
Die meisten Monitoring-Setups reagieren auf etwas, das passiert: einen Fehler, einen Ausschlag, einen Timeout. Am schwersten zu erkennen sind Ausfälle, bei denen nichts passiert:
Keiner dieser Fälle erzeugt einen Fehler, also löst auch kein fehlerbasierter Alert aus. Die Technik dafür heisst Heartbeat-Monitoring, auch Dead Man's Switch: Der Prozess sendet in regelmässigen Abständen ein kleines „Ich lebe noch"-Signal, und das Monitoring schlägt Alarm, wenn es innerhalb eines erwarteten Zeitfensters ausbleibt. Die Logik kehrt sich um — Stille wird zum Alarm.
Zwei Regeln machen Heartbeats verlässlich: Setzen Sie den Timeout auf ein Mehrfaches des Intervalls (ein 30-Sekunden-Heartbeat mit 90 Sekunden Timeout verkraftet ein verlorenes Paket, ohne jemanden zu wecken), und bewerten Sie pro Dienst, nicht pro Host. In Container-Umgebungen ersetzt jeder Deploy die Hosts; gilt jeder alte Pod als „tot", sieht jedes Release wie ein Ausfall aus.
Ein Alert ist eine Bitte um die Aufmerksamkeit eines Menschen. Jeder Alert, der sich als irrelevant herausstellt, macht es etwas unwahrscheinlicher, dass der nächste gelesen wird — das ist Alert Fatigue, und sie ist der häufigste Grund, warum Monitoring in der Praxis scheitert, obwohl die Daten da waren. Einige Regeln halten Alerts vertrauenswürdig:
Wer Ziele formal festlegt, landet bei SLOs (Service Level Objectives): Man definiert, was „gut genug" heisst — etwa 99,5 % der nächtlichen Jobs laufen beim ersten Versuch durch — und alarmiert, wenn das erlaubte Fehlerbudget zu schnell aufgebraucht wird, statt bei jedem einzelnen Fehler.
Aufbewahrung ist ein Abwägen zwischen Kosten und den Fragen, die man noch beantworten kann. Als grobe Orientierung:
Achten Sie darauf, wo die Aufbewahrung für Sie entschieden wird. Viele Tools behalten standardmässig nur ein kurzes, festes Fenster — Hangfires eingebauter Speicher etwa lässt erfolgreiche Jobs nach rund einem Tag verfallen (Details hier). Und denken Sie an den Datenschutz: Monitoring-Daten enthalten oft personenbezogene Daten in Exception-Messages oder Payloads — Aufbewahrung sollte deshalb mit echtem Löschen enden, nicht nur mit dem Ausblenden alter Daten.
Die meisten Monitoring-Stacks wachsen aus dem Request-Pfad heraus: Uptime-Checks, APM, Error-Tracker, die sich ins Web-Framework einklinken. Sie sehen eine Anfrage hereinkommen und eine Antwort hinausgehen. Was sie nicht sehen, ist die Arbeit ausserhalb jeder Anfrage — und in vielen Anwendungen lebt genau dort die Logik, mit der tatsächlich Geld verdient wird: Rechnungsläufe, Datenimporte, Berichte, E-Mail-Kampagnen, Synchronisation mit ERP- und Partnersystemen.
Background-Jobs haben drei Eigenschaften, die sie für request-zentrierte Tools schwer überwachbar machen:
Sinnvolles Monitoring für Background-Jobs heisst: jeder Zustandswechsel (eingereiht, in Bearbeitung, erfolgreich, fehlgeschlagen) ausserhalb der Anwendung festgehalten, damit er Neustarts übersteht; eine Fehlerraten-Regel pro Anwendung oder Job-Typ; eine Heartbeat-Regel pro Anwendung, die auslöst, wenn alle ihre Worker verstummen; und eine Historie, die lang genug ist, um „seit wann schlägt das fehl?" zu beantworten. Für .NET-Teams mit Hangfire macht QueueHawk genau das — wie es sich einklinkt, steht unter Hangfire-Monitoring, und diese zwei Alert-Regeln decken die meisten Ausfälle ab.
Damit finden Sie Lücken in einem bestehenden Setup. Jedes „Nein" ist ein Ausfall, von dem Sie heute zuerst durch einen Kunden erfahren würden.
Ein Begriff unklar? Das Monitoring-Glossar erklärt alle an einem Ort. Und wer Jobs mit Cron-Ausdrücken plant, sieht im kostenlosen Cron-Ausdruck-Explainer, wann sie genau laufen.
Monitoring beantwortet Fragen, die man vorher kannte: Liegt die Fehlerrate über 2 %? Ist der nächtliche Job gelaufen? Observability ist die Fähigkeit, auch unvorhergesehene Fragen zu beantworten, indem man reichhaltige Telemetrie wie Traces und strukturierte Logs untersucht. Monitoring baut auf beobachtbaren Systemen auf — man braucht beides.
Latenz, Traffic, Fehler und Sättigung. Sie stammen aus dem Site-Reliability-Engineering-Buch von Google und beschreiben den Zustand jedes nutzerseitigen Dienstes von aussen: wie lange Anfragen dauern, wie viele es sind, wie viele fehlschlagen und wie nahe der Dienst an seiner Kapazitätsgrenze ist.
Beim Heartbeat-Monitoring (auch Dead Man's Switch genannt) meldet sich ein Prozess regelmässig. Bleibt das erwartete Signal innerhalb eines Zeitfensters aus, wird ein Alarm ausgelöst. Nur so lässt sich zuverlässig erkennen, was lautlos ausfällt — ein Cronjob, der nie gestartet ist, ein abgestürzter Worker, ein verschwundener Server.
Das hängt von der Frage ab, die man beantworten will. Minuten bis Tage reichen fürs Alerting, Wochen für Incident-Analysen und Vergleiche vor/nach einem Deploy, Monate bis ein Jahr für Kapazitätsplanung, saisonale Muster und Reporting gegenüber Kunden.
Ja. Uptime-Checks und Request-Metriken sehen nur den synchronen Teil einer Anwendung. Background-Jobs laufen ausserhalb jeder Anfrage, oft nachts, und ihr häufigster Ausfall ist kein Fehler, sondern Stille — ein Job, der einfach nicht mehr läuft. Dafür braucht es Job-Historie, Fehlerraten-Alerts und Heartbeat-Prüfungen.
Historie, Fehlerraten- und Heartbeat-Alerts für Hangfire. Kostenlos für eine Application, keine Kreditkarte nötig.