Le monitoring ping envoie régulièrement de petits paquets de test à un hôte et enregistre s'il répond, la durée de l'aller-retour et le nombre de paquets perdus. Il indique si une machine est joignable sur le réseau, pas si l'application qu'elle héberge fonctionne. Utilisez le ping pour les équipements et services sans point de terminaison web, et les vérifications HTTP dès que ce qui compte est une page ou une réponse d'API.
Comment fonctionne le monitoring ping
Un ping classique est une requête ICMP echo request, à laquelle la cible répond par un echo reply. Le monitoring suit :
- Temps aller-retour (RTT) : la latence entre l'envoi et la réponse, généralement en moyenne et au p95.
- Perte de paquets : la part des paquets qui ne reviennent jamais. Une perte persistante supérieure à environ 1–2 % sur un lien filaire mérite en général une analyse.
- Gigue (jitter) : la variation du RTT entre les mesures, déterminante pour la VoIP et le trafic temps réel.
De nombreux réseaux bloquent ou limitent l'ICMP. Un ping TCP, qui mesure la poignée de main vers un port ouvert comme 22 ou 443, fournit alors un signal de joignabilité fiable, tandis que les sondes UDP couvrent des services comme le DNS sur le port 53. Pour le détail du fonctionnement, consultez comment fonctionne le monitoring ping.
Ping vs vérifications HTTP : couche 3 vs couche 7
La différence essentielle tient à l'endroit où chaque vérification s'arrête : la couche réseau pour le ping, la couche application pour HTTP.
| Question | Ping (ICMP/TCP/UDP) | Vérification HTTP |
|---|---|---|
| L'hôte est-il joignable ? | Oui | Indirectement |
| La route se dégrade-t-elle (latence, perte) ? | Oui | Partiellement |
| Le serveur web renvoie-t-il un 200 ? | Non | Oui |
| Le contenu de la réponse est-il correct ? | Non | Oui, avec des assertions sur mots-clés ou JSON |
| Fonctionne sur des équipements sans serveur web ? | Oui | Non |
Un serveur peut répondre parfaitement au ping alors que Nginx renvoie des 502 ou que l'application redémarre en boucle. Un ping réussi ne prouve jamais qu'un site est en ligne.
Quand le ping est le bon choix
Le ping est la meilleure vérification principale lorsque la cible n'expose pas d'interface HTTP ou lorsque c'est le chemin réseau lui-même qui importe :
- Routeurs, commutateurs et pare-feu. Ils n'exposent souvent que SSH ou SNMP. Le ping confirme qu'ils sont actifs et révèle une hausse de latence sur les liens montants.
- Passerelles VPN et tunnels site à site. Pinguer un hôte situé derrière le tunnel montre si le trafic passe réellement, et pas seulement si la passerelle est allumée.
- Hôtes de bases de données et de cache. Les hôtes PostgreSQL, MySQL ou Redis ne devraient pas servir de HTTP. Un ping TCP sur le port du service est le signal pertinent.
- Objets connectés et équipements en périphérie. Caméras, capteurs et terminaux de paiement n'ont souvent qu'une adresse IP et un répondeur ICMP.
- Serveurs de messagerie, de jeu et autres serveurs non HTTP. SMTP, services TCP personnalisés et serveurs de jeu UDP se prêtent bien aux sondes TCP ou UDP.
Des intervalles de 30 à 60 secondes sont courants, avec une alerte après deux ou trois échecs consécutifs pour filtrer les coupures passagères.
Quand les vérifications HTTP sont indispensables
Tout ce que vos clients atteignent via un navigateur ou une bibliothèque cliente exige un monitoring HTTP : sites web, parcours de connexion et de paiement, API REST et GraphQL. Les vérifications HTTP contrôlent les codes de statut, le temps de réponse, les redirections et le contenu, et détectent ainsi les pannes situées au-dessus de la couche réseau : déploiements défectueux, erreurs de base de données remontant en 500 ou CDN mal configurés. Si votre SLA comptabilise les requêtes réussies, le ping seul ne peut pas le mesurer.
Pourquoi combiner les deux accélère le diagnostic
Exécuter les deux vérifications sur le même service transforme une alerte « site indisponible » en diagnostic :
- Ping en échec, HTTP en échec : probablement un problème de réseau, d'hôte ou de fournisseur.
- Ping réussi, HTTP en échec : l'hôte est joignable ; examinez le serveur web, l'application, TLS ou les dépendances en amont.
- Les deux réussissent, mais la latence grimpe : comparez le RTT et le temps de réponse HTTP pour distinguer congestion réseau et code lent.
Plusieurs régions ajoutent une dimension supplémentaire : si un seul emplacement perd le ping, soupçonnez une route régionale plutôt que votre serveur. UpScanX exécute des sondes ICMP, TCP et UDP en parallèle des vérifications HTTP/HTTPS depuis plus de 15 emplacements dans le monde, de sorte que les deux signaux partagent une même chronologie, et ses rapports IA corrèlent les alertes liées en proposant des pistes de cause racine. Les alertes sont envoyées par e-mail, Slack, Telegram, Microsoft Teams ou webhook.
À retenir
- Le ping mesure la joignabilité, le RTT, la perte de paquets et la gigue au niveau réseau ; il ne dit rien de la santé de l'application.
- Privilégiez le ping, ou les sondes TCP et UDP lorsque l'ICMP est filtré, pour les routeurs, pare-feu, passerelles VPN, hôtes de bases de données, objets connectés et serveurs non HTTP.
- Utilisez les vérifications HTTP pour tout ce dont dépendent vos utilisateurs ou clients d'API.
- Associez les deux sur les services critiques pour que le schéma d'alertes indique lui-même quelle couche est en panne.
Pour ajouter des vérifications réseau à côté de vos moniteurs de disponibilité, commencez par le monitoring ping d'UpScanX.