Begriffe zu Alerting, Observability und Zuverlässigkeit — verständlich erklärt.
Monitoring, Alerting und Observability bringen viel Fachvokabular mit. Dieses Glossar erklärt die Begriffe, denen Sie am häufigsten begegnen — kurz, verständlich und mit einem Hinweis, wo sie in der Praxis zählen. Den Gesamtzusammenhang liefert Was ist Monitoring?
Alert
Eine Benachrichtigung, die einen Menschen bittet, sich etwas anzusehen — ausgelöst, wenn eine überwachte Bedingung eintritt, etwa eine Fehlerrate über einem Schwellwert. Ein guter Alert nennt das betroffene System, sagt, was falsch ist, und verlinkt die Details. Siehe Alerts, die niemand ignoriert.
Alert Fatigue (Alarmmüdigkeit)
Der Zustand, in dem ein Team so viele irrelevante oder doppelte Alerts erhält, dass es sie ignoriert — auch die wichtigen. Dagegen hilft: auf Symptome alarmieren, Zeitfenster verwenden, mit Cooldown deduplizieren und Alerts löschen, die nie zu einer Handlung führen. Siehe Alert Fatigue reduzieren.
APM (Application Performance Monitoring)
Überwachung einer Anwendung von innen: Antwortzeiten, Durchsatz, Fehlerraten und langsame Datenbankaufrufe, meist pro Endpunkt und oft mit Traces. APM-Tools sind request-zentriert und sehen typischerweise wenig von dem, was in Background-Jobs passiert.
Aufbewahrung (Retention)
Wie lange Monitoring-Daten gespeichert werden, bevor sie gelöscht werden. Kurze Aufbewahrung spart Kosten; lange erlaubt Fragen wie „seit wann?" und Vergleiche über Monate oder Saisons.
Background-Job
Arbeit, die ausserhalb einer Nutzeranfrage läuft — geplante Aufgaben, Queue-Consumer, Importe, E-Mail-Versand. In .NET ist Hangfire dafür das verbreitetste Framework — siehe Hangfire vs. Quartz.NET vs. TickerQ. Background-Jobs scheitern leise und brauchen ein eigenes Monitoring.
Black-Box-Monitoring
Prüfung eines Systems von aussen, so wie ein Nutzer es sieht, ohne Kenntnis seines Inneren — etwa ein HTTP-Check gegen die Login-Seite. Das Gegenstück ist White-Box-Monitoring.
Cooldown
Die Mindestzeit zwischen zwei Benachrichtigungen zum selben andauernden Problem. Ein Cooldown von 30 Minuten macht aus einem zweistündigen Ausfall eine Handvoll Nachrichten statt Hunderte.
Cron-Ausdruck
Eine kompakte Zeichenkette wie 0 3 * * 1-5, die einen wiederkehrenden Zeitplan beschreibt (Minute, Stunde, Tag im Monat, Monat, Wochentag). Im Cron-Ausdruck-Explainer sehen Sie, wann ein Ausdruck auslöst.
Dead Man's Switch
Anderer Name für Heartbeat-Monitoring: ein Alarm, der auslöst, wenn ein erwartetes Signal ausbleibt — nicht, wenn etwas Schlimmes passiert.
Fehlerrate
Anzahl oder Anteil fehlgeschlagener Vorgänge innerhalb eines Zeitfensters, etwa „5 fehlgeschlagene Jobs in 10 Minuten". Fehler über ein Zeitfenster auszuwerten ist weit ruhiger als bei jeder einzelnen Exception zu alarmieren.
Heartbeat
Eine kleine, regelmässige „Ich lebe noch"-Meldung eines Prozesses an ein Monitoring-System. Bleiben Heartbeats innerhalb eines Timeouts aus, gilt der Prozess als ausgefallen — der einzig verlässliche Weg, Ausfälle zu erkennen, die gar keinen Fehler erzeugen. Den passenden Timeout liefert der Heartbeat-Timeout-Rechner.
Incident (Vorfall)
Eine ungeplante Unterbrechung oder Verschlechterung eines Dienstes, die eine Reaktion erfordert. Monitoring soll Incidents früh erkennen; Post-Mortems sollen verhindern, dass sie sich wiederholen.
Latenz und Perzentile (p95, p99)
Latenz ist die Dauer eines Vorgangs. Weil Durchschnitte langsame Ausreisser verbergen, misst man Perzentile: Ein p95 von 800 ms heisst, 95 % der Anfragen sind schneller als 800 ms, 5 % langsamer.
Logs
Zeitgestempelte Einträge zu einzelnen Ereignissen. Strukturierte Logs (Schlüssel-Wert oder JSON) lassen sich durchsuchen und filtern, Freitext-Logs kaum. In Logs untersucht man nach einem Alert.
Metriken
Numerische Messwerte über die Zeit, etwa CPU-Auslastung oder Anfragen pro Sekunde. Günstig zu speichern und abzufragen — die Grundlage von Dashboards und Schwellwert-Alerts.
MTTD / MTTR
Mean Time to Detect und Mean Time to Resolve (bzw. Recover): wie lange ein Problem unbemerkt bleibt und wie lange die Behebung dauert, sobald es bemerkt ist. Genau diese beiden Werte soll Monitoring senken.
Observability
Eine Eigenschaft eines Systems: wie gut sich sein innerer Zustand aus der ausgesendeten Telemetrie verstehen lässt. Monitoring beantwortet bekannte Fragen, Observability ermöglicht neue.
OpenTelemetry
Ein offener, herstellerneutraler Standard samt SDKs zum Erzeugen von Traces, Metriken und Logs. Einmal instrumentieren, an jedes kompatible Backend senden.
Queue-Rückstau
Arbeit, die eingereiht, aber nicht abgearbeitet wird — weil Worker ausgefallen, ausgelastet oder auf der falschen Queue sind. Siehe Jobs, die in Enqueued hängen.
RED-Methode
Rate, Errors, Duration: drei Metriken, die jeden anfragebasierten Dienst beschreiben.
Retry (Wiederholung)
Das automatische erneute Ausführen eines fehlgeschlagenen Vorgangs. Retries verbergen vorübergehende Fehler — gut für Nutzer, gefährlich fürs Monitoring, wenn die fehlgeschlagenen Versuche nie festgehalten werden.
SLI, SLO und SLA
Ein Service Level Indicator (SLI) ist eine Messgrösse, etwa der Anteil erfolgreicher Jobs. Ein Service Level Objective (SLO) ist das Ziel dafür, etwa 99,5 %. Ein Service Level Agreement (SLA) ist ein vertragliches Versprechen gegenüber Kunden, meist lockerer als das interne SLO.
Synthetisches Monitoring
Skriptgesteuerte Prüfungen, die in regelmässigen Abständen Nutzeraktionen gegen ein Live-System simulieren — vom einfachen Uptime-Ping bis zum kompletten Login-und-Checkout-Ablauf.
Traces
Die Aufzeichnung des Wegs einer Anfrage durch mehrere Dienste, mit der Dauer jedes Schritts (Span). Traces beantworten „wo ist die Zeit geblieben?" in verteilten Systemen.
Uptime-Monitoring
Regelmässige Prüfung, ob ein Dienst antwortet, meist von mehreren externen Standorten aus. Die einfachste Form von Black-Box-Monitoring.
USE-Methode
Utilization, Saturation, Errors: eine Checkliste für jede Ressource (CPU, Speicher, Festplatten, Connection-Pools, Queues), um Engpässe zu finden.
Vier Golden Signals
Latenz, Traffic, Fehler und Sättigung — die vier Messgrössen, die das SRE-Buch von Google für jeden nutzerseitigen Dienst empfiehlt.
White-Box-Monitoring
Monitoring auf Basis interner Daten, die ein System über sich selbst bereitstellt — Metriken, Logs, Traces, Zustandswechsel. Es sieht Ursachen, die Black-Box-Checks nicht sehen, aber nur von innen.
