Self Healing avec Jeedom : agir sur erreur

Le Self Healing est une notion en supervision qui consiste à sur un état en erreur, lancer des commandes pour corriger en automatique sans intervention humaine. Et là encore, Jeedom c’est tellement fort que ca fait le job.

 

Self Healing : supervision + orchestration

Finalement, le self healing c’est une combinaison de supervision (savoir quel état est en cours, et si c’est ok ou ko par exemple) et d’orchestration (pouvoir lancer une action suite à un état, valeur, heure …)

Donc Jeedom colle aux deux définitions, il connait les états de pas mal de choses dans votre maison et bien plus encore (à condition d’avoir les bons protocoles par exemple il sait si une lumière est allumée, si vous êtes là etc …)

Il sait également « réagir » à ses états et bien d’autres triggers, rien qu’avec les scénarios.

Voyons maintenant si Jeedom pourrait remplir un rôle de Self Healing, dans le secteur où on utilise le terme, donc la supervision système.

Superviser un site web

Regardons un cas d’école : un site web par exemple un WordPress hébergé sur un Linux donc avec un Nginx et PHP-FPM.

Prenons un scénario simple de supervision. Imaginons qu’on souhaite vérifier si le site répond correctement, si ce n’est pas le cas pendant 5mn, on souhaite redémarrer le service PHP. Après rien n’empêche de faire plus compliqué à l’avenir. Ca restera le même principe si on veut ajouter le redémarrage Nginx, MariaDB …

Pour superviser celui-ci, on peut le faire via le plugin script ou bien Checks Nagios comme on l’a vu ICI par exemple.

Pour redémarrer un service sur un serveur distant, il y a SSH Commander.

Configuration des commandes

Checks Nagios

Côté Check Nagios, on créera une commande utilisant « check_http ». Facile, ce check prend l’argument -H avec le nom du site que vous superviser. Ajoutez un -S si vous êtes en https. Donc pour le blog canardlaque.com qui serait en https, ca donne :

check_http -H canardlaque.com -S

self healing

 

sshcommander_icon

Pour SSH Commander, il faut créer un équipement qui correspond au serveur hébergant le site. A vous de voir si c’est via mot de passe ou via clef SSH. Pareil pour l’utilisateur. (mais attention, il devra savoir faire un sudo service sans mot de passe)

self healing

Et dans une commande, on utilisera par exemple pour redémarrer PHP :

sudo service php7.0-fpm restart

self healing

 

Et la magie Jeedom pour lier les 2

Alors, voilà on a une commande qui donne le statut du site web et une autre qui permet de le réparer. Comment faire pour lier les 2 ? Oui y a les scénarios, mais aussi la fonction native d’action sur condition. Comme sur la vigilance météo, que je vous invite à lire pour plus de détails, on va utiliser les propriétés avancées de la commande Nagios.

Le statut normal a pour valeur 0, donc déclenchons une action si la valeur est différente de 0 pendant X minutes.

 

self healing

 

Et il reste à sélectionner la commande SSH en action.

self healing

Voilà, là on a une base de travail, pour l’exemple c’est suffisant et ca fait déjà le boulot. Après biensur, charge à chacun d’agrémenter et suivant son besoin de complexifier. On pourrait redémarrer plusieurs services. Uniquement via SSH commander, récupérer le statut du service PHP et le redémarrer.

Les possibilités sont sans limites, j’espère juste vous donner des pistes de ce qui est possible.

4 réflexions au sujet de “Self Healing avec Jeedom : agir sur erreur”

  1. Peut on adapter cela au contrôle des démons de jeedom ? Du genre:
    Démon blea down 5 minutes, restart Démon. Même chose avec les antennes.

    Merci

    Répondre
    • Les démons jeedom sont déjà gérés sur ce mode. Toutes les 5mn jeedom vérifie si les démons sont démarrés, si c’est pas le cas il les démarre.
      Dans le cas ou on veut vérifier si ils sont ‘stuck’ oui on peut utiliser cette méthode avec check_nagios, voir scripts tout court. Mais il faut savoir ce qui faut surveiller en plus.
      Exemple jeedom vérifier naturellement que le processus est présent. Mais si ce processus représente un service qui doit écouter en TCP et qui ‘plante’ parfois sans que jeedom le voit. Oui on peut vérifier avec check_TCP qu’il fonctionne, si KO le killer.
      A savoir pour gérer les démons, il y a possibilités d’utiliser jeelink qui fait ca bien (mis façon simple)

      Répondre

Laisser un commentaire