Glossaire · Types de surveillance
Un endpoint de health check est une URL, comme /health ou /healthz, qu’un service expose pour que les répartiteurs de charge, les orchestrateurs et la surveillance puissent lui demander s’il fonctionne. Il répond 200 quand le service est en bonne santé et un statut d’erreur, généralement 503, sinon.
Un bon health check teste ce dont le service a besoin pour servir les utilisateurs : une requête rapide à la base de données, au cache, à la file d’attente. Il répond vite, n’a pas d’effets de bord, ne demande pas de connexion ou seulement une clé sans autres droits, et renvoie un petit corps JSON qui indique quel contrôle a échoué.
Il en existe généralement deux types. Un contrôle de liveness indique que le processus tourne et ne doit pas être redémarré ; il reste simple. Un contrôle de readiness indique que l’instance peut recevoir du trafic maintenant, dépendances comprises, pour qu’un load balancer ou Kubernetes puisse la contourner. La surveillance externe a besoin du type readiness.
Méfiez-vous des dépendances que vous ne maîtrisez pas. Si le health check échoue dès qu’une API tierce est lente, toutes les instances peuvent être retirées du service d’un coup. Signalez-les comme dégradées dans le corps de la réponse, et réservez le code de statut aux pannes qui arrêtent vraiment le service.
GET /health
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{"status":"ok","checks":{"database":"ok","cache":"ok"}}
Un moniteur vérifie le code de statut et que $.status vaut ok. Une 503, un délai dépassé ou toute autre valeur fait échouer la vérification.
Les moniteurs d’API Uptimecheck peuvent vérifier un endpoint de health check chaque minute : le code de statut (200 à 399 par défaut, ou les codes que vous définissez), jusqu’à 10 conditions JSON et d’en-tête comme $.status égal à ok, un mot-clé, et jusqu’à 20 en-têtes de requête pour une clé. Le délai d’expiration par défaut est de 10 secondes, et les réponses plus lentes que votre limite déclenchent une alerte de lenteur.
Essai gratuit de 14 jours · Puis gratuit pour 5 moniteurs · Sans carte bancaire
Guides 7 min de lecture
Un endpoint de health check indique aux moniteurs et aux load balancers si votre application peut servir des requêtes. Quoi vérifier, comment le garder rapide et sûr, du code pour Laravel, Express et Flask, et comment le surveiller.
LireGuides 5 min de lecture
Une API peut renvoyer 200 et pourtant être cassée. Une checklist pratique pour la surveillance d’API : méthodes, en-têtes, corps de requête, authentification, réponses attendues et seuils de temps de réponse.
LireAgencies 7 min de lecture
Surveiller uniquement la page d’accueil laisse passer la plupart des pannes. Une checklist des URL et vérifications qui comptent, de la connexion et du paiement aux webhooks, tâches cron, SSL, DNS et serveurs, avec des exemples de configuration.
Lire200 avec un petit corps JSON quand le service et ses dépendances critiques fonctionnent, et 503 sinon. Ajoutez Cache-Control: no-store pour qu’aucun cache ne réponde à sa place.
Oui, s’il ne révèle rien de sensible : ni versions, ni noms d’hôtes, ni messages d’erreur. Sinon, protégez-le par un jeton envoyé dans un en-tête, et donnez au service de surveillance sa propre clé.
Le liveness indique que le processus tourne ; en cas d’échec, le processus est redémarré. Le readiness indique que l’instance peut servir du trafic maintenant ; en cas d’échec, l’instance est retirée de la rotation jusqu’à son rétablissement.
Configurez votre premier moniteur en moins d’une minute, ou explorez d’abord la démo en ligne.
Essai gratuit de 14 jours · Puis gratuit pour 5 moniteurs · Sans carte bancaire
Avec votre accord, Google Analytics et Microsoft Clarity nous montrent quelles pages sont utiles et où les visiteurs bloquent. Ils déposent des cookies pour une durée maximale de 13 mois. Sans votre accord, aucun des deux ne s’exécute. Vous pouvez changer d’avis à tout moment via Paramètres des cookies en bas de la page. Politique de confidentialité