Une bonne sonde est comme un chien de garde bien dressé : elle signale l'intrus, pas le passage du facteur. Entre un contrôle trop mou qui rate les pannes et un contrôle trop nerveux qui réveille l'équipe, le réglage demande un peu de méthode.
Surveiller ce que vit l'utilisateur
Une machine qui répond au ping peut héberger un site cassé. Privilégiez des vérifications qui ressemblent à l'usage : chargement d'une page, appel d'une API, connexion à un compte de test. Un contrôle de bout en bout détecte ce que cent contrôles techniques isolés laissent passer.
Choisir la fréquence selon le délai de détection voulu
Le délai maximal de détection est l'intervalle multiplié par le nombre d'échecs exigés avant l'alerte. Un intervalle de 30 secondes avec trois échecs détecte en une minute et demie au plus. Plus l'intervalle est court, plus les sondes pèsent sur la cible et sur le stockage des mesures.
Sonder depuis plusieurs endroits
Une sonde unique confond une panne du service avec une panne de son propre réseau. Deux ou trois points de contrôle indépendants, avec une règle de majorité, réduisent fortement les fausses alertes. Le calcul de charge induite montre ce que cela coûte.
Exiger plusieurs échecs avant d'alerter
Une seule requête perdue n'est pas une panne. Exiger deux ou trois échecs consécutifs filtre les incidents de quelques secondes. À l'inverse, ne dépassez pas le délai que votre objectif de disponibilité tolère.
Suivre les percentiles, pas seulement la disponibilité
Un service qui répond toujours mais en dix secondes est un service en panne pour l'utilisateur. Suivez les temps de réponse en percentiles et définissez un seuil de lenteur qui déclenche une alerte moins urgente que l'indisponibilité.
Documenter ce que chaque sonde protège
Une sonde sans description devient vite un bruit de fond que personne n'ose supprimer. Pour chacune, notez ce qu'elle vérifie, quel parcours utilisateur elle protège, qui reçoit l'alerte et quelle consigne s'applique. Cette fiche d'une ligne facilite les revues trimestrielles : une sonde qui ne protège plus rien se retire, une sonde manquante se crée. Elle aide aussi les nouveaux arrivants à comprendre ce que l'équipe juge essentiel, bien mieux qu'un schéma d'architecture.
Checklist avant de commencer
- Une vérification de bout en bout par service important
- Intervalle et nombre d'échecs choisis d'après le délai de détection voulu
- Au moins deux points de contrôle indépendants
- Sondes identifiées pour être exclues des statistiques d'audience
- Seuil de lenteur défini en plus de l'indisponibilité
- Alerte envoyée à un canal réellement lu
Questions fréquentes
Faut-il surveiller aussi les pages secondaires ?
Surveillez d'abord les parcours qui rapportent ou qui bloquent l'activité. Étendez ensuite, en gardant le nombre d'alertes sous contrôle.
Qui surveille la supervision ?
Une sonde extérieure à votre infrastructure doit pouvoir alerter même si votre réseau principal tombe. Prévoyez un contrôle de la supervision elle-même.
Combien de sondes faut-il ?
Autant que de parcours essentiels, pas davantage. Mieux vaut quelques vérifications de bout en bout bien réglées que des dizaines de contrôles redondants qui multiplient les alertes.
Ce guide présente des principes généraux : il ne note ni ne recommande aucun site de l'annuaire ni aucun prestataire. Les règles juridiques citées sont rappelées de manière simplifiée : vérifiez-les auprès des sources officielles.
Besoin de matériel ou de fournitures ? L'annuaire classe 14 sites dans la rubrique Baie animalière.
Ouvrir la baieCalculateurs utiles
- 21Fréquence de sondes et charge induiteSondes par jour, charge par cible et délai de détection
- 01Disponibilité (SLA) et indisponibilité autoriséeCombien de minutes d'arrêt un objectif de 99,9 % autorise-t-il ?
- 10Percentiles d'une liste de temps de réponsep50, p90, p95 et p99 d'une série de mesures collées