Quand un client se plaint que "ça lag", la réponse réflexe est d'ouvrir un terminal et de lancer un ping. Ce qu'on voit à l'instant T ne dit rien de l'état du réseau hier à 14h ou avant-hier la nuit. Sans données historiques, le diagnostic reste anecdotique.
SmokePing résout ce problème depuis 2003. Outil créé par Tobias Oetiker (le même qui a créé MRTG et RRDtool), il sonde en continu un parc de cibles avec ICMP, DNS, HTTP, et bien d'autres protocoles, stocke les résultats en RRD, et produit des graphes qui montrent latence, jitter et perte de paquets sur la durée.
Pour les opérateurs réseau qui doivent diagnostiquer des dégradations, prouver la qualité d'un lien à un client, ou détecter une congestion qui se construit lentement, SmokePing est l'outil de référence.
Plan de l'article
- Pourquoi mesurer la latence en continu
- Architecture SmokePing
- Sondes disponibles
- Configuration : Targets et alerts
- Lecture des graphes : latence, jitter, perte
- Intégration avec Prometheus et Grafana
- Cas d'usage en prod
- Limites et alternatives
Pourquoi mesurer la latence en continu
Trois problèmes que SmokePing met en évidence et que ping ad hoc ne montre pas.
Dégradation lente. Une fibre commence à dériver, latence passe de 5 ms à 8 ms à 15 ms sur deux semaines. Aucune alerte ne se déclenche. Les utilisateurs commencent à se plaindre. SmokePing montre le drift sur le graphe historique avant que ça devienne critique.
Perte de paquets intermittente. Un câble RJ45 abimé perd 0.5% des paquets. Le ping moyen est ok, mais TCP se dégrade fortement. SmokePing graphe la perte sur 24h et identifie le pattern (par exemple : tous les soirs entre 19h et 22h, congestion BSC mobile).
Jitter (variabilité de latence). Un lien moyenne 10ms mais avec des pics à 80ms. Pour de la VoIP ou du gaming, c'est un cauchemar. Ping classique ne montre pas. SmokePing affiche le "smoke" (l'écart-type) qui révèle ces oscillations.
Pour les ISP, les hébergeurs, et les opérateurs réseau, c'est l'outil qui tient depuis 20 ans malgré la bataille des outils plus modernes.
Architecture SmokePing
SmokePing est en Perl, simple à comprendre :
- Daemon : exécute les sondes selon un cron interne (toutes les 5 minutes par défaut, configurable).
- Sondes (probes) : modules Perl qui font le test (FPing, DNS, HTTP, etc.). Chaque probe lance N mesures par cycle (typiquement 20).
- RRD : stockage en round-robin database. Permet conservation longue durée à coût stockage faible (typiquement 50-100 Mo pour 1 an de données sur 50 cibles).
- CGI Web : serveur web qui génère les graphes à la demande. Pas de DB additionnelle.
- Alerts : système de matching de patterns sur les courbes (par exemple : "loss > 2% pendant 3 cycles consécutifs").
Pas de base de données, pas de message broker, pas de dépendances lourdes. Un seul process Perl + un Apache/Nginx pour servir l'interface.
Stack typique sur Debian/Ubuntu :
sudo apt install smokeping
# Le daemon démarre automatiquement
# UI accessible sur http://serveur/smokeping/
Sondes disponibles
SmokePing propose 15+ sondes. Les plus utiles :
| Sonde | Mesure | Cas d'usage |
| FPing | ICMP latence + perte | Test générique de réseau |
| FPing6 | Idem en IPv6 | Suivi v6 |
| DNS | Résolution DNS | Surveiller un resolver |
| HTTP / HTTPS | TTFB HTTP | Surveiller un service web |
| TraceRoute | Hops vers une cible | Détecter changement de chemin |
| NTP | Latence NTP | Surveiller un serveur de temps |
| TCPPing | TCP SYN/SYN-ACK | Quand ICMP est filtré |
| EchoPing | Echo TCP/UDP | Test L7 simple |
| LDAP | Latence LDAP search | Surveiller AD/LDAP |
| Radius | Auth RADIUS | Surveiller AAA |
| AnotherDNS | DNS sur DNSSEC, EDNS, etc. | Tests DNS avancés |
| SSH | Connexion SSH | Surveiller un bastion |
La sonde FPing est le défaut : elle pingue les cibles en parallèle, retourne 20 mesures en quelques secondes par cycle. Pour les réseaux qui filtrent ICMP, TCPPing prend le relais.
Configuration : Targets et alerts
Configuration /etc/smokeping/config.d/Targets en format hiérarchique simple :
*** Targets ***
probe = FPing
menu = Top
title = Network Latency
remark = Welcome to the SmokePing site
+ Internet
menu = Internet
title = External targets
++ Google
menu = Google DNS
title = Google Public DNS
host = 8.8.8.8
++ Cloudflare
menu = Cloudflare
host = 1.1.1.1
+ Internal
menu = Internal
title = Internal targets
++ Router
menu = Edge router
title = Edge router R1
host = 10.0.0.1
++ DC2
menu = Backbone DC2
host = backbone-dc2.exemple.fr
Chaque cible apparait dans la nav UI. Les + ouvrent des sous-menus.
Configuration des alertes dans /etc/smokeping/config.d/Alerts :
*** Alerts ***
to = ops@exemple.fr
from = smokeping@exemple.fr
+ lossdetect
type = loss
pattern = >0%,*12*,>0%,*12*,>0%
comment = continuous packet loss
+ bigloss
type = loss
pattern = ==0%,==0%,==0%,==0%,>20%,>20%,>20%
comment = sudden major loss
Les patterns expriment des suites d'observations consécutives qui déclenchent l'alerte. Le système est verbeux mais expressif.
Lecture des graphes : latence, jitter, perte
Un graphe SmokePing classique a trois éléments visibles :
- Ligne médiane : latence médiane sur les 20 mesures du cycle.
- Smoke (zone grise/colorée autour) : étendue des 20 mesures (jitter). Plus le smoke est épais, plus le réseau est instable.
- Couleur : indique la perte de paquets sur le cycle. Vert = 0%, jaune = 1-5%, rouge = >5%.
Lire le graphe :
- Ligne stable et fine + tout vert = lien sain.
- Ligne qui dérive vers le haut = dégradation latence.
- Smoke épais = jitter, lien instable.
- Bandes rouges = perte de paquets.
- Pics ponctuels = micro-coupures, à corréler avec d'autres sources (logs équipement, alertes).
Sur 1 an, on peut zoomer sur une période et identifier le moment exact où la dégradation a commencé. Indispensable pour des post-mortems incident.
Intégration avec Prometheus et Grafana
SmokePing est antérieur à Prometheus mais cohabite bien.
Pour exposer les métriques SmokePing en Prometheus, le projet smokeping_prober (Python) reproduit le concept en mode Prometheus exporter. Mêmes sondes, mêmes mesures, mais en pull Prometheus.
Pattern hybride utile :
- SmokePing : pour la vue historique année et la lecture rapide par le NOC.
- smokeping_prober + Grafana : pour les dashboards intégrés et l'alerting Alertmanager.
Plus moderne mais perd l'UI ergonomique de SmokePing pour le diagnostic rapide.
Pour la stack monitoring complète, voir deployer-stack-monitoring qui couvre Prometheus + Grafana, et librenms-snmp-2026 pour le monitoring équipement réseau.
Cas d'usage en prod
ISP régional. SmokePing surveille les liens vers chaque PoP, vers les transitaires, vers les peerings. NOC passe le matin par l'UI SmokePing pour repérer les dégradations qui n'ont pas déclenché d'alerte hard.
Hébergeur. Surveillance des liens entre DC, vers les CDN, vers les services critiques. Diagnostic rapide quand un client se plaint de latence.
Multi-site corporate. Mesure latence des liens MPLS entre les sites, justification des SLA opérateur.
Audit réseau. Sur 30 jours de mesures, identifier des patterns récurrents (par exemple : congestion tous les vendredis 18h sur un site spécifique).
SLA reporting. Producteur de PDF mensuels avec graphes SmokePing pour clients qui ont un SLA réseau contractuel.
Limites et alternatives
UI vieillissante. SmokePing date. L'interface CGI ne respire pas la modernité 2026. Fonctionnel mais pas séduisant.
Pas de multi-tenancy native. Pour proposer SmokePing en tant que service à des clients, il faut bricoler une authentification frontale.
Pas de modèle pull moderne. SmokePing pousse depuis le serveur central vers les cibles. Si la cible est derrière NAT ou firewall qui bloque ICMP, ne marche pas. Solution : agents distants qui poussent vers SmokePing central, mais demande config additionnelle.
Granularité fixe. 5 minutes par défaut. Pour de la haute résolution (1 minute), demande un réglage manuel. Pour du sub-seconde, hors périmètre.
Pas d'alerting moderne. Le système d'alerts SmokePing est expressif mais lourd. Pour des intégrations PagerDuty/Slack, smokeping_prober + Alertmanager est plus simple.
Alternatives modernes :
- smokeping_prober + Grafana : reproduit SmokePing en stack Prometheus.
- Cacti : monitoring SNMP graphique (cf. librenms-snmp-2026) plus orienté équipement.
- PingPlotter / MTR : outils manuels pour diagnostic ponctuel, pas pour historique.
- Solarwinds NPM, PRTG : équivalents commerciaux.
- Probely / ThousandEyes : SaaS pour mesure depuis multiples Points of Presence.
Pour de la mesure interne basique, SmokePing reste le défaut côté ops. Pour des organisations qui démarrent un projet observability complet, smokeping_prober + Grafana colle mieux à la stack.
SmokePing tient son rôle de "weather station du réseau" : visible en permanence, consulté en quelques secondes pour confirmer ou éliminer une cause réseau lors d'un incident. Pour un monitoring infra qui démarre de zéro, smokeping_prober + Grafana colle mieux à une stack moderne ; sur les parcs déjà établis, SmokePing classique reste pertinent pour la vue historique et la lecture rapide par le NOC. Garder cette weather station vivante (sondes à jour, alertes calibrées, lecture pendant l'incident) prend du temps ; la faire tenir par une exploitation dédiée reste possible.
Sources
- SmokePing documentation officielle : référence install, config, probes.
- GitHub oetiker/SmokePing : code source, communauté.
- smokeping_prober (Prometheus) : équivalent Prometheus exporter.
- RRDtool documentation : moteur de stockage time-series sous-jacent.
- FPing tool : outil de ping parallèle utilisé par SmokePing.
- Network Latency Measurements - RFC 2330 : référence pour les méthodologies de mesure.
