Surveiller le point d’accès de santé de votre application

Ce que vous saurez

• L’application répond, avec le code d’état attendu. Gryphon suit les redirections et juge la réponse finale ; un 503 ou une page de connexion là où se trouvait /healthz est donc un problème.
• Elle se dit en bon état, dans ses propres mots. La vérification peut exiger un texte dans la réponse, comme "status":"ok" ; un 200 qui signale une dépendance en échec compte donc quand même comme un échec.
• Le certificat devant elle n’est pas sur le point d’expirer, pour une application servie en HTTPS.

Une application sur Internet est vérifiée depuis les serveurs de Gryphon, comme vos utilisateurs la joignent. Une application sur un réseau privé, ou liée à localhost, est vérifiée par l’agent sur une machine voisine. Les réglages sont les mêmes dans les deux cas.

Ce que ceci ne peut pas vous dire : tout ce que le point d’accès ne vérifie pas. Un point d’accès de santé qui répond seulement ok prouve que le processus tourne. S’il n’interroge pas aussi la base de données, Gryphon ne saura pas qu’elle est en panne. Plus votre point d’accès vérifie de choses, plus Gryphon en sait.

Avant de commencer

• Un point d’accès qui dit la vérité. Un bon point d’accès répond 200 avec un court corps comme {"status":"ok"} quand l’application peut faire son travail, et 503 quand elle ne le peut pas. Il vérifie ce dont l’application dépend, chaque élément avec un court délai d’expiration, et répond bien en deçà de dix secondes.
• La machine où tourne l’application, ajoutée comme hôte dans Gryphon. Pour une application publique, utilisez le nom qu’emploient vos utilisateurs, comme api.example.com.
• Pour une application que seul votre propre réseau peut joindre, l’agent Gryphon sur cette machine ou sur une machine voisine.

Voyez exactement ce que la vérification verra en interrogeant vous-même le point d’accès :

curl -si https://api.example.com/healthz

Étapes

1Le vérifier de l’extérieur

Ouvrez l’hôte, allez dans Services, choisissez Ajouter le service, puis Surveiller une page Web.

Un chemin est récupéré depuis l’hôte en HTTPS ; /healthz sur api.example.com donne donc https://api.example.com/healthz. Pour du HTTP simple ou un autre port, donnez l’URL complète, comme http://api.example.com:8080/healthz.

La réponse contient cherche exactement le texte que vous tapez, majuscules et espaces compris. Si votre application envoie {"status": "ok"} avec une espace après le deux-points, tapez-le avec l’espace. Copiez le texte depuis la sortie de curl ci-dessus plutôt que de l’écrire de mémoire.

Codes d’état acceptés prend des codes seuls et des plages, séparés par des virgules, comme 200-299 ou 200,204. HEAD est plus léger que GET, mais n’a pas de corps où chercher ; on ne peut donc pas le combiner avec La réponse contient.

2Surveiller le certificat

Ajoutez Certificat SSL au même hôte. Laissez Port à 443 et Vérifier le certificat à true. La vérification avertit 30 jours avant l’expiration du certificat et signale un problème à 7 jours. Elle repère aussi un certificat qui n’est plus de confiance, ou qui n’est plus émis pour le nom de l’hôte.

3Ou le vérifier de l’intérieur, par l’agent

Pour une application sur une adresse privée, un nom interne ou 127.0.0.1, ajoutez HTTP (agent) à l’hôte où tourne l’agent :

Hôte est l’adresse telle que l’agent la voit. L’agent ne joint que son propre réseau ; une adresse publique est donc refusée, sauf si l’agent a été lancé avec GWC_ALLOW_PUBLIC_TARGETS. Donnez un Nom à chaque vérification, puisqu’un seul agent peut surveiller autant d’applications que vous voulez.

Pour HTTPS, choisissez HTTPS (agent). Son Hôte doit être le nom pour lequel le certificat a été émis. Pour une application interne avec un certificat autosigné, réglez Vérifier le certificat à false.

Faire un essai

1. Utilisez Vérifier maintenant sur la nouvelle vérification. Un résultat en bon état ressemble à https://api.example.com/healthz - 200 OK in 84ms.
2. Faites échouer le point d’accès sur une copie de préproduction, en arrêtant sa base de données ou en renvoyant 503. Le message dit quelle règle a échoué, par exemple 503 Service Unavailable (accepted: 200), ou 200 OK, but the response did not contain "\"status\":\"ok\"".
3. Gryphon revérifie chaque minute dès qu’une vérification échoue, et alerte quand trois résultats de suite concordent. Un seul déploiement lent ne réveille personne.

Variantes

Depuis plus d’une région

Avec les forfaits Pro et Teams, Surveiller une page Web peut s’exécuter depuis plusieurs régions, sous Vérifier depuis. Cela repère une périphérie de CDN ou un acheminement qui échoue pour une partie du monde. Les vérifications de l’agent s’exécutent toujours depuis l’intérieur de votre réseau.

Faire du verdict de l’application un avertissement

Si votre point d’accès signale degraded en plus de ok, un court script peut en faire un avertissement plutôt qu’un échec. Enregistrez-le dans le dossier de scripts de l’agent (voir Utiliser n’importe quel plugiciel Nagios, ou écrire votre propre vérification pour la configuration), et ajoutez-le comme vérification Script (agent). Il lui faut curl et jq.

#!/bin/sh
# The app's own verdict: "ok" is healthy, "degraded" a warning,
# anything else a problem.
URL=http://127.0.0.1:8080/healthz

BODY=$(curl -sS -m 5 "$URL" 2>&1) || { echo "CRITICAL - $BODY"; exit 2; }
STATUS=$(printf '%s' "$BODY" | jq -r '.status // empty' 2>/dev/null)

case "$STATUS" in
    ok)       echo "OK - status is ok"; exit 0 ;;
    degraded) echo "WARNING - status is degraded"; exit 1 ;;
    *)        echo "CRITICAL - status is ${STATUS:-missing}"; exit 2 ;;
esac

La même approche fonctionne pour un point d’accès qui exige un jeton ou un en-tête. Les vérifications HTTP de Gryphon n’envoient ni l’un ni l’autre, mais un script le peut.

Plusieurs services derrière un même point d’accès

Un seul point d’accès qui vérifie tout, c’est simple, mais son alerte dit seulement que quelque chose a échoué. Si vous préférez savoir quoi, exposez un chemin par dépendance, comme /healthz/db et /healthz/queue, et donnez à chacun sa propre vérification. Chaque alerte nomme alors le chemin qui a échoué.