Alerts & Hysterese

Alerts feuern, wenn eine Metrik einen Schwellwert verletzt. Damit sie verlässlich und nicht lärmend sind, kennt der Monitor mehrere Mechanismen.

Warnung und kritisch

Jede Regel kann einen Warnungs- und einen Kritisch-Schwellwert haben. So eskaliert ein Alert stufenweise, statt sofort auf „kritisch“ zu springen.

Hysterese – gegen Flattern

Ohne Hysterese löst eine Metrik, die um den Schwellwert pendelt, eine Flut von Auf/Zu-Alerts aus. Zwei Felder verhindern das:

• Resolve-Schwellwert (ResolveThreshold) – der Alert gilt erst als behoben, wenn die Metrik unter diesen (niedrigeren) Wert fällt, nicht schon bei knappem Unterschreiten des Auslöse-Schwellwerts.
• Aufeinanderfolgende gute Messwerte (ResolveConsecutiveSamples) – es braucht mehrere gute Messungen in Folge, bevor aufgelöst wird.

Beispiel: Auslösen bei CPU > 90 %, auflösen erst bei < 70 % und drei guten Messungen in Folge. Ein kurzer Ausreißer auf 91 % und zurück erzeugt so keinen Alert-Sturm.

Silences – Wartungsfenster

Während geplanter Wartung (Backups, Deployments) unterdrücken Silences (Einstellungen → Silences) Alerts für einen Zeitraum, optional pro Server oder Regel.

Severity-Routing

Alerts werden nach Schweregrad an Kanäle geroutet – z. B. Warnungen per E-Mail, kritische zusätzlich an Microsoft Teams oder PagerDuty. Kanäle werden verschlüsselt in der Datenbank konfiguriert (Einstellungen → Benachrichtigungen).

Server-offline-Korrelation

Ist ein Server selbst nicht erreichbar, würden alle abhängigen Metriken gleichzeitig Alarm schlagen. Der Monitor erkennt das und unterdrückt die Folge-Alerts, meldet nur den Server als offline.

Tuning

Die Seite Reports → Alert-Statistik zeigt Auslösehäufigkeit und Fehlalarm-Quote pro Regel – die Grundlage, um Schwellwerte über die Zeit zu schärfen.