Surveillance d’API : vérifications, assertions et parcours utilisateur
Surveillez une API au-delà de son accessibilité : vérifiez la réponse attendue, repérez les ralentissements et alertez les bonnes personnes lorsque le contrat est rompu.
Choisir le bon moniteur
Utilisez HTTP pour un endpoint simple et une vérification de code d’état. Utilisez API lorsque la requête a besoin d’une méthode, d’un corps, d’en-têtes, d’une authentification ou d’une assertion de réponse. Utilisez Browser lorsque la réussite dépend de plusieurs étapes utilisateur telles que la connexion, la navigation ou le paiement. Utilisez Heartbeat lorsque l’appel du système est la meilleure preuve que le travail en arrière-plan est terminé.
Configurer une assertion pertinente
Commencez par un endpoint stable de santé ou de disponibilité. Attendez un code d’état précis et, si utile, une petite valeur dans le corps de réponse qui prouve que la dépendance est prête. Stockez les identifiants comme secrets dans la configuration du moniteur ; ne les placez jamais dans une documentation publique, une page de statut ou du code côté client.
GET https://api.example.com/health
Expected status: 200
Expected body: {"ok":true}Faire des assertions sur le corps de réponse
Un code d’état indique seulement que le serveur a répondu. La vérification de mot-clé affirme ce qui est revenu. Saisissez une assertion par ligne : toutes les lignes doivent correspondre, plusieurs lignes agissent donc comme ET et non OU. Activez les expressions régulières pour traiter chaque ligne comme un motif RE2 et vérifier des valeurs changeantes. L’option de mot-clé absent inverse la vérification et échoue lorsque le texte ou le motif est trouvé. RE2 ne prend pas en charge lookahead, lookbehind ni les références arrière, et seul le premier Mo de la réponse est recherché.
# Literal: every line must appear in the body
"status":"ok"
# Regular expression (RE2): every line must match
"status"\s*:\s*"(ok|healthy)"
"version":"4\.[0-9]+"Lorsqu’un endpoint ne suffit pas
Une API peut renvoyer 200 alors que le parcours vu par le client échoue encore. La surveillance Browser peut valider le parcours d’une personne dans l’application. Pour les files, tâches cron, sauvegardes et pipelines de déploiement, un heartbeat planifié est souvent le signal le plus fiable car il confirme l’achèvement plutôt que la seule disponibilité.
Répondre délibérément aux défaillances
Envoyez les incidents vers les canaux de notification que votre équipe surveille réellement, puis ajoutez des triggers pour les actions sûres à automatiser. Séparez les vérifications bruyantes de celles qui touchent les clients afin que chaque défaillance ait un responsable et un chemin de notification clairs.
Guides associés
Le guide des types de moniteur couvre tous les signaux pris en charge. Le guide Heartbeat contient des exemples copiables pour cron, workers et GitHub Actions ; les notifications expliquent où les incidents sont livrés.