Surveillance synthétique et contrôles de disponibilité : sonder de l'extérieur ce que voient les personnes utilisatrices

Objectif

Détecter que les personnes utilisatrices ne peuvent pas atteindre ou utiliser le service, indépendamment du bon fonctionnement des métriques, journaux ou points de contrôle de santé propres au service, et enregistrer la disponibilité depuis l'extérieur.

Prérequis

Un outil de sondage qui s'exécute hors du réseau de production (le blackbox exporter de Prometheus sonde des cibles HTTP, HTTPS, DNS, TCP, ICMP et gRPC, et expose probe_success ainsi que des métriques de temps), au moins deux emplacements de sondage, et un canal d'alerte qui ne dépend pas du système surveillé. La distinction du livre SRE s'applique ici : la surveillance en boîte noire est orientée symptôme et signale des problèmes actifs (« le système ne fonctionne pas correctement, en ce moment même »), tandis que la surveillance en boîte blanche inspecte l'intérieur et peut voir des problèmes imminents.

Étapes

1. Lister ce dont une personne utilisatrice a besoin dans l'ordre : réponse DNS, poignée de main TLS, la page d'atterrissage, le point d'entrée de connexion ou d'API, une lecture qui touche la base de données, une ressource statique provenant du CDN.
2. Écrire une sonde par étape avec une condition de correction, pas seulement un code de statut : sous-chaîne attendue dans le corps ou champ JSON attendu, cible de redirection attendue, valeur attendue de l'enregistrement DNS, validité du certificat.
3. Fixer le délai d'expiration de la sonde en deçà de l'intervalle de sondage ; le README du blackbox exporter précise qu'un délai d'expiration de collecte Prometheus ne peut jamais dépasser l'intervalle de collecte.
4. Exécuter chaque sonde depuis au moins deux emplacements sur des réseaux différents ; ne considérer un échec comme réel que s'il persiste sur plusieurs intervalles consécutifs depuis plus d'un emplacement.
5. Déclencher une alerte sur probe_success == 0 selon cette règle et conserver la série des durées pour les tendances de latence ; une lenteur soudaine depuis un seul emplacement indique en général un chemin réseau, depuis tous les emplacements, le service lui-même.
6. Marquer le trafic de sondage (un agent utilisateur ou un en-tête dédié) afin qu'il soit exclu des analyses, des limitations de débit et des alertes de sécurité.
7. Répéter l'exercice : pointer une sonde vers une cible de pré-production volontairement cassée et confirmer que l'alerte arrive bien par le chemin externe.

Résultat attendu

Un relevé de disponibilité du point de vue de la personne utilisatrice, qui déclenche une alerte en quelques intervalles après une panne et qui continue de fonctionner lorsque c'est la pile de surveillance interne elle-même qui est en défaut.

Limites et base de vérification

Une sonde ne voit qu'un seul chemin avec un seul client ; elle ne peut pas voir les dégradations qui renvoient une page correcte mais lente pour certaines personnes utilisatrices, ni les parcours connectés, sauf à disposer d'un compte de test et d'actions idempotentes. Sonder des points de terminaison d'écriture en production nécessite de tels comptes et un nettoyage. Les intervalles de sondage et le nombre d'emplacements indiqués ici sont des choix de conception, non des optima mesurés.