Historiquement j’utilisais un seul server Nagios3 pour superviser ma production dont la configuration était
complètement générée par Puppet avec Naginator.
Cette solution bien que contraignante (difficulté à gérer les seuils spécifiques d’alerte par exemple,
appliances non puppetisée, etc ..) est vraiment puissante et me permets de ne jamais me soucier de la configuration du monitoring :
je suis sur à tout moment que tous les serveurs dans mon environnement de production sont monitorés
et que chaque service définis dans Puppet à les services Nagios associés.
Cependant mes besoins ont évolués et j’ai commencé à avoir des problématiques de monitoring distribué assez classique :
4 datacenters répartis entre l’Europe et les USA, des problèmes récurrents de réseau
qui provoquaient de nombreux faux-positifs et un ras le bol de mails trop intempestifs.
Je n’avais pas de soucis particuliers de performances : j’ai moins de 200 hosts et 2000 services.

J’ai essayé Shinken, vraiment. Y’a 2 ans une première fois puis ces derniers mois.
J’ai été obligé de le packager puisqu’aucun package Debian n’était proposé
et que tous nos serveurs sont déployés de manière unattended :
le script d’installation proposé n’était pas pour moi une solution envisageable.
Sur le papier Shinken était parfait :
* compatibilité de configuration avec Nagios
* support des directives spécifiques à Shinken dans Puppet avec Naginator
* support natif de distribution avec les realms ou poller_tag
* suport natif de la HA
* support natif de Livestatus
* une communauté sympas et des devs réactifs

Dans les faits et d’après mon expérience :
* la configuration n’est pas 100% interprétée de la même manière (mais les ajustements relativements triviaux)
* shinken prend énormément plus de RAM que nagios (même si Jean Gabès a pris le temps d’écrire un très long mail pour m’expliquer très clairement ce comportement)
* le plus important pour moi : l’ensemble n’est à mon humble avis pas assez stable / robuste dans mon cas d’usage : en cas de netsplit les démons n’arrivaient plus à se resynchroniser à la fin de l’outage, certains modules crashaient sans crier gare, des problèmes d’incompatibilité avec Pyro.

Je n’était pas assez confiant envers mon POC pour accepter de le mettre en production.

Pour être bien claire :
* Je continue de penser que Shinken sera à terme une des (sinon LA) solutions pour remplacer Nagios, mais il n’était pas encore prêt pour mes besoins.
* Certaines personnes font tourner Shinken en production, sur de grosses infras sans problèmes. Mon retour sur ce projet ne doit en aucun cas vous dissuader
de faire vos propres tests et de vous forger votre opinion.

J’ai du trouver une solution moins satisfaisante formellement mais qui repose sur des briques éprouvées.

Je suis donc partis sur l’ensemble des briques suivantes :
* Un server Nagios par datacenter pour le monitoring
* Puppet pour la gestion des configurations distribuée (il prend ici le rôle de l’arbiter de Shinken)
* Livestatus + Check_MK Multisite pour l’aggrégation des données

Nous utilisons énormément de Facts custom dans Puppet et nous avons donc
un Fact « $::hosting » qui nous indique dans quel datacenter se situe notre chaque host.
Afin de découper notre configuration entre chaque poller, j’utilise donc des targets dynamiques dans puppet pour les resources liées aux datacenter (hosts, services, hostescalation, serviceescalation):

Voici un exemple simplifié de ma définition d’host en Exported Resources :

        $puppet_conf_directory = '/etc/nagios3/conf.puppet.d'
        $host_directory = "$puppet_conf_directory/$::hosting"

        @@nagios_host { "$::fqdn" :
                tag           => 'nagios',
                address    => $::ipaddress_private,
                alias         => $::hostname,
                use           => "generic-host",
                notify        => Service[nagios3],
                target        => "$host_directory/$::fqdn-host.cfg",
        }

Toutes les resources communes à tous les pollers (contacts, contactgroups,
commands, timeperiods, etc…) sont générées dans un répertoire sourcé par tous les nagios
(ex: ‘/etc/nagios3/conf.puppet.d/common’).
Enfin dans le nagios.cfg je source pour chaque poller les dossiers des datacenters
que je souhaite monitorer depuis ce poller.

# Ex pour nagios1 : 
cfg_dir=/etc/nagios3/conf.puppet.d/common
cfg_dir=/etc/nagios3/conf.puppet.d/hosting1
# Pour nagios2 :
cfg_dir=/etc/nagios3/conf.puppet.d/common
cfg_dir=/etc/nagios3/conf.puppet.d/hosting2

J’ai pris le partis de ne pas utiliser les tags des exported resources :
ce la le permet d’avoir exactement les mêmes fichiers de configuration sur tous mes pollers dans /etc/nagios3/conf.puppet.d : seul nagios.cfg change entre les pollers.
En cas de soucis avec l’un de mes pollers, je peux très simplement ajouter le monitoring d’un autre datacenter en ajoutant l’inclusion d’un dossier en plus !
Cette configuration me permet donc d’avoir une supervision distribuée dont la configuration est homogène.

J’expliquerais dans un prochain article mon utilisation de Livestatus pour agréger l’ensemble des résultats de monitoring.

Original post of Fitzdsl Blog.Votez pour ce billet sur Planet Libre.