Ping
Surveillance par ping
Est-ce qu'il est là, et est-ce que le lien vers lui perd des paquets.
À quoi ça sert
La question la plus simple que tu peux poser à une machine : est-ce qu'elle répond tout court. Un routeur, un pare-feu, un serveur sans service public, un matériel dans un rack : des choses avec une adresse et rien d'autre à qui parler.
Le ping est un écho ICMP, et il rapporte la perte de paquets ainsi que l'accessibilité, donc un lien qui est actif mais qui perd un cinquième de son trafic est visible comme autre chose que correct. Si ce qui t'intéresse est un service sur un port plutôt que l'hôte, le check de port TCP est celui qui fait la différence.
Comme chaque vérification ici, elle s'exécute depuis Amsterdam, New York, Sydney and Singapore, et un échec est confirmé depuis deux autres continents avant que quelqu'un soit réveillé. Comment ça marche.
Ce que tu peux configurer
Tout ce qui suit est dans le formulaire quand tu en ajoutes un, sur chaque forfait.
- Hôte ou adresse IP
- Un nom d'hôte ou une adresse. Pas de port : le ping n'est pas une connexion à quoi que ce soit sur l'hôte, c'est l'hôte qui répond.
Questions
Qu'est-ce que le check de ping mesure réellement ?
Quatre requêtes d'écho ICMP, espacées d'une demi-seconde, et il rapporte la perte de paquets en pourcentage ainsi que la latence : le temps de trajet aller-retour minimum, moyen et maximum. Quatre plutôt qu'une, donc un seul paquet perdu sur un lien occupé est visible comme une perte plutôt que lu comme une panne.
Une perte partielle de paquets, c'est up ou down ?
Ni l'un ni l'autre, ce qui est la réponse honnête et celle que ce produit donne. Un hôte qui répond à un ping sur quatre n'est pas down et il n'est certainement pas correct. Une perte totale est down, parce que rien ne répond. Une perte de plus de 20 % sur plusieurs checks consécutifs est dégradée, ce qui alerte sans prétendre que l'hôte est parti.
Est-ce que tu rapportes le jitter ?
Pas comme un chiffre, et on préfère le dire plutôt que de calculer quelque chose à partir de quatre paquets et de mettre un mot dessus. Ce que tu obtiens, c'est le temps de trajet aller-retour minimum, moyen et maximum pour chaque check, et l'écart entre le premier et le dernier est ce que tu aurais lu de toute façon.
Et un hôte qui ne répond pas au ping ?
Beaucoup d'hôtes et de pare-feu bloquent l'ICMP volontairement, et pour un check de ping, c'est indiscernable d'un hôte qui est parti : chaque écho est perdu, donc c'est down. Si l'hôte fait tourner un service, surveille son port avec le check de port TCP à la place, qui n'a pas besoin d'ICMP du tout.
Pourquoi ne pas simplement le pinger moi-même depuis un cron job ?
Un cron job qui ping un hôte est un vrai check et ça ne coûte rien, donc si c'est tout ce dont tu as besoin, fais-le. Ce qu'il ne peut pas faire, c'est te dire si l'hôte a arrêté de répondre ou si c'est ta propre connexion qui l'a fait, parce que ces deux cas se ressemblent depuis un seul endroit. Il tourne aussi sur une machine qui peut perdre son réseau, remplir son disque ou redémarrer, et un check silencieux est pire qu'aucun check. Et il faut encore que quelque chose remarque le résultat et réveille quelqu'un, ce qui est la majeure partie du travail.