Admins

Bonsoir,

Executive summary: zabbix devrait être remplacé par nagios parcequ'il n'est pas supporté par puppet. Zabbix ne permet pas le test automatisé des services déployés.

Introduction:

Il y a quelque semaines, lorsque j'ai commencé à m'impliquer dans l'administration système de l'April, je ne connaissais pas zabbix. Je pratique nagios depuis de nombreuses années et j'en connais les faiblesses principales : consommateur en ressources et mal maintenu par un upstream développant du logiciel propriétaire. J'ai eu le réflexe de commencer par trouver toutes les raisons possibles pour mettre zabbix de coté. Mais zabbix a été choisit par l'April il y a plusieurs années alors je me suis obligé à apprendre zabbix.

Zabbix à l'April:

Au début du mois de Novembre zabbix était configuré sur le vserver ephedrine sur ns1.april.org et monitorait, via ping uniquement, une partie des autres vservers se trouvant sur ns1.april.org et un de ceux qui se trouve sur pavot.april.org. J'ai ajouté des sondes pour de nouveaux services, incluant tous les vservers qui se trouvent sur pavot.april.org. J'ai aussi ajouté les premières sondes web : zabbix a la capacité de définir des scénarios dédiés à la vérification de la navigation. Le premier objectif était d'obtenir un maximum de tests avant de rebooter pavot.april.org : une opération nécessaire pour y ajouter de la RAM. Les notifications de zabbix reçoivent une attention quotidienne et reflètent les problèmes en cours : la surcharge de pavot essentiellement. J'ai aussi exploré et testé la possibilité d'automatiser l'ajout de sondes : soit par l'API, soit par l'import de fichiers XML.

Gestion centralisée de la configuration:

Pour gérer la configuration des machines de façon centralisée, il faut aussi pouvoir ajouter des alertes dans l'outil de surveillance. Lorsqu'un serveur mail est installé, il faut demander a la surveillance de s'assurer que le serveur mail est disponible.

Nagios est supporté par puppet : il y a des types natifs ( http://docs.puppetlabs.com/references/latest/type.html#nagioscommand ) et on trouve des articles décrivant les meilleures pratiques ( aout 2012 par exemple : http://www.linuxjournal.com/content/puppet-and-nagios-roadmap-advanced-configuration ). L'idée est assez simple : puppet fait un fichier plat ( qui est le format natif utilisé par le serveur nagios ) qui décrit ce que nagios doit surveiller et demande a nagios d'en prendre compte. C'est la méthode la plus commune, gestion centralisée ou non, pour interagir avec nagios.

Zabbix n'est pas supporté par puppet ( ni chef ). Il y a des API ( https://agir.april.org/issues/1017 ) et des fichiers XML d'import ( https://agir.april.org/issues/1027 ) qui permettraient d'ajouter un support zabbix dans puppet. Les essais et discussions autour de l'import XML montrent qu'il s'agit d'une méthode permettant d'aider à la migration d'un serveur zabbix vers un autre. L'import XML n'est pas courament utilisé pour exploiter / modifier un serveur zabbix. Un support zabbix pour puppet devrait donc plutôt s'appuyer sur les API. Il est possible d'obtenir un résultat rapidement en faisant un petit module puppet. Mais la complexité de l'integration puppet et nagios suggère que la maitenance et la maturité d'un tel module représente des semaines de développement et doit se faire de façon coopérative : c'est un projet d'une ampleur qui dépasse la capacité de travail du groupe d'administration système.

L'integration continue des fonctions système:

Les alertes sont des tests qui peuvent être utilisées par un système d'intégration continue pour vérifier que le système de gestion centralisée fonctionne, avant de l'utiliser en production. C'est une approche inhabituelle mais simple. Par exemple, la gestion de configuration centralisée dit qu'il faut lancer un serveur ssh. On y trouve aussi l'ajout d'une alerte vérifiant que le port 22 répond. Pour vérifier que cela fonctionne, le système d'intégration continue lance une machine de surveillance vierge et une machine lambda doit etre configurée. Il patiente ensuite durant une minute et vérifie que l'alerte confirme que le port 22 répond. Dans le cas contraire le système d'intégration continue signale l'échec et il est possible de débugger en se connectant aux machines de tests.

Le dilemne

Zabbix n'étant pas intégré avec puppet et la quantité de travail pour réaliser cette intégration étant significative, zabbix doit être configuré à la main. Une configuration manuelle de zabbix ne permet pas de tester les manifests puppet via un système d'integration continue parcequ'il doit être, par nature, entièrement automatisé.

Zabbix ne permet pas de faire de l'integration continue et l'integration continue dépend d'un outil de surveillance tel que zabbix.

Une solution

Je recommande que l'April change zabbix en faveur de nagios. L'existant est léger et peut être migré en quelques heures. Nagios intégré à puppet peut être utilisé sans modification pour l'intégration continue, sans développement.

En conclusion

J'ai beaucoup hésité a proposer ce changement et ce n'est qu'avec réticence que j'ouvre le débat. En pratique, entamer cette discussion bloque l'avancée de l'integration continue dans l'April. Mais l'alternative qui consiste a passer des jours et des jours à travailler à l'intégration de zabbix avec puppet est pire. Plus grave : elle impose du travail sur le long terme et mobilise une force de travail qui est hors de proportion avec les ressources de l'équipe.

Au début du mois de Novembre zabbix était configuré sur le vserver ephedrine sur ns1.april.org et monitorait, via ping uniquement, une partie des autres vservers se trouvant sur ns1.april.org et un de ceux qui se trouve sur pavot.april.org.

La configuration des zabbix n'a jamais été finalisée, mais elle n'était pas quasi-vierge.

Fin du HS.

Je suis tout à fait favorable à l'utilisation de Nagios.

Je connais aussi bien Nagios, que Zabbix ou BigBrother/Hobbit/Xymon. Je préfère zabbix. Mais si ça nous bloque Nagios, me convient très bien.

Quand je parle de Nagios, c'est pour désigner les logiciels de la famille Nagios. Je conseille l'utilisation d'icinga qui est un fork plus dynamique.

theo _ a écrit :

[...] C'est étonnant. De mémoire, on recevait des alertes pour de nombreuses choses, pas uniquement le ping.

La configuration des zabbix n'a jamais été finalisée, mais elle n'était pas quasi-vierge.

Tu as raison : il y avait 2 serveurs ( de mémoire ) qui avaient un template gnu/linux appliqué, ce qui impliquait plus d'alertes. Plus un check dns.

(06:50:51 PM) dachary: _aeris_: est-ce que tu es ok pour utiliser nagios à la place de zabbix ? 
(06:51:27 PM) _aeris_: je ne maîtrise ni l'un ni l'autre, donc pas d'avis =)

Pas d'avis, je ne connais sérieusement ni l'un ni l'autre.