Was Flapping-Alerts sind — und warum sie Vertrauen zerstören
Ein Monitor arbeitet in einem einfachen Zustandsmodell: Jeder Check liefert ein Ergebnis, das der Detektor in einen Zustand übersetzt — typischerweise up oder down. Wechselt dieser Zustand, feuert das System eine Benachrichtigung. Beim Flapping wechselt der Zustand nicht ein- oder zweimal, sondern in dichter Folge. Jeder Wechsel kann dabei zwei Meldungen auslösen: eine Problem-Meldung beim Sprung nach down und eine Recovery-Meldung beim Sprung zurück nach up. Zehn Wechsel in zwanzig Minuten ergeben so bis zu zwanzig Meldungen für einen einzigen, noch gar nicht verstandenen Vorfall.
Genau diese Kombinatorik macht Flapping so gefährlich für die Aufmerksamkeit des Teams. Nagios begrenzt sein Flap-Erkennungsfenster deshalb bewusst auf die letzten 21 Prüfergebnisse je Host oder Service — bei 21 gespeicherten Ergebnissen sind höchstens 20 Zustandswechsel möglich (Nagios Core Documentation). Diese Obergrenze ist kein Zufall, sondern die formale Anerkennung des Problems: Ein einzelner Dienst kann in kurzer Zeit erstaunlich viele Wechsel produzieren, und jeder davon konkurriert um die Reaktion eines Menschen. Der überwachte Dienst selbst hat sich in dieser Zeit vielleicht kein einziges Mal wirklich verabschiedet.
Das Google SRE Book warnt ausdrücklich: "When pages occur too frequently, employees second-guess, skim, or even ignore incoming alerts, sometimes even ignoring a 'real' page" (Google SRE Book). Ein Postfach voller Flapping-Meldungen ist damit nicht nur nervig, sondern ein Sicherheitsrisiko: Der eine Alarm, der zählt, verschwindet zwischen neunzehn, die es nicht taten.
Die zwei Ursachen: Grenzwert am Rand und ein zu nervöser Detektor
Flapping hat in aller Regel dieselbe doppelte Wurzel. Die erste Ursache ist ein Grenzwert am Rand: Eine Messgröße pendelt genau um die Schwelle, an der der Detektor umkippt. Die Antwortzeit liegt knapp am definierten Timeout, die CPU-Auslastung kratzt an der Alarmgrenze, ein einzelner Server im Load-Balancer-Pool fällt sporadisch aus dem Rotationszyklus. Die natürliche Streuung solcher Werte reicht dann aus, um den Zustand abwechselnd über und unter die Grenze zu drücken — ohne dass sich am eigentlichen Dienst etwas Grundsätzliches ändert.
Die überwachte Metrik liegt dauerhaft dicht an der Schwelle. Schon Messrauschen, Jitter oder normale Lastschwankungen kippen den Zustand hin und her — ein systematisches Problem der Schwellenwahl, nicht des Dienstes.
Der Detektor entscheidet auf Basis eines einzigen Messwerts. Ein verworfenes Paket, eine langsame Antwort oder ein transienter TCP-Reset genügt für sofortiges down — ohne Glättung, ohne Bestätigung, ohne zweite Meinung.
Die zweite Ursache ist ein zu empfindlicher Detektor: Er erklärt einen Zustand auf Basis eines einzigen Messwerts für gültig. Das Internet ist jedoch ein statistisches Medium. Paketverluste, kurzzeitige Latenzspitzen, ein neu aushandelndes TLS-Handshake oder ein hakeliges Routing zwischen zwei Netzen sind Normalzustand, kein Ausfall. Wer aus jedem einzelnen Aussetzer sofort ein down macht, verwechselt Momentaufnahmen mit Diagnose. Erst das Zusammenspiel beider Ursachen — die Messgröße am Rand plus die Ein-Messwert-Logik — erzeugt den charakteristischen Sturm. Beide lassen sich gezielt entschärfen, und genau das leisten die drei folgenden Gegenmittel.
Was Flapping kostet: Alarm-Müdigkeit und der übersehene Ausfall
Der offensichtliche Schaden ist die Alarm-Müdigkeit. Das SRE Book beschreibt die Belastung nüchtern: "If the employee is at home, a page interrupts their personal time, and perhaps even their sleep" (Google SRE Book). Jede unnötige Unterbrechung kostet Konzentration, Nachtruhe und langfristig die Bereitschaft, Alarme überhaupt ernst zu nehmen. Google leitet daraus einen klaren Anspruch ab: "Every page should be actionable" (Google SRE Book). Eine Flapping-Meldung ist das Gegenteil davon — sie verlangt eine Reaktion, ohne eine sinnvolle Handlung zu ermöglichen, denn bis jemand hinschaut, ist der Zustand oft schon dreimal weitergesprungen.
Der subtilere, teurere Schaden ist der übersehene echte Ausfall. Ein gutes Monitoring beantwortet laut SRE Book zwei Fragen: "what's broken, and why?" (Google SRE Book). Um das zu leisten, empfiehlt Google die Konzentration auf die vier goldenen Signale Latenz, Traffic, Fehler und Sättigung (Google SRE Book) statt auf jede kleine Zustandszuckung. Wo ein Team an Flapping gewöhnt ist, gilt der reflexhafte Griff zum Wegklicken. Und genau dann trifft die nächste Meldung, die keine Zuckung ist, sondern der Beginn eines realen Ausfalls, auf ein abgestumpftes Auge. Das SRE Book bringt die Konsequenz auf den Punkt: "If a page merely merits a robotic response, it shouldn't be a page" (Google SRE Book).
Flapping kostet nicht primär Rechenzeit oder Speicher, sondern Aufmerksamkeit — das knappste Gut im Betrieb. Jede Meldung, die fällt, ohne handlungsfähig zu sein, senkt den Wert aller künftigen Meldungen. Das Ziel ist deshalb nicht mehr Alarme, sondern weniger und dafür verlässliche. Genau darauf zielen die drei Gegenmittel.
Gegenmittel 1: Aufeinanderfolgende Fehlversuche verlangen
Das erste und wirksamste Gegenmittel gegen den nervösen Detektor ist eine simple Regel: Ein Ausfall gilt erst als bestätigt, wenn mehrere aufeinanderfolgende Checks fehlschlagen. Statt beim ersten Aussetzer zu alarmieren, verlangt der Monitor zum Beispiel drei fehlgeschlagene Prüfungen in Folge, bevor er den Zustand auf down setzt. Ein einzelner verlorener Request löst damit keine Meldung mehr aus — genau die transienten Aussetzer, die den Großteil des Rauschens erzeugen, werden herausgefiltert, bevor sie zum Alarm werden.
Nagios gießt diese Idee in eine ausgereifte Formel. Aus den letzten 21 Ergebnissen berechnet die Flap-Erkennung einen prozentualen Zustandswechsel-Wert und vergleicht ihn mit Schwellen (Nagios Core Documentation). Dabei zählen jüngere Wechsel stärker: "The flap detection routines are currently designed to make the newest possible state change carry 50% more weight than the oldest possible state change" (Nagios Core Documentation). Ein Ausfall, der gerade eben begonnen hat, wird also höher gewichtet als einer, der vor zwanzig Checks lag — die Erkennung reagiert auf aktuelle Instabilität, nicht auf längst vergangene.
- Anzahl bewusst wählen: Zwei bis drei aufeinanderfolgende Fehlversuche filtern die meisten Einzelaussetzer heraus, ohne die Erkennung spürbar zu verzögern.
- Erkennungslatenz einkalkulieren: Jeder zusätzlich verlangte Fehlversuch verschiebt den Alarm um ein Prüfintervall nach hinten. Bei einem 60-Sekunden-Intervall bedeuten drei Versuche bis zu drei Minuten Verzögerung — ein bewusster Handel zwischen Ruhe und Reaktionsschnelligkeit.
- Nach Kritikalität staffeln: Ein Zahlungsendpunkt darf weniger Bestätigungen verlangen als eine Marketingseite. Die Anzahl ist ein Regler, kein Dogma.
- Mit Prüfintervall abstimmen: Enge Intervalle erlauben mehr Bestätigungen bei gleicher Latenz; weite Intervalle verlangen Zurückhaltung bei der Anzahl.
Diese Retry-vor-Alarm-Logik ist die Grundlage jeder ruhigen Uptime-Überwachung. Sie kostet ein paar Sekunden Erkennungslatenz und zahlt sie in Form drastisch reduzierter Fehlalarme zurück. Wie Sie darüber hinaus ganze Alarmketten sauber konfigurieren, vertieft der Beitrag zu Monitoring-Alerts und Alarm-Fatigue.
Gegenmittel 2: Aus mehreren Standorten bestätigen
Aufeinanderfolgende Fehlversuche filtern zeitliches Rauschen. Doch ein zweiter, oft unterschätzter Grund für falsches down ist räumlich: Der Monitor sieht die Welt nur durch einen einzigen Netzwerkpfad. Ein Peering-Problem zwischen zwei Providern, eine überlastete Transitstrecke, ein regionaler DNS-Hakler oder eine kurzzeitige Routing-Anomalie lässt die Zielseite von genau diesem einen Standort aus unerreichbar wirken — obwohl sie für den Rest der Welt tadellos läuft. Ein Ein-Standort-Monitor kann nicht unterscheiden zwischen "die Seite ist unten" und "mein Weg zur Seite ist unten".
Die Lösung ist Bestätigung aus mehreren, unabhängigen Standorten. Meldet ein Knoten einen Fehlschlag, wird der Ausfall erst dann als real gewertet, wenn weitere Standorte ihn unabhängig bestätigen. Sieht nur ein einziger von drei Knoten ein Problem, ist das ein starkes Signal für eine lokale Netzwerkstörung — und kein Grund, das gesamte On-Call-Team zu wecken. Erst wenn mehrere Blickwinkel übereinstimmen, wird aus einem Verdacht ein bestätigter Ausfall. Dieses Quorum-Prinzip ist der wirksamste Hebel gegen pfadbedingte Fehlalarme.
Netzwerkstörungen sind häufig einseitig: Sie betreffen eine Route, ein Peering oder einen Resolver, nicht den Dienst selbst. Wer aus einem einzigen Blickwinkel alarmiert, verwechselt regelmäßig die eigene Anbindung mit dem Zustand der Zielseite. Mehrknotige Bestätigung trennt beides sauber.
XICTRAQ setzt genau hier an. Die Erreichbarkeitsprüfungen laufen auf drei unabhängigen Knoten in getrennten Rechenzentren — DE-1, FI und DE-2 — zwei in Deutschland, eines in Finnland. Ein Ausfall wird nur dann zum Alarm, wenn er mehrknotig bestätigt ist. Fällt ein einzelner Standort wegen einer lokalen Routing-Anomalie aus, bleibt das Postfach ruhig, während die Diagnose im Hintergrund festhält, welcher Knoten was gesehen hat. Dieselbe Logik trägt auch komplexere synthetische Browser-Checks, bei denen ein voller Klickpfad statt nur eines HTTP-Codes gemessen wird.
Gegenmittel 3: Hysterese mit getrennten Schwellen
Das dritte Gegenmittel greift die Ursache "Grenzwert am Rand" direkt an. Solange ein einziger Schwellenwert darüber entscheidet, ob ein Zustand up oder down ist, wird jede Metrik, die genau auf dieser Linie pendelt, zwangsläufig flattern. Hysterese löst das, indem sie zwei getrennte Schwellen einführt: eine höhere, ab der ein Ausfall ausgerufen wird, und eine niedrigere, ab der erst wieder Entwarnung gilt. Zwischen beiden liegt ein Totband, in dem sich der Zustand nicht ändert — ein Puffer, der das Zittern verschluckt. Das Prinzip kennt man vom Thermostat: Es heizt nicht bei exakt 21 Grad an und bei 21,0001 Grad wieder aus, sondern arbeitet mit einem bewussten Abstand.
Nagios' eigene Flap-Erkennung ist im Kern eine solche Hysterese. Ein Host oder Service gilt als flappend, "when its percent state change first exceeds a high flapping threshold", und erst als beruhigt, "when its percent state goes below a low flapping threshold" (Nagios Core Documentation). Die Standardwerte machen den Abstand konkret: Die untere Schwelle liegt bei 5 Prozent, die obere bei 20 Prozent Zustandswechsel (Nagios Core Documentation). Zwischen 5 und 20 Prozent passiert bewusst nichts — dieser Korridor ist der Grund, warum ein einmal als stabil erkannter Dienst nicht bei der nächsten kleinen Schwankung sofort wieder als instabil gilt.
| Eigenschaft | Einzelne Schwelle | Hysterese (getrennte Schwellen) |
|---|---|---|
| Auslöse-Logik | Eine Grenze für up und down | Hohe Grenze für Ausfall, niedrige für Erholung |
| Verhalten am Rand | Pendelt bei jeder Schwankung | Totband verschluckt kleine Ausschläge |
| Meldungsaufkommen | Hoch, im Takt des Rauschens | Niedrig, nur bei echtem Übergang |
| Nagios-Standard | nicht vorgesehen | 5 % Erholung / 20 % Ausfall (Nagios Core Documentation) |
| Risiko | Dauerflattern an der Grenze | Minimal spätere, dafür stabile Erholung |
Burn-Rate statt Einzelmesswert: wie die SRE-Praxis Rauschen filtert
Die drei Gegenmittel lassen sich zu einem eleganten Muster verdichten, das die Google-SRE-Praxis als Multi-Window-Multi-Burn-Rate-Alarmierung beschreibt. Statt auf einen einzelnen Messwert reagiert der Alarm auf die Burn-Rate — wie schnell ein Fehlerbudget aufgezehrt wird — und das über zwei Zeitfenster gleichzeitig. Ein langes Fenster erkennt das grundlegende Problem, ein kurzes prüft, ob es jetzt noch andauert. Der Alarm feuert nur, wenn beide Fenster ihre Schwelle überschreiten. Damit vereint das Muster Bestätigung über die Zeit (Gegenmittel 1) mit einer eingebauten Dämpfung (Gegenmittel 3).
Die SRE-Praxis nennt für ein Ziel von 99,9 Prozent konkrete Werte. Ein Page feuert bei einer Burn-Rate von 14,4 über ein 1-Stunden-Fenster, sobald 2 Prozent des 30-Tage-Fehlerbudgets verbraucht sind; eine zweite Stufe bei Burn-Rate 6 über 6 Stunden und 5 Prozent Budget; ein Ticket bei Burn-Rate 1 über 3 Tage und 10 Prozent Budget (Google SRE Workbook). Als Faustregel gilt: "A good guideline is to make the short window 1/12 the duration of the long window" (Google SRE Workbook). Für das 1-Stunden-Fenster bedeutet das ein kurzes Fenster von fünf Minuten.
Der Doppelfenster-Ansatz reduziert Fehlalarme, weil beide Bedingungen zugleich erfüllt sein müssen, und er verbessert die Erholung: Der Alarm hört bereits fünf Minuten nach dem Ende des Problems auf zu feuern statt erst nach einer Stunde (Google SRE Workbook). Eine kurze Spitze, die sich von selbst erledigt, überschreitet die Schwelle im langen Fenster gar nicht erst — das transiente Rauschen fällt heraus, bevor es zur Meldung wird.
Wer sein Alerting an SLOs statt an rohen Einzelwerten ausrichtet, gewinnt Rauschresistenz quasi als Nebeneffekt. Die Mechanik hinter Fehlerbudget und Burn-Rate — inklusive der Frage, wie schnell man ein Budget realistisch verbrennt — behandelt der Beitrag zu Error-Budget und Burn-Rate im SLO-Monitoring im Detail.
Alerts deduplizieren: ein Vorfall, eine Meldung
Selbst mit bestätigten Ausfällen bleibt eine Quelle von Rauschen: Wiederholung. Ein und derselbe Vorfall darf nicht bei jedem Prüfzyklus erneut melden. Deduplizierung fasst zusammengehörende Ereignisse zu einem Vorfall mit einem Lebenszyklus zusammen — offen, wenn der Ausfall bestätigt ist, geschlossen, wenn die Erholung ebenso bestätigt ist. Zwischen diesen beiden Punkten fließt genau eine Meldung, kein Dauerfeuer. Wiederholte Signale desselben Vorfalls werden innerhalb eines Zeitfensters unterdrückt, statt das Postfach zu fluten.
Jeder Vorfall bekommt einen deterministischen Schlüssel aus Ziel und Fehlerart. Wiederholungen desselben Schlüssels innerhalb eines Fensters werden zusammengefasst statt einzeln gemeldet.
Erholt sich ein Dienst nachweislich, schließt der Vorfall automatisch und sendet genau eine Recovery-Meldung — keine Karteileiche, die manuell quittiert werden muss.
Statt zwanzig Einzelmails erhält das Team eine konsolidierte Meldung je Vorfall über den gewählten Kanal — vom Postfach bis zum Chat-Webhook.
Deduplizierung ist besonders bei periodischen Jobs wertvoll, wo ein einzelner hängender Lauf sonst eine Kaskade auslösen würde. Wie man solche Hintergrundprozesse überhaupt sauber überwacht, ohne bei jedem Zyklus zu alarmieren, zeigt der Leitfaden zum Heartbeat-Monitoring für Cron-Jobs. Und weil geplante Wartung eine häufige Flapping-Quelle ist, lohnt der Blick in den Beitrag zu Wartungsfenstern und Fehlalarmen.
So bringt XICTRAQ die drei Gegenmittel zusammen
Die drei Gegenmittel entfalten ihre Wirkung erst im Zusammenspiel, und genau so setzt XICTRAQ sie um. Erreichbarkeitsprüfungen laufen mehrknotig auf drei Standorten (DE-1, FI, DE-2); ein Ausfall wird nur dann zum Alarm, wenn er mehrknotig bestätigt ist — das ist Gegenmittel 2 als Standardverhalten. Aufeinanderfolgende Fehlversuche gaten die Zustandsänderung zeitlich (Gegenmittel 1), und die Vorfalls-Deduplizierung fasst alles zu einem Lebenszyklus zusammen, statt bei jedem Wackler erneut zu melden. So entsteht aus einem potenziellen Zwanzig-Meldungen-Sturm eine einzige, handlungsfähige Benachrichtigung.
Die Faustregel aus dem Betrieb ist einfach: Ein Alarm, der nicht mehrknotig bestätigt und nicht dedupliziert ist, ist ein Alarm zu viel. Wer diese beiden Filter konsequent vorschaltet, halbiert das Meldungsaufkommen, bevor überhaupt über Schwellenwerte gesprochen wird.
— Projekterfahrung
Sichtbar wird das Ergebnis auf der Statuspage und im Reporting: Ein bestätigter Vorfall erscheint als ein Eintrag mit klarem Anfang und Ende, nicht als flatternde Kette. Wer die Preisstufen und den Umfang der Multi-Location-Bestätigung vergleichen möchte, findet die Details in der Preisübersicht. Flüchtige Netzwerkanomalien und ihre Erkennung sind übrigens auch das Thema angrenzender Beiträge zu Post-Quantum-TLS im Monitoring und zur Überwachung verschlüsselter Mailzustellung mit MTA-STS, die zeigen, wie breit das Feld der bestätigungsbedürftigen Signale inzwischen ist.
Dieser Artikel stützt sich auf: Nagios Core Documentation (Detection and Handling of State Flapping — 21-Ergebnis-Fenster, maximal 20 Zustandswechsel, 50 Prozent höhere Gewichtung des jüngsten Wechsels, Standardschwellen 5 Prozent und 20 Prozent, Start-/Stopp-Regel als Hysterese), Google SRE Book (Monitoring Distributed Systems / Effective Alerting — "what's broken, and why?", vier goldene Signale, "every page should be actionable", "good signal and very low noise", Warnung vor dem Ignorieren echter Pages) und Google SRE Workbook (Alerting on SLOs — Multi-Window-Multi-Burn-Rate mit Burn-Rate 14,4 / 2 Prozent im 1-Stunden-Fenster, 6 / 5 Prozent im 6-Stunden-Fenster, 1 / 10 Prozent im 3-Tage-Fenster, kurzes Fenster als 1/12 des langen, Doppelfenster-Bedingung für weniger Fehlalarme und schnellere Erholung).
Häufige Fragen zu Flapping-Alerts
Was ist ein Flapping-Alert genau?
Wie viele aufeinanderfolgende Fehlversuche sollte ich verlangen?
Was bedeutet Hysterese im Monitoring?
Warum reicht ein einzelner Prüfstandort nicht aus?
Hilft Alerting auf Basis von SLOs gegen Flapping?
Wie unterscheidet XICTRAQ echten Ausfall von Rauschen?
Ruhe im Postfach, Vertrauen in jeden Alarm
Flapping ist kein Naturgesetz, sondern das Ergebnis zweier behebbarer Entscheidungen: ein Grenzwert am Rand und ein Detektor, der aus einem einzigen Messwert eine Diagnose macht. Wer aufeinanderfolgende Fehlversuche verlangt, aus mehreren Standorten bestätigt und Hysterese mit getrennten Schwellen einsetzt, dreht das Verhältnis von Signal zu Rauschen um — hin zu weniger, dafür handlungsfähigen Meldungen. Genau darauf zielt ein Monitoring, das mehrknotig bestätigt und dedupliziert, statt bei jedem Wackler zu alarmieren. Das Ergebnis ist ein Postfach, in dem jeder Alarm wieder etwas bedeutet. Wer das an echten Monitoren nachvollziehen möchte, findet in der interaktiven Demo einen ruhigen Alert-Verlauf ohne Login.