Page History

Contexte

Le check Health by API permet de superviser l’état de santé ( health status ) des conteneurs, basé sur les checks “HEALTHCHECK” définis dans la configuration Docker.

Le check interroge, pour chaque conteneur supervisé :

Quand un conteneur est en fonctionnement, le statut de celui-ci permet de définir son état général. Cependant, dans certains cas, il arrive qu'un conteneur ait besoin d'une ou plusieurs vérifications additionnelles pour attester qu'il fonctionne correctement.

Ces vérifications additionnelles, nommées "healthcheck" dans le jargon Docker, dépendent des utilisateurs pour être ajoutées et ne sont pas configurées par défaut. C'est pourquoi la grande majorité des conteneurs en est dépourvue.

Un healthcheck ne possède pas de structure prédéfinie. Il peut s'agir de n'importe quelle vérification imaginée par l'utilisateur pour attester que le conteneur réponde bien à ses attentes. Il peut prendre la forme : 

• D'un ping pour vérifier que le conteneur communique bien
• D'un statut pour vérifier l'état d'un service
• D'une commande complexe pour vérifier un fonctionnement applicatif
• etc ...

Le check Health by SSH permet ainsi de superviser le retour de ces vérifications

.

Le changement de statut repose sur une seule règle :

• Si un conteneur est en état unhealthy, alors le statut du check passe à warning ou critical, selon les paramètres définis.

Ce check permet :

• de détecter rapidement un service applicatif non-fonctionnel,

• de confirmer qu’un conteneur “vivant” est réellement opérationnel,

• de cibler les conteneurs dont l’application interne est partiellement ou totalement indisponible.

En résumé, ce check offre une supervision plus fine, en s’appuyant sur les mécanismes internes de Docker pour valider le bon fonctionnement interne du conteneur, au-delà de sa simple exécution.

• l’état du healthcheck n'est pas " healthy " ou "no-healthcheck", le check remontera en warning ou critique (  Basé sur la gravité de l'état remonté ).

Ce check permet donc :

• de détecter rapidement un service applicatif non fonctionnel,

• de confirmer qu’un conteneur “running” est réellement opérationnel,

• de cibler les conteneurs dont l’application interne est partiellement ou totalement indisponible.

Pour résumer, ce check offre  un indicateur avancé pour valider le bon fonctionnement interne d'un conteneur,

Paramétrage

Le check utilise la ligne de commande suivante :

$SHINKEN_DOCKER-ON-LINUX-BY-APISSH_PLUGINSDIR$/check_docker_SSH.py 
	--connectionH "$HOSTADDRESS$":
	-u "$_HOSTDOCKER-ON-LINUX-BY-APISSH__PORT$SSH-USER$" 
	--uptimep "$_HOSTDOCKER-ON-LINUX-BY-APISSH__UPTIMESSH-PORT$"
	-k "$_HOSTDOCKER-ON-LINUX-BY-SSH__UPTIMESSH-WARN$":KEY$"
	-x "$_HOSTDOCKER-ON-LINUX-BY-API__UPTIME__UPTIME-CRIT$SSH__SSH-PASSPHRASE$"
	-m "health"
	-e "$_HOSTDOCKER-ON-LINUX-BY-SSH__CONTAINERS-EXCLUDED$"

Données utilisées provenant du modèle

Données communes pour les checks du modèle

Données spécifiques pour ce check

Données DFE ( Duplicate Foreach )

Pas de données DFE pour ce check

Données utilisées provenant du check

Pas de données provenant du check pour ce modèle

Résultat

Exemple

Interprétation des données

Statut

• Il peut prendre 3 valeurs  états OK / CRITIQUE / INCONNU ATTENTION .

  • Le statut va dépendre du retour de sonde.

  • Voici un tableau récapitulatif du statut attendu suivant le retour de sonde :

Résultat

Le résultat court affiche la liste des conteneurs détectés, séparés par des points-virgules ;.Pour chaque conteneur, l’état retourné par le check health est indiqué : starting, healthy, ou unhealthy, en une ligne, un résumé de l'état des healthchecks. Ce retour compact permet de pouvoir visualiser l'information même avec la taille des lignes réduites dans l'interface de visualisation.

Résultat Long

Pas de résultat long pour ce checkLe résultat long affiche un tableau regroupant l'ensemble des conteneurs détectés et le status de leurs healthchecks.

Métriques

Pas de métriques pour ce check.

Erreurs et pré-requis