Pour la plupart des hôtes de production, un bon point de départ consiste à utiliser un intervalle de vérification de 30 à 60 secondes, un timeout d'environ 2 à 3 fois le temps aller-retour normal, une alerte après 2 à 3 échecs consécutifs et une confirmation depuis au moins deux sites de monitoring. Placez les avertissements de latence à 1,5 à 2 fois votre référence mesurée et les alertes critiques à 3 fois, et alertez sur une perte de paquets supérieure à environ 2 % (avertissement) et 10 % (critique). Ajustez ensuite selon le type d'hôte.
La vitesse de détection dépend de trois paramètres
Le délai de détection d'une panne correspond grosso modo à l'intervalle multiplié par le nombre d'échecs consécutifs requis, plus le timeout. Avec un intervalle de 30 secondes et trois échecs requis, vous êtes averti d'une panne franche en 90 secondes environ. Diviser l'intervalle par deux divise ce délai d'autant, mais donne aussi davantage d'occasions aux micro-coupures de déclencher une alerte.
Valeurs par défaut pragmatiques :
- Intervalle : 30 secondes pour l'infrastructure critique, 60 secondes pour les serveurs standards, 2 à 5 minutes pour les équipements peu prioritaires ou à bande passante limitée.
- Timeout : 2 à 3 fois le temps aller-retour p95, avec un minimum d'environ 1 seconde.
- Échecs consécutifs : 2 pour les hôtes critiques, 3 pour la plupart des autres. Une seule sonde perdue constitue rarement un incident.
Utilisez un quorum multi-sites
Un échec observé depuis un seul point de mesure reflète souvent un problème proche de la sonde, et non de la cible. Exiger l'accord de plusieurs sites est le filtre le plus efficace contre les faux positifs. Une règle courante est « hors service lorsqu'au moins 2 sites sur 3 échouent », ou la majorité lorsque vous en utilisez cinq ou plus. Une seule région en échec peut tout de même déclencher une alerte de moindre gravité, utile pour repérer des problèmes de routage ou de peering.
Définissez les seuils de latence par rapport à la référence
Des valeurs fixes en millisecondes conviennent rarement à tous les hôtes. Mesurez une référence sur au moins une semaine, en utilisant le p50 pour le comportement typique et le p95 pour la variance normale, puis alertez sur les écarts :
- Avertissement : latence soutenue à 1,5 à 2 fois la référence sur plusieurs vérifications consécutives.
- Critique : 3 fois la référence, ou un plafond absolu au-delà duquel votre application ne fonctionne plus correctement, par exemple 250 ms pour un backend d'API interactif.
Combinez les deux : un seuil relatif détecte un lien LAN qui passe de 5 ms à 20 ms, tandis qu'un plafond absolu protège les utilisateurs même lorsque la référence dérive vers le haut.
Perte de paquets et gigue
La perte de paquets est souvent le premier signe d'un lien défaillant ou d'une interface saturée. Évaluez-la sur une fenêtre glissante, par exemple les 10 à 20 dernières sondes, plutôt qu'à chaque vérification. Les valeurs de départ typiques sont au-dessus de 2 % pour un avertissement et au-dessus de 10 % pour le critique ; sur les liens LAN, toute perte persistante mérite une investigation.
La gigue (jitter), c'est-à-dire la variation entre temps aller-retour consécutifs, compte surtout pour la voix, la vidéo et les API temps réel. Environ 30 ms constitue un seuil d'avertissement courant pour ces charges. Pour le trafic web ou batch, traitez la gigue comme un signal de diagnostic plutôt que comme un déclencheur d'alerte.
Seuils de départ par type d'hôte
| Type d'hôte | Intervalle | Timeout | Échecs | Latence avert. / crit. | Perte avert. / crit. |
|---|---|---|---|---|---|
| Serveur LAN | 30s | 1s | 2 | 2x / 3x la référence (ex. 5 / 10 ms) | >0,5 % / >2 % |
| VM cloud, même région | 30s | 1s | 2–3 | 2x / 3x la référence (ex. 20 / 40 ms) | >1 % / >5 % |
| Intercontinental | 60s | 3s | 3 | 1,5x / 2x la référence ou 300 ms absolu | >2 % / >10 % |
| Équipement edge / IoT | 2–5 min | 5s | 3–5 | 2x / 3x la référence | >5 % / >15 % |
Remplacez les valeurs d'exemple par vos propres références au cours des premières semaines.
Ajuster pour réduire les faux positifs
- Analysez chaque alerte pendant deux semaines. Classez-la comme réelle, transitoire ou liée à la sonde.
- Augmentez le nombre d'échecs requis avant d'allonger l'intervalle afin de filtrer les pertes de sonde isolées.
- Ajoutez une vérification TCP en complément de l'ICMP. Certains réseaux limitent ou dépriorisent l'ICMP ; une sonde TCP sur un port connu confirme si le service est réellement joignable.
- Recalculez les références après tout changement d'infrastructure, comme un changement de région ou de nouveaux pare-feu.
- Séparez l'acheminement des avertissements et des alertes critiques. Envoyez les avertissements vers un canal Slack ou Microsoft Teams et les états critiques par e-mail, Telegram ou webhook.
Le monitoring ping UpScanX exécute des vérifications ICMP, TCP et UDP depuis plus de 15 sites dans le monde, ce qui simplifie les règles de quorum, et ses rapports IA signalent les anomalies de latence progressives. Pour des conseils de configuration plus larges, consultez nos bonnes pratiques de monitoring ping.
Points clés à retenir
- Le délai de détection correspond grosso modo à l'intervalle multiplié par le nombre d'échecs, plus le timeout ; ajustez les trois ensemble.
- Exigez un quorum multi-sites avant de déclarer un hôte hors service.
- Alertez sur la latence par rapport à la référence, avec un plafond absolu en filet de sécurité.
- Utilisez des fenêtres glissantes pour la perte de paquets et réservez les alertes de gigue au trafic temps réel.
- Revoyez les seuils après les deux premières semaines et après chaque changement réseau.