Bien choisir ses intervalles de monitoring

L’intervalle de vérification est le premier réglage d’un moniteur, et le plus souvent choisi au jugé : « le plus court possible ». C’est rarement le bon choix. L’intervalle fixe le délai maximal avant qu’une panne soit vue, mais il fixe aussi la charge envoyée au service, le volume d’alertes à absorber et le coût de la supervision. Ce guide aide à le régler service par service.

Ce que l’intervalle change vraiment

Un moniteur ne voit une panne qu’au moment où il vérifie. Avec un intervalle de 5 minutes, une panne qui commence juste après une vérification reste invisible jusqu’à la suivante : jusqu’à 5 minutes dans le pire des cas, 2 min 30 en moyenne. Passer à 1 minute ramène ce pire cas à 1 minute.

Ce délai s’ajoute à tout ce qui suit la détection : l’envoi de l’alerte, le temps qu’il faut à quelqu’un pour la lire, puis pour agir. Gagner quatre minutes sur la détection n’a de valeur que si le reste de la chaîne suit. Sur un service dont personne ne lit les alertes la nuit, un intervalle de 30 secondes ne change rien à l’heure à laquelle la panne sera corrigée.

La bonne question n’est donc pas « à quelle vitesse puis-je détecter ? », mais « combien de minutes de panne non détectée ce service peut-il se permettre ? ».

Le coût d’un intervalle trop court

Un intervalle court n’est pas gratuit, même quand l’outil le permet.

• Plus de bruit. Plus on vérifie souvent, plus on capte de micro-coupures : un redémarrage de quelques secondes, un pic de latence réseau, un déploiement. Chacune peut devenir une alerte, et une équipe qui reçoit trop d’alertes finit par ne plus les lire (voir Réduire le bruit des alertes de monitoring).
• Plus de charge sur le service. Toutes les 30 secondes, cela fait 2 880 requêtes par jour et par moniteur. Ce n’est rien pour une page d’accueil, mais c’est significatif pour un point d’entrée qui interroge une base de données, et un pare-feu applicatif peut finir par bloquer la sonde comme un robot.
• Plus cher. Les intervalles courts sont réservés aux plans supérieurs chez la plupart des éditeurs. Les payer pour des services qui n’en ont pas besoin, c’est du budget qui ne protège rien.

Une grille par type de service

La grille ci-dessous part d’une question : que perd-on, concrètement, pour chaque minute où la panne passe inaperçue ?

Service	Intervalle conseillé	Pourquoi
Tunnel de paiement, API facturée au client	30 s à 1 min	Chaque minute de panne se compte en ventes ou en pénalités
Application utilisée en continu	1 min	Les utilisateurs remarquent la panne avant vous
Site vitrine, blog, documentation	5 min	Une panne courte a peu d’effet, une longue se verra
Outil interne, back-office	5 min	Les utilisateurs sont joignables et peuvent prévenir
Tâche planifiée (sauvegarde, export)	Heartbeat	Il n’y a rien à interroger : c’est la tâche qui signale

Deux réglages complètent la grille :

• Surveillez le parcours, pas seulement la page d’accueil. Une page d’accueil en cache peut répondre 200 alors que la connexion ou le paiement sont en panne. Un moniteur à 1 minute sur la page de paiement vaut mieux que dix moniteurs à 30 secondes sur des pages statiques.
• Vérifiez le contenu, pas seulement le code HTTP. Une page d’erreur applicative peut répondre 200. Un moniteur à mot-clé, qui cherche un texte attendu dans la réponse, ou une assertion sur une réponse JSON, attrape ces pannes que le code de statut ne montre pas.

Les tâches planifiées : inverser la logique

Une sauvegarde nocturne ou un export horaire n’a pas d’adresse à interroger. La bonne approche est le moniteur heartbeat : c’est la tâche qui appelle une URL à chaque exécution réussie, et l’alerte part si cet appel n’arrive pas dans le délai prévu.

L’intervalle à choisir est alors celui de la tâche elle-même, plus une marge de tolérance : une sauvegarde qui tourne toutes les 24 heures et dure habituellement 40 minutes mérite une marge d’au moins une heure, sans quoi la moindre lenteur déclenchera une alerte.

Les certificats et les domaines à part

L’expiration d’un certificat SSL ou d’un nom de domaine se prépare en jours, pas en minutes. La vérifier toutes les 30 secondes n’apporte rien : ce qui compte, c’est d’être prévenu suffisamment tôt pour renouveler. Une vérification par jour, avec plusieurs rappels échelonnés avant l’échéance, suffit largement.

Ce que propose Uptally

L’intervalle se règle moniteur par moniteur, de 5 minutes à 1 heure sur le plan Starter, et jusqu’à 1 minute à partir du plan Growth. Rien n’oblige à appliquer le minimum à tous les moniteurs : c’est ce qui permet de suivre la grille ci-dessus au sein d’un même plan.

Le moniteur heartbeat, le moniteur à mot-clé et l’assertion JSON sont disponibles à partir du plan Growth, comme la surveillance des certificats et des domaines : elle s’active sur un moniteur HTTPS, vérifie chaque nuit, et prévient 30, 14, 7, 3 puis 1 jour avant l’expiration du certificat.

En résumé

• Partez de ce que coûte une minute de panne non détectée, pas de l’intervalle le plus court disponible.
• Réservez les intervalles courts aux parcours critiques : paiement, API facturée, application utilisée en continu.
• Préférez un moniteur bien placé à plusieurs moniteurs rapides.
• Pour les tâches planifiées, utilisez un heartbeat avec une marge réaliste.