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.
-
KISS warrior ↩
# Nommage des options
Posté par David Demelier (site web personnel) . Évalué à 2.
Petite question, pourquoi préfixer certaines options par un _ ? :)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Nommage des options
Posté par Anonyme . Évalué à 3.
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 Benoît Sibaud (site web personnel) . Évalué à 3.
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 Anonyme . Évalué à 3.
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 GG (site web personnel) . Évalué à 2.
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!
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Monitoring
Posté par Anonyme . Évalué à 5.
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 GG (site web personnel) . Évalué à 4.
Par défaut, Xymon ne zyeute que la machine locale.
aptitude install 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…
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Monitoring
Posté par Anonyme . Évalué à 2. Dernière modification le 19 octobre 2016 à 12:26.
alors j'irai voir ça d'un peu plus près
moi aussi :)
# Auto hébergement
Posté par Grégory Soutadé (site web personnel) . Évalué à 1.
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 Yggdras . Évalué à 4.
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 Anonyme . Évalué à 3.
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 Alex G. . Évalué à 2.
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.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.