Surveillance de ping

À quoi sert le ping si je surveille déjà le HTTP ?

La surveillance HTTP indique si un site renvoie une réponse correcte. Le monitoring ping indique si la machine est joignable tout court. Ce sont des questions différentes, et la nuance compte quand une panne survient. Si l’application web plante mais que le serveur tourne encore, le HTTP est hors service – le ping fonctionne. Cela permet d’affiner instantanément le diagnostic. Si les deux tombent – c’est une panne réseau ou infrastructurelle. Si seul le ping échoue – il est possible qu’un pare-feu commence à bloquer les sondes, mais le HTTP fonctionne toujours pour les utilisateurs.

Le monitoring ping est aussi l’outil adapté pour les hôtes qui n’exposent pas du HTTP : serveurs de base de données, serveurs de mail, serveurs applicatifs derrière un load balancer, passerelles VPN, services internes – partout où vous devez simplement savoir « est-ce que cette boîte est vivante et accessible ».

Pourquoi un ping basé sur TCP

Le ping ICMP classique (commande « ping ») est excellent sur un poste de travail, mais peu fiable pour une supervision depuis le cloud. La plupart des firewalls récents bloquent ou limitent l’ICMP, en particulier depuis l’extérieur, ce qui fait que le timeout ICMP « serveur down » peut tout aussi bien signifier « le pare-feu a jeté le paquet ». Cette ambiguïté est catastrophique pour un outil d’alerte.

DiagnoSEO Uptime Monitoring utilise un ping TCP : le test ouvre une connexion TCP sur un port connu (d’abord 80, puis en secours 443) avec un timeout de 5 secondes. Si un SYN/ACK revient – l’hôte est joignable. Sinon – vous recevez une vraie erreur, avec un code du noyau (connection refused, timeout, no route to host), ce qui accélère le triage.

Que conserve-t-on ?

Chaque test ping enregistre le résultat (up / down) et le temps RTT en millisecondes. Cela s’intègre dans la même pipeline d’historique que les surveillances HTTP — vous obtenez un sparkline des derniers tests, les pourcentages de disponibilité sur 24h et 30j, ainsi qu’une carte de chaleur d’accessibilité des 30 derniers jours. Si un hôte tombe, un incident est ouvert et des notifications sont envoyées sur les canaux activés.

Conseils pour les moniteurs ping

• Choisissez un court intervalle : le ping coûte peu, mettez 1 à 5 minutes si votre plan le permet. Une détection plus rapide à faible coût.
• Combinez avec la surveillance des ports : si vous avez une base sur 5432 ou un mail sur 25, ajoutez aussi un moniteur de port. Ping dit « la boîte est vivante », le port dit « le service écoute ».
• Surveillez le RTT : le temps de réponse est enregistré à chaque vérification. Des pics soudains de RTT précèdent parfois une panne totale — configurez un seuil et vous les attraperez avant l’incident.
• Utilisez le seuil de confirmation : les réseaux « clignotent ». Par défaut, deux tests consécutifs en erreur protègent des faux positifs.

Comment ça s’intègre au dashboard

Les moniteurs ping apparaissent aux côtés des moniteurs HTTP, port, mot-clé, API et heartbeat dans la même liste. Vous pouvez les taguer (« infra », « interne »), filtrer par statut, trier par RTT et les mettre en pause/reprendre comme n’importe quel autre. Les alertes passent par les mêmes canaux (Email, Telegram, Slack, Discord, SMS) avec les mêmes règles de silence nocturne et seuil de confirmation.

Configuration

Ouvrez l’outil, cliquez sur « Ajouter un moniteur », choisissez le type « Ping (TCP) », collez l’hôte (par ex. db.internal.firma.com), définissez l’intervalle et enregistrez. Dès le prochain cycle, le moniteur ouvre une connexion TCP chaque minute, enregistre le RTT et vous notifie si l’hôte cesse de répondre.

Foire aux questions

• À quoi sert la surveillance ping ?

  Vérifiez l’accessibilité en couche 3 — si un hôte répond à un écho ICMP. Utile pour les routeurs, switchs, objets connectés, infrastructure interne et tout ce qui ne fonctionne pas sur HTTP mais doit rester accessible.

• Pourquoi mon serveur AWS/cloud ne réussit-il pas les tests ping ?

  La plupart des fournisseurs cloud bloquent par défaut l’ICMP au niveau des security groups ou firewalls. Le serveur lui-même va bien mais ne répond pas au ping. Pour les workloads cloud, privilégiez les vérifications HTTP ou TCP. Vous pouvez autoriser l’ICMP dans vos security groups si le ping est vraiment nécessaire.

• Quelle est la différence entre ping et test de port TCP ?

  Le ping utilise ICMP (pas de port — pure accessibilité couche 3). Un port TCP ouvre une connexion sur un port précis — atteste de la connectivité couche 4. Un hôte peut répondre au ping mais échouer en TCP (pare-feu bloquant le port), ou l’inverse (ICMP bloqué, port ouvert).

• Mesurez-vous le temps de round-trip ping ?

  Oui — le temps de réponse (aller-retour) est enregistré à chaque test et suivi dans le temps. Utile pour détecter une dégradation du réseau : si l’hôte reste le même mais que le RTT grimpe doucement de 20ms à 200ms, c’est qu’il y a un problème de routage ou de congestion.

• Puis-je pinger des IP internes ?

  Seulement si l’IP est atteignable depuis nos serveurs de vérification — donc une IP publique. Les plages privées RFC1918 (192.168.x.x, 10.x.x.x, 172.16-31.x.x) ne fonctionneront pas en supervision externe. Pour l’infrastructure interne, déployez un agent heartbeat auto-hébergé qui pingue depuis votre réseau.