Für die meisten Produktivsysteme ist ein solider Ausgangspunkt ein Prüfintervall von 30–60 Sekunden, ein Timeout von etwa dem 2- bis 3-Fachen der normalen Round-Trip-Time, ein Alarm nach 2–3 aufeinanderfolgenden Fehlschlägen und eine Bestätigung durch mindestens zwei Monitoring-Standorte. Setzen Sie Latenz-Warnungen beim 1,5- bis 2-Fachen Ihrer gemessenen Baseline und kritische Alarme beim 3-Fachen, und alarmieren Sie bei Paketverlust ab etwa 2 % (Warnung) und 10 % (kritisch). Passen Sie die Werte anschließend je Host-Typ an.
Die Erkennungszeit ergibt sich aus drei Einstellungen
Die Zeit bis zur Erkennung eines Ausfalls entspricht grob dem Intervall multipliziert mit der Anzahl erforderlicher aufeinanderfolgender Fehler, plus Timeout. Bei einem 30-Sekunden-Intervall und drei erforderlichen Fehlschlägen erfahren Sie von einem harten Ausfall nach etwa 90 Sekunden. Ein halbiertes Intervall halbiert diesen Wert, gibt kurzen Aussetzern aber auch mehr Gelegenheiten, Alarme auszulösen.
Praxistaugliche Standardwerte:
- Intervall: 30 Sekunden für kritische Infrastruktur, 60 Sekunden für Standardserver, 2–5 Minuten für Geräte mit niedriger Priorität oder begrenzter Bandbreite.
- Timeout: das 2- bis 3-Fache der p95-Round-Trip-Time, mindestens jedoch etwa 1 Sekunde.
- Aufeinanderfolgende Fehler: 2 für kritische Hosts, 3 für die meisten anderen. Ein einzelner verlorener Ping ist selten ein Incident.
Setzen Sie auf ein Quorum mehrerer Standorte
Ein Fehler, der nur von einem Standort aus sichtbar ist, deutet oft auf ein Problem in der Nähe der Messstation hin, nicht beim Ziel. Die Übereinstimmung mehrerer Standorte zu verlangen, ist der wirksamste verfügbare Filter gegen Fehlalarme. Eine gängige Regel lautet „down, wenn mindestens 2 von 3 Standorten fehlschlagen“, bzw. eine Mehrheit, wenn Sie fünf oder mehr betreiben. Eine einzelne ausfallende Region kann trotzdem einen Alarm niedrigerer Priorität auslösen, der auf Routing- oder Peering-Probleme hinweist.
Latenz-Schwellenwerte relativ zur Baseline festlegen
Feste Millisekundenwerte passen selten zu jedem Host. Messen Sie eine Baseline über mindestens eine Woche, mit p50 für das typische Verhalten und p95 für die normale Streuung, und alarmieren Sie dann bei Abweichungen:
- Warnung: anhaltende Latenz beim 1,5- bis 2-Fachen der Baseline über mehrere aufeinanderfolgende Checks.
- Kritisch: 3-Fache der Baseline oder eine absolute Obergrenze, ab der Ihre Anwendung nicht mehr funktioniert, etwa 250 ms für ein interaktives API-Backend.
Kombinieren Sie beides: Ein relativer Schwellenwert erkennt, wenn ein 5-ms-LAN-Link auf 20 ms springt, während eine absolute Obergrenze die Nutzer schützt, auch wenn die Baseline selbst nach oben driftet.
Paketverlust und Jitter
Paketverlust ist oft das früheste Anzeichen für einen defekten Link oder ein überlastetes Interface. Bewerten Sie ihn über ein gleitendes Fenster, etwa die letzten 10–20 Pings, statt pro Check. Typische Ausgangswerte sind über 2 % für eine Warnung und über 10 % für kritisch; auf LAN-Strecken verdient jeder anhaltende Verlust eine Untersuchung.
Jitter, also die Schwankung zwischen aufeinanderfolgenden Round-Trip-Times, ist vor allem für Voice, Video und Echtzeit-APIs relevant. Rund 30 ms sind für solche Workloads eine gängige Warnschwelle. Bei Web- oder Batch-Traffic sollten Sie Jitter eher als Diagnosesignal denn als Alarmauslöser behandeln.
Startwerte nach Host-Typ
| Host-Typ | Intervall | Timeout | Fehler | Latenz Warnung / kritisch | Verlust Warnung / kritisch |
|---|---|---|---|---|---|
| LAN-Server | 30s | 1s | 2 | 2x / 3x Baseline (z. B. 5 / 10 ms) | >0,5 % / >2 % |
| Cloud-VM, gleiche Region | 30s | 1s | 2–3 | 2x / 3x Baseline (z. B. 20 / 40 ms) | >1 % / >5 % |
| Interkontinental | 60s | 3s | 3 | 1,5x / 2x Baseline oder 300 ms absolut | >2 % / >10 % |
| Edge- / IoT-Gerät | 2–5 min | 5s | 3–5 | 2x / 3x Baseline | >5 % / >15 % |
Ersetzen Sie die Beispielwerte innerhalb der ersten Wochen durch Ihre eigenen Baselines.
Feinabstimmung gegen Fehlalarme
- Prüfen Sie zwei Wochen lang jeden Alarm. Ordnen Sie ihn als echt, vorübergehend oder messstationsseitig ein.
- Erhöhen Sie die Fehleranzahl, bevor Sie das Intervall verlängern, um einzelne verlorene Pings herauszufiltern.
- Ergänzen Sie ICMP um einen TCP-Check. Manche Netzwerke drosseln oder priorisieren ICMP herab; ein TCP-Check auf einem bekannten Port bestätigt, ob der Dienst tatsächlich erreichbar ist.
- Berechnen Sie Baselines nach Infrastrukturänderungen neu, etwa nach Regionswechseln oder neuen Firewalls.
- Leiten Sie Warnungen und kritische Alarme getrennt weiter. Senden Sie Warnungen an einen Slack- oder Microsoft-Teams-Kanal und kritische Zustände per E-Mail, Telegram oder Webhook.
UpScanX Ping-Monitoring führt ICMP-, TCP- und UDP-Checks von über 15 globalen Standorten aus, was Quorum-Regeln einfach macht, und die KI-Berichte machen schleichende Latenzanomalien sichtbar. Weitere Hinweise zur Einrichtung finden Sie in unseren Best Practices für Ping-Monitoring.
Wichtigste Erkenntnisse
- Die Erkennungszeit entspricht grob Intervall mal Fehleranzahl plus Timeout; stimmen Sie alle drei gemeinsam ab.
- Verlangen Sie ein Quorum mehrerer Standorte, bevor ein Host als down gilt.
- Alarmieren Sie bei Latenz relativ zur Baseline, abgesichert durch eine absolute Obergrenze.
- Nutzen Sie gleitende Fenster für Paketverlust und reservieren Sie Jitter-Alarme für Echtzeit-Traffic.
- Überprüfen Sie die Schwellenwerte nach den ersten zwei Wochen und nach jeder Netzwerkänderung.