Alert-Hygiene für das Host-Monitoring: Änderungsrate statt Schwellwert, fehlgeschlagene Units und Zeitfenster

Worum es geht

Das SRE-Buch von Google hält fest, dass "paging a human is a quite expensive use of an employee's time" (einen Menschen per Pager zu alarmieren, ist eine ziemlich teure Nutzung der Arbeitszeit) und dass wirksames Alerting "good signal and very low noise" (gutes Signal und sehr wenig Rauschen) braucht: Jeder Alarm, der sich als nicht handlungsrelevant herausstellt, bringt den Bereitschaftsdienst dazu, Alarmen weniger zu vertrauen. Das SRE-Workbook beschreibt im Kapitel zum Alerting auf SLOs die Multiwindow-Alarmierung. Sie löst nur aus, wenn die Burn Rate sowohl über ein langes Fenster (ein kurzer Ausschlag alarmiert nicht) als auch über ein kurzes Fenster (der Alarm klingt nach der Erholung rasch ab) hoch ist.

Auf einen einzelnen Host statt auf das SLO eines Dienstes angewendet, beantworten dieselben zwei Ideen, welche der an anderer Stelle in dieser Serie behandelten Signale auf den Pager gehören und welche in die Ticket-Warteschlange:

• Speicherplatz: Ein fester Prozentwert (etwa "Alarm bei 90 % Füllstand") alarmiert gleich, ob die Partition seit sechs Monaten unverändert bei 91 % steht oder in der letzten Stunde von 60 % auf 91 % gewachsen ist. Das Signal, das einen bevorstehenden Ausfall tatsächlich vorhersagt, ist die Füllrate, also die prognostizierte Zeit bis zur vollen Platte bei der aktuellen Wachstumsgeschwindigkeit. Ein langsamer, stabiler Stand von 91 % ist ein Ticket; eine Partition, die voraussichtlich innerhalb einer Stunde voll ist, ist ein Alarm.
• Fehlgeschlagene systemd-Units / gestoppte Windows-Dienste: Eine Unit, die jetzt im Zustand failed ist und laufen sollte, entspricht weitgehend dem Fall "bereits ausgefallen", den das SRE-Buch als alarmwürdig einstuft. Eine Unit, die einmal fehlgeschlagen ist und von ihrer eigenen Retry-Logik schon neu gestartet wurde, ist ein Ticket, kein Alarm.
• Zeitsynchronisation: Ein Host, dessen Uhr so weit abgedriftet ist, dass die TLS-Validierung oder die Log-Korrelation versagt, ist alarmwürdig. Ein kurzzeitiger Timeout bei der NTP-Abfrage, der sich bei der nächsten Abfrage von selbst erledigt, ist es nicht.
• SMART-/NVMe-Gesundheit: Ein fehlgeschlagener Selbsttest oder ein von null verschiedenes Critical-Warning-Byte ist angesichts des kurzen Zeitfensters bis zum Datenverlust alarmwürdig. Ein einzelner neu zugewiesener Sektor (reallocated sector) auf einem sonst gesunden Laufwerk ist ein Ticket zur Beobachtung.

Warum es wichtig ist

Wer auf den rohen Momentanwert einer Metrik alarmiert, ohne Anforderung an Dauer oder Trend, erzeugt genau das Flapping und Rauschen, vor dem das SRE-Buch warnt: Ein Schwellwert, der nahe an seiner Grenze schwankt, löst wiederholt aus und klingt wieder ab. Die daraus folgende Alert Fatigue ist dasselbe Fehlerbild, egal ob die Metrik ein Disk-Prozentwert oder eine HTTP-Fehlerrate ist.

So wird es angewendet

• Bei jedem Host-Alarm prüfen, ob die Regel auf eine Änderungsrate bzw. einen Trend oder auf einen rohen Pegel reagiert und ob sie verlangt, dass die Bedingung über ein Zeitfenster anhält statt nur in einer einzelnen Stichprobe aufzutreten.
• Bedingungen der Art "bereits ausgefallen, sofortiges Handeln nötig" (Platte läuft innerhalb des Bereitschaftsfensters voll, eine erforderliche Unit ausgefallen, Uhr nicht synchron) an einen Pager leiten; Bedingungen der Art "bald prüfenswert" (langsam, stabil oder bereits erholt) an ein Ticket oder Dashboard.
• Jeden Alarm neu bewerten, der mehr als eine Handvoll Mal ausgelöst hat, ohne dass ein entsprechender echter Fix erfolgte. Die Bigtable-Fallstudie im SRE-Buch beschreibt, wie E-Mail-Alarme deaktiviert wurden, die zu zahlreich geworden waren, um sie noch zu diagnostizieren.

Stolpersteine

• Einen prozentbasierten Disk-Schwellwert von einem Host auf einen anderen mit stark abweichender Wachstumsrate übernehmen, obwohl dieselbe Zahl dort eine andere verbleibende Reichweite bedeutet.
• Alarm und Ticket als denselben Schweregrad mit unterschiedlichen Zustellkanälen behandeln, statt als unterschiedliche Dringlichkeitsklassen.