Journal Zyeute: un outil minimaliste de monitoring… ou pas

Posté par . Licence CC by-sa
36
18
oct.
2016

Salut les gens,

ma vie t’intéresse ? NAAAAANNNNNNN ! alors va zyeuter ça et bonne nuit.
Sinon, en voici un morceau ! RHHHHOOOOOOO …

Au mois de mai dernier, j’ai eu une déconvenue avec l’outil de surveillance de mon fournisseur de serveurs claudes: alors que ma machine n’avait pas redémarré après un incident encore non élucidé à ce jour, cet outil n’a pas cru bon de m’en informer. Après quelques échanges de messages, le support technique m’indique que cet outil n’est pas fiable et que je ne devrais pas me reposer dessus.

Proposer un outil de surveillance et en avouer l’inefficacité… m’enfin !

[ Alors tu vois qu’elle est chouette ma vie ! tu as bien fait de rester ! ]

D’autre part, j’avais depuis plusieurs années un problème de branchement USB capricieux sur mon serveur auto-hébergé: un peu trop sensible aux vibrations de l’agitation citadine, le disque branché sur ce port USB se désactivait régulièrement, m’obligeant à démonter puis remonter régulièrement l’importun. Et pour réaliser cela, j’avais donné à manger à cron un script qui vérifiait l’état du fichier /dev/sda et s’occupait de remettre le tout d’aplomb en cas de disparition inopinée.

[ C’est long hein ma vie ? Détends-toi les gens, on arrive au point qui captivera nécessairement ton attention… ]

Bref, tout ça pour dire que j’avais besoin d’un outil qui irait à la fois vérifier si mon serveur claude était en ligne et si mon serveur auto-hébergé avait bien accès à son disque dur.

Penses-tu que je me serai renseigné pour savoir si cette perle existait déjà ?
Que nenni ! Je suis un guerrier du bisou1 moi !
À besoin simple, solution simple: un script bash et hop, c’était plié, le tout placé en bonne position dans le crontab de mon serveur auto-hébergé !

Et puis je me suis dit que je pourrais ajouter à cet outil la possibilité de jeter un œil à la connectivité de mon serveur auto-hébergé depuis mon serveur claude… et puis pourquoi pas également zyeuter le bon fonctionnement de mes serveurs web claudes et auto-hébergé… et puis pourquoi pas du serveur XMPP, du serveur DAVCAL et tout et tout et tout !

Et pouf, du coup me voilà à transformer mon script tout petit tout simple en un outil beaucoup plus générique: le tout joli tout neuf et bien nommé Zyeute !

Zyeute exploite lâchement un fichier de configuration répertoriant les cibles à surveiller dans un contexte particulier, puis les donne sauvagement à manger à des outils de test indépendants de Zyeute:

  • une IP ? allez hop un ping !
  • une connexion HTTPS ? allez hop une vérification de certificat via openssl !
  • un fichier qui a tendance à disparaître ? allez hop un [ -e monfichier ] !

Seules contraintes pour ces outils de test:

  • comprendre les arguments transmis par Zyeute
  • se terminer par un code de sortie de 0 en cas de succès ou de 1 en cas d’échec

Pour plus de bonheur oculaire, un message d’information renseignant le sujet du succès ou de l’échec est tout de même conseillé, mais on sait aussi faire sans.

Et Zyeute dans tout ça ? Quoi c’est qu’il fait lui ?
Par défaut, Zyeute se contente d’informer la majestueuse assemblée observante, par le biais de la sortie standard, d’une part lors de l’échec d’un test, et d’autre part lors du succès d’un test qui aurait précédemment échoué.
Minimaliste on a dit !

Parce que Zyeute conserve un état des différents tests pour les différentes cibles dans leurs différents contextes, il peut être non seulement utilisé de manière ponctuelle, mais délivre tout son potentiel lors d’une automatisation via ton ordonnanceur de tâches préféré.

Ensuite, personnellement, je me plais à tuber cette information vers les outils de diffusion appropriés tels que messagerie électronique, messagerie instantanée et/ou SMS pour être certain de ne pas manquer la catastrophe annoncée d’un service inévitablement défaillant.

[ Bah voilà tu sais tout les gens ! J’avais prévenu hein: y avait du level ! GG comme on dit chez les jeunes. ]

Ah si ! Comme je m’étais préalablement fait la main avec DLFPLonk, j’ai choisi de capitaliser sur cette expérience de FramaGit, le GitLab de FramaSoft, pour y partager Zyeute sous licence Unlicense.

Outre la correction d’insectes, fruits ignobles de tes retours et remontées peut-être acides, nécessaire avant une version unité, cette version 0.9 ne doit son manque de dixième qu’à l’irrépressible nécessité de la dépouiller de sa dépendance actuelle au bash environnant: avoue, les gens, qu’un Zyeute qui tournerait sous un maximum de coquillages aurait autrement plus de chien !

Tiens d’ailleurs j’en profite pour t’avertir qu’en plus de bash, il te faudra sed, grep, find et jq >= 1.5 pour utiliser mon, que dis-je, notre déjà indispensable Zyeute.
Mais tout cela, et bien plus encore, tu le trouveras dans l’assemblage de mots qui se veut servir de documentation.
Parce qu’il ne faut pas faire l'autruche: il va falloir la retravailler pour attirer le chaland.

Sur ce, bonne nuit les gens et n’oublie pas: Zyeute veille pour toi.


  1. KISS warrior 

  • # Nommage des options

    Posté par (page perso) . Évalué à 2 (+1/-0).

    Petite question, pourquoi préfixer certaines options par un _ ? :)

    svn is the IE6 of version control

    • [^] # Re: Nommage des options

      Posté par . Évalué à 3 (+1/-0).

      pour différencier les cibles de test (sans _) et les contextes de test (avec _): j'aurais tout aussi bien pu ajouter une propriété 'type' dans les objets idoines, mais puisque j'avais seulement 2 types d'objet, j'ai préféré faire simple pour ne pas alourdir le fichier de conf.

  • # DLFPlonk

    Posté par (page perso) . Évalué à 3 (+0/-0).

    Ah si ! Comme je m’étais préalablement fait la main avec DLFPLonk,

    Au passage, merci d'avoir partagé ce script. J'en ai profité pour te créditer dans la dernière rétrospective de la quinzaine pour Linuxfr, ce que j'avais oublié de faire initialement.

    • [^] # Re: DLFPlonk

      Posté par . Évalué à 3 (+1/-0).

      5 ans pour le pondre, ça méritait bien une punition de quelques heures de retard pour mon quart de seconde de gloire !

  • # Monitoring

    Posté par (page perso) . Évalué à 2 (+0/-0).

    Tout le plaisir est de créer son propre outil.

    Cela dit, il existe Xymon, Shinken… très bien faits pour tout ça. Il y a toutefois un peu plus de dépendances.

    D'ailleurs, tu peux installer xymon et comparer….

    Bravo!

    • [^] # Re: Monitoring

      Posté par . Évalué à 5 (+3/-0).

      D'ailleurs, tu peux installer xymon et comparer….

      je ne pense pas que cela soit comparable :)

      D'un coté on a des systèmes dédiés à la surveillance d'un grand nombre de services sur un grand nombre de machines avec outils d'administration et rapports graphiques, et de l'autre un pauvre petit script bash qui se limite à faire tourner séquentiellement des tests et t'informer d'une ligne de texte lorsque ces tests échouent ou se remettent à tomber en marche.

      Les problématiques ciblées par des outils de type Shinken ou Xymon me semblent très éloignées de celles auxquelles Zyeute voudrait répondre.

      Je voulais un outil tout en un, avec une certaine flexibilité, qui m'éviterait de faire des copier/coller/éditer dans mon crontab, devenant à la longue une tannée à maintenir.

      Et comme je le dis dans l'introduction du README.md, le principe de fonctionnement de Zyeute ne le contraignant pas a priori à une problématique spécifique, ce qui m’intéresse en le partageant c'est de découvrir les utilisations inédites que les gens qui auraient la curiosité de l'essayer pourraient en faire.

      • [^] # Re: Monitoring

        Posté par (page perso) . Évalué à 4 (+2/-0).

        Par défaut, Xymon ne zyeute que la machine locale.

        aptitude install xymon
        après, avec ton navigateur tu vas sur http://127.0.0.1/xymon/

        et voilà.

        Ce n'est parce que des outils sont capable de faire de la supervision sur de très nombreuses machines que ce n'est pas adapté pour une poignée de machines.

        Avec Xymon tu as aussi les alertes envoyées par email, ou vers un script, etc.

        Au contraire, je pense que Xymon correspond à tes besoins (sauf qu'il est déjà codé).

        PS : j'aime bien le nom de ton outil…

        • [^] # Re: Monitoring

          Posté par . Évalué à 2 (+0/-0). Dernière modification le 19/10/16 à 12:26.

          alors j'irai voir ça d'un peu plus près

          PS : j'aime bien le nom de ton outil…

          moi aussi :)

  • # Auto hébergement

    Posté par (page perso) . Évalué à 1 (+0/-0).

    Dans la même veine, j'ai un petit script Python qui fait du DNS failover (je sais, c'est mal) entre deux serveurs auto hébergés (un maître et un esclave). Il se base sur l'API XML-RPC de Gandi.

    C'est pratique quand une des deux connexions tombe (ce qui est le cas en ce moment).

  • # Monitoring avec monit

    Posté par . Évalué à 4 (+3/-0).

    Je ne sais pas si tu connais monit, qui est plus simple que Shinken/Nagios. Monit permet de facilement surveiller les services de sa machine, et de les redémarrer si ça ne marche plus. Il y a un certain nombre de modules fournis, mais ça ne doit pas être aussi extensible que ton outil.

    • [^] # Re: Monitoring avec monit

      Posté par . Évalué à 3 (+1/-0).

      Je m'étais intéressé à monit il y a quelques temps de cela, et il m'avait bien plus.
      Honnêtement je ne me souviens plus pourquoi je ne l'avais pas mis en place.

      Après avoir rapidement fait un tour sur le wiki de monit, c'est peut être parce que, même si il est plus simple que Shinken et Nagios, il fait tout de même un tas de choses qui ne correspondent pas à mes besoins.
      Il y a une différence entre pouvoir faire ce que je demande et correspondre à mes besoins: pour moi ces 3 outils sont disproportionnés par rapport à ce que je demande.

      Je vais avoir l'air de me répéter, mais j'ai juste besoin de savoir si ça ne marche pas et quand ça s'arrête de ne plus marcher.
      Ainsi je ne perds pas mon temps à m'inquiéter au sujet d'incidents que je ne peux de toute façon pas anticiper.
      Quand ça arrive, alors je peux intervenir dans un délai optimal, sinon j'utilise mon temps de cerveau disponible à autre chose.

      D'ailleurs aujourd'hui zyeute m'a averti qu'un de mes certificats, que j'avais complètement oublié, allait expirer dans 15 jours, du coup je vais occuper mon temps de cerveau à l'intégration de Let's Encrypt.

      • [^] # Re: Monitoring avec monit

        Posté par . Évalué à 2 (+1/-0).

        En fait monit ne surveille que ce que tu lui dit.
        Il y a une notion de nombre de fois où ça ne marche pas avant d'alerter (ou du niveau d'alerte) ou d'une action automatique. En pratique c'est utile par exemple, si la BDD ne répond pas, au bout de trois fois (ça pouvait être temporaire), je la redémarre, et si ça ne suffit toujours pas, je fais un mail.

        Je dirais que monit demande un tout petit peu de temps pour être bien compris, mais après c'est très vite mis en place, assez facile à relire (c'est un plus difficile à concevoir qu'à relire) et ça fait vraiment bien le travail.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.