Centreon on Zwindler's Reflection

Superviser des appliances HPE StoreVirtual VSA (LeftHand) avec Nagios/Centron/Shinken

Tue, 08 Jan 2019 12:45:34 +0000

Superviser des Lefthand ?

Dans une vie antérieure (article dans mes tiroirs depuis fin 2015 a priori XD), j’ai eu à gérer, on premise, du stockage hautement disponible HPE VSA pour mes clusters VMware.

Si vous êtes ici, c’est sûrement parce que vous aussi, vous avez acheté des LeftHand (StoreVirtual P4000) et/ou des HPE VSA, et que vous voulez les superviser.

La plupart des tâches d’administration se font depuis la CMC (Centralized Management Console), mais clairement ce n’est pas hyper pratique. La section 7 du manuel StoreVirtual traite de la supervision en général : h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c04581885-1.pdf (lien mort, pas sauvegardé par Internet Archive).

Heureusement, la documentation explicite clairement qu’il est possible d’activer SNMP pour externaliser tout ça.

A noter, je n’ai pas pu m’empêcher de glousser en lisant cette petit phrase dans un manuel d’administration un peu plus ancien, qui dit que vous ne pouvez pas changer, ni même supprimer (#Sécurité), les communautés par défaut :

Section 7 du manuel d’administration http://www.hp.com/ctg/Manual/c01865545.pdf

Nagios / Centreon / Shinken

Pour superviser mes machines dans mes DC « on-premise », j’utilisais Centreon. Tout naturellement je me suis tourné vers Nagios Exchange pour voir s’il n’y avait pas déjà des gens qui avaient fait le travail.

2 plugins ont attirés mon attention :

Prérequis

Le plus récent et le plus téléchargé, check_lhc, nécessite le téléchargement de MIB. Je les avaient trouvé sur circitor (ex. www.circitor.fr/Mibs/Html/L/LEFTHAND-NETWORKS-NUS-COMMON-CLUSTERING-MIB.php), puis de les déposer dans votre serveur Nagios/Centreon/Shinken

/usr/share/snmp/mibs/

J’avais également trouvé des ressources sur le site d’HPE, mais comme ils passent leur temps à le refaire les 3 liens que j’avais sauvegardés sont maintenant HS. Voilà voilà.

En gros, ce que ça disait, c’est que les MIB sont contenues dans l’installeur, celui qui est utilisé pour instancier les VSA la première fois.

Fallait le savoir…

Configurer SNMP

Comme les deux plugins utilisent SNMP, on va… l’activer. #ThanksCaptainObvious.

Depuis la CMC, on peut donc configurer nos StoreVirtual pour qu’elles acceptent des connexions SNMP et configurer une communauté (voir le manuel d’admin, page 93). Clairement, ce n’est pas sorcier.

Dans le Management Group, on a un menu Event, dans lequel on peut configurer un serveur SMTP (pratique pour recevoir les mails qui m’informe que mon cluster est à plat et que mes données sont définitivement corrompues et que je peux aller pointer à Paul Emploi).

Et, SNMP.

Checker

Maintenant que vous avez activé SNMP (avec une communauté bien complexe, readonly et des restrictions IP à vos seuls serveurs de supervision, on est d’accord), on peut voir si ça marche.

Personnellement j’ai préféré check_lefthand, car la doc est plus fournie et les options plus nombreuses .

./check_lefthand.pl -H 10.10.10.16 -C hyperdifficultcommunity
Cowardly exiting, not instructed to check anything!
check_lefthand.pl -H -C [-t timeout] [-p port]
Additional Options:
--module-space
report the available space on each 'module' within a management group
--module-status
report on the various status elements for each 'module' within a management group
--volume-space
report the available space on each volume within a management group
--volume-status
report on the various status elements for each volume within a management group
--cluster-space
report the available space for each cluster within a management group
--cluster-status
report the status of each cluster within a management group

Les deux alertes que j’ai mises en place sont l’état du clusters, et le status de mes volumes (synchronisés ou pas entre les 2 salles).

centreon$ ./check_lefthand.pl -H 10.10.10.16 -C hyperdifficultcommunity --cluster-status
OK - mgmt group: MyAwesomeHPVSA 5/5 Cluster Managers Active.
centreon$ ./check_lefthand.pl -H 10.10.10.16 -C public --volume-status
OK - mgmt group: MyAwesomeHPVSA 4 Volumes with valid replication and Data Protection.

A noter, tout n’est pas parfait. Dans certains cas, j’ai remarqué que l’alerte ne se déclenchait pas quand des nœuds étaient DOWN, car le compteur « total » de nœuds décrémentait en même temps que les nœuds tombaient (ce qui est très bête…).

Mais c’est quand même un début :)

Bonus : Rage

Ouais, je sais…HPE VSA (maintenant HPe StoreVirtual VSA), quoi. L’alternative « géniale » de HPE à VSAN.

Ne me blâmez pas… A l’époque, on m’avait donné le choix entre 2 appliances physiques NetApps plus chères et même pas hautement disponibles (actif/passif) et donc les fameuses HPE VSA Storevirtual. Et puis sur le papier, ça paraissait robuste. C’est basé sur un produit éprouvé, les Lefthands (appliances physiques) et un OS Linux.

What could go wrong?

Maintenant que je ne m’en occupe plus, je peux dire que c’est grâce à ce superbe outil que j’aurai fais un week end non-stop quasiment sans dormir au téléphone avec des techs HPE et VMware de tout autour du monde (mais je me suis fait payer plus de 25 heures d’astreinte #youpi) parce que les nœuds tombaient les uns après les autres sans raison apparente.

Pour les curieux, c’était un problème de hotspare qui se mettait en veille et bloquaient les nodes, les uns après les autres, dès qu’une commande « refresh storage usage » était lancée par l’ESXi (automatique ou manuel).

C’est aussi mon record personnel du ticket support le plus longtemps, tout constructeur/éditeur confondu. Les chiffres sont impressionnants :

un mois pour trouver un workaround (désactiver les hotspares, #genious)
plus de 200 emails
5 mises à jours (dont 4 inutiles)
3 interventions le soir sur la prod
Et last but not least : 2 ans pour trouver le fix (alors que le problème était détecté puisqu’on savait qu’il suffisait de désactiver les hotspares).

DEUX… ANS…

Au final, je ne suis même pas vraiment sûr que le problème soit fixé.

Je ne suis plus sûr de rien, à part du niveau de compétence de HPE sur le sujet des serveurs et du stockage.

Mais qui peut les blâmer, ce n’est pas leur cœur de métier après tout. #ohwait

Configurer NSCA pour Centreon Engine

Tue, 21 Nov 2017 12:45:26 +0000

Petit rappel de ce qu’est NSCA

NSCA, pour Nagios Service Check Acceptor, est un couple de binaires serveur et client permettant de réaliser les checks passifs avec Nagios. Le check passif est à l’initiative du serveur supervisé, alors qu’a contrario le check actif est déclenché par le serveur superviseur.

Au delà de la question de philosophie (j’ai rencontré de fervents défenseurs du check passif avec que je suis plutôt pour ne pas faire confiance au serveur surveillé pour qu’il nous dise qu’il va mal), il y a clairement des cas d’usage où les checks passifs sont bien plus indiqués.

Si vous voulez aller plus loin sur le sujet actif vs passif, je vous propose d’aller lire l’article en Français de Olivier Jan, fondateur de Check My Website et figure assez connue de la supervision open source FR.

Bon alors pourquoi tu fais du NSCA ?

Un bon exemple de usecase où les checks passifs sont clairement indiqués sont les événements applicatifs. Pour une raison ou pour une autre, un traitement applicatif (par exemple de type batch) a échoué. Je pourrais aller vérifier régulièrement les traitements en erreur mais l’ordonnanceur de nagios ne me permet pas de faire un polling plus fin qu’une minute, et en plus la plupart du temps, je vérifierai juste que tout est OK pour rien.

En revanche, l’application, si elle est fiable, sait quand il y a eu une erreur et est capable de me le dire, uniquement quand cela arrive. Le check passif est dans ce cas parfaitement indiqué.

Dans le cadre de la migration de ma supervision d’un Centreon 2.4 vers un CES 3.3 (un article est à venir, je ne fais rien dans l’ordre…), il a été nécessaire de reconfigurer NSCA sur la nouvelle plateforme. La plateforme CES 3.3 étant basée sur un CentOS 6 ainsi que Centreon Engine et non plus Nagios directement, de nombreuses documentations ne sont plus à jour. Et pour cause, NSCA n’a pas pratiquement évolué depuis 2007 (une version sortie en 2011 et une mineure sortie de nulle part fin 2016).

Ce commentaire sur Nagios Exchange en est assez révélateur :

The NSCA addon has been ignored and neglected for years. For passive checks, try NRDP instead.

I can’t imagine why NSCA is still a featured plugin on the Nagios Exchange when it hasn’t received an update in over 3 years.

The NSCA addons work, but they are buggy, crash too often and will lead to false positives on your Nagios server.

The 2.9 branch and 2.7 branch are not compatible. The 2.7 branch is still in wide use due to these compatibility issues, but it hasn’t received an update since 1997. The 2.9 branch hasn’t received an update since 2012.

Ambiance.

Aparté compatibilité

Comme l’indique le commentaire ci dessus que je n’ai malheureusement pas lu, les branches 2.9 et 2.7 ne sont pas compatibles. Ne vous fatiguez pas à essayer de les faire communiquer, ça ne fonctionnera pas. Vous verrez les connexions arriver mais aucun message passer côte serveur de supervision.

Bon, il faut voir le bon côté des choses, ça me permet de vous offrir en fin d’article une superbe section debugging ;-).

Comment l’installer ?

On récupère les sources, directement depuis le serveur Centreon :

wget https://github.com/NagiosEnterprises/nsca/releases/download/nsca-2.9.2/nsca-2.9.2.tar.gz
tar xzf nsca-2.9.2.tar.gz
cd nsca-2.9.2
./configure --prefix=/usr/share/centreon/ --with-trusted-path=/bin:/sbin:/usr/bin:/usr/sbin:/usr/share/centreon/bin:/usr/lib/nagios/plugins
make all

Les sources sont partiellement compilées avec les nouveaux chemins par défauts de CES, qui n’ont plus rien avoir avec ceux de Nagios (historiques).

On copie le binaire « serveur » dans le dossier de Centreon Engine (pour rester cohérent avec l’ancien système de stockage des fichiers Nagios plus qu’autre chose, il peut être mis n’importe où).

cp src/nsca /usr/share/centreon/bin/

On n’utilise pas le fichier de configuration disponible dans sample-config/nsca.cfg car trop de paramètres ne sont plus en phase. Il est plus simple d’en créer directement un avec tous les bons paramètres :

cat > /etc/centreon-engine/nsca.cfg << EOF
log_facility=daemon
pid_file=/var/run/nsca.pid
server_port=5667
nsca_user=centreon-engine
nsca_group=centreon-engine
debug=0
command_file=/var/lib/centreon-engine/rw/centengine.cmd
alternate_dump_file=/var/lib/centreon-engine/rw/nsca.dump
aggregate_writes=0
append_to_file=0
max_packet_age=30
decryption_method=1
EOF

A noter, la encryption/decryption_method par défaut et l’absence de mot de passe font de cette solution quelque chose de très peu sécurisé. Je vous invite à consulter la page suivante pour plus de détails.

En revanche on peut utiliser la configuration par défaut pour avoir le client NSCA sur la machine (utile pour tester).

cp sample-config/send_nsca.cfg /etc/centreon-engine/send_nsca.cfg
chown centreon-engine:centreon-engine /etc/centreon-engine/send_nsca.cfg
cp src/send_nsca /usr/lib/nagios/plugins/
chown centreon-engine:centreon-engine /usr/lib/nagios/plugins/send_nsca

On créé ensuite un script de démarrage. On est encore sur System V et des scripts d’init car CES 3.3 n’est pas livré sur une CentOS 7 mais une 6. A noter, il est également possible de l’installer via xinetd si vous préférez ou que vous en avez l’habitude. Moi je préfère l’avoir comme un service à part.

cat /etc/init.d/nsca
#!/bin/sh
### BEGIN INIT INFO
# Provides: nsca
# Required-Start: $local_fs $remote_fs $syslog $named $network $time
# Required-Stop: $local_fs $remote_fs $syslog $named $network
# Should-Start:
# Should-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start/Stop the Nagios Service Check Acceptor (nsca) daemon
### END INIT INFO
DAEMON=/usr/share/centreon/bin/nsca
NAME=nsca
DESC="Nagios Service Check Acceptor"
CONF=/etc/centreon-engine/nsca.cfg
OPTS="--daemon -c $CONF"
PIDFILE="/var/run/nsca.pid"
. /etc/init.d/functions
test -f $DAEMON || exit 0
# support a default file
if [ -f /etc/default/nsca ]; then
. /etc/default/nsca
fi
case "$1" in
start)
echo "Starting $DESC" "$NAME"
daemon --pidfile $PIDFILE $DAEMON $OPTS
;;
stop)
echo "Stopping $DESC" "$NAME"
killproc -p $PIDFILE $NAME
;;
restart)
$0 stop
$0 start
;;
status)
status_of_proc -p $PIDFILE $DAEMON $NAME
;;
*)
echo "Usage: $N {start|stop|restart|status}"
exit 1
;;
esac
exit 0

On rend le script exécutable, on l’ajoute au démarrage, et on le lance :

chmod +x /etc/init.d/nsca
chkconfig --level 235 nsca on
/etc/init.d/nsca start

Test

Sur le serveur Centreon

Pour valider que tout fonctionne, on peut se créer un service nsca_test sur l’hôte par défaut (Centreon-Server). Ne pas oublier d’autoriser les checks passifs sur ce service dans sa configuration !

su - centreon-engine
echo -e "Centreon-Server\tnsca_test passif\t2\tNE PAS TENIR COMPTE" | /usr/lib/nagios/plugins/send_nsca -H 127.0.0.1 -c /etc/centreon-engine/send_nsca.cfg

Sur un client

Maintenant que notre test fonctionne, le mieux c’est quand même de tester en vrai que notre serveur superviser peut déclencher une alerte et que le serveur la récupère. Pour ce faire vous pouvez créer un petit script qui vous servira à valider que tout fonctionne.

cat /usr/lib/nagios/libexec/test_nsca.sh
#!/bin/bash
#test_nsca.sh
echo -e "srv_supervise\tmon_service_passif\t2\tmessage" | /usr/lib/nagios/libexec/send_nsca -H 200.140.20.186 -c /etc/nagios/send_nsca.cfg
su - nagios
/usr/lib/nagios/libexec/test_nsca.sh

Debugging

Et oui ! Des fois ça ne fonctionne pas… Lorsque côté client vous avez « 0 packet sent », pas la peine de se fatiguer, c’est côté client que ça coince dans ce cas là. Le format des séparateurs ou le nombre de champs n’est peut être pas le bon.

En revanche, si vous recevez « 1 data packet(s) sent to host successfully. », c’est que c’est bien parti et c’est côté serveur de supervision qu’il faut regarder.

J’ai retrouvé un article sur le support de Nagios qui donne quelques pistes, bien qu’elles soient light…

On peut commencer par demander à NSCA de loguer quelque chose. Oui parce que par défaut, le serveur NSCA ne logue rien du tout… Dans rsyslog.conf, ajouter daemon.debug pour /var/log/messages :

vi /etc/rsyslog.conf
[...]
*.info;mail.none;authpriv.none;cron.none;daemon.debug /var/log/messages

Dans la configuration de nsca, on peut aussi passer en mode debug (pas très bavard malheureusement).

cat /etc/centreon-engine/nsca.cfg
[...]
debug=1

Pour prise en compte, rechargez les deux démons :

service nsca restart
service rsyslog restart

Erreur de décalage de temps entre les serveurs

Par défaut, les paquets plus vieux de 30 secondes sont ignorés. Ceci peut poser problème dans le cas où les serveurs de temps ne sont pas à jour.

Côté client, on a le message suivant :

1 data packet(s) sent to host successfully.

Côté serveur, on a le message suivant dans /var/log/messages (si debug=1 et daemon.debug dans rsyslog.conf)

Nov 14 16:00:03 sup02 nsca[6786]: Handling the connection...
Nov 14 16:00:04 sup02 nsca[6786]: End of connection...

Alors qu’on devrait avoir :

Nov 14 15:51:14 sup02 nsca[1721]: Handling the connection...
Nov 14 15:51:15 sup02 nsca[1721]: SERVICE CHECK -> Host Name: 'srv_supervise', Service Description: 'mon_service_passif', Return Code: '2', Output: 'TEST TEST TEST DGE DGE DGE'
Nov 14 15:51:15 sup02 nsca[1721]: Attempting to write to nagios command pipe
Nov 14 15:51:15 sup02 nsca[1721]: End of connection...

Le paramètre à modifier dans ce cas là (même si le mieux serait de corriger les serveurs de temps…) est max_packet_age dont la valeur par défaut est 30. Vous pouvez la monter jusqu’à 900 (15 minutes) ou bien la positionner à 0 pour accepter tous les paquets, quelque soit leur age.

Monitorez le fait que les URLs bloquées sont bien bloquées par le proxy

Sat, 18 Nov 2017 12:45:25 +0000

Comment je vérifie que les sites bloqués par mon proxy sont bien bloqués ?

Il y a plein de raisons qui peuvent expliquer qu’un site non légitime soit bloqué sur un lieu de travail (par exemple). Et autant de raisons qui font que, parfois, les proxies ne bloquent pas bien des sites que vous aviez pourtant bloqués !

Pour tout ce qui est supervision des pages web, Nagios fourni le plugin check_http, dans les nagios-plugins (collection officielle de plugins), et qui permet de vérifier qu’une page web donnée est accessible (ou non).

Limitations

Cependant, il existe plusieurs cas où ce plugin ne « fonctionne pas » comme je le souhaite :

D’abord, dans le cas où l’URL checkée renvoie un 30x (redirection), le check_http considère que c’est bon et ne va pas chercher plus loin. Hors, il arrive que le site soit down au-delà de la redirection. Dans ce cas là, check_http ne nous notifie pas de l’échec.
Ensuite, dans le cas où vous voulez traverser un proxy pour vérifier si une page est accessible ou non comme dans mon introduction, vous ne pouvez pas spécifier si un code retour 40x est une bonne chose ou non. Dans tous les cas, avec check_http, un 40x sera considéré comme un WARNING, jamais comme un CRITICAL ou un OK.

Pour résoudre ces problèmes, j’ai donc réécris un petit script bash simple, permettant de résoudre tous les cas ci-dessus. Avec check_proxy_http_url, vous pouvez vérifier des URLs en spécifiant un proxy, suivre correctement les redirections (301 ou 302 par ex.) et spécifier si le fait qu’une page soit accessible (ou pas accessible) est une bonne chose ou non.

Installation

Le script est simplissime. Pour des raisons de facilité je me suis simplement appuyé sur un script bash et de wget, présents sur la plupart des serveurs par défaut. Il n’y a pas d’autres prérequis.

Dans un futur (plus ou moins) proche j’ajouterai également une compatibilité avec cURL, qui a tendance à le remplacer.

Usage

Là encore, j’ai fait au plus simple. Le script dispose d’un nombre limité d’arguments, permettant de réaliser les usecases indiqués précédemment.

/var/lib/nrpe/plugins/check_proxy_http_url.sh -u TARGET_URL [-p PROXY_ADDRESS:PROXY_PORT] [-r] [-v]

TARGET_URL : obligatoire - l’URL que vous souhaitez superviser. Par défaut, un code retour de type 200 induira un OK, un 4XX/5XX un CRITICAL
PROXY_ADDRESS & PROXY_PORT : optionnels - le hostname ou l’adresse de votre proxy, si nécessaire
-r : optionnel - permet d’inverser les codes retours de Nagios. Un code retour 200 induira un CRITICAL (URL qui est accessible alors qu’elle ne le devrait pas) et un 4XX/5XX induira un OK

Exemples

Vérifier que http://@IPsome_forbidden_website.com n’est pas accessible et renvoyer un CRITICAL sinon.

[root@lanhost ~]# /var/lib/nrpe/plugins/check_proxy_http_url.sh -u some_forbidden_website.com -r
OK: URL some_forbidden_website.com isn't available and it shouldn't - 403

Vérifier que http://@IPsome_allowed_website_that_isnt_accessible.com n’est pas accessible et renvoyer un CRITICAL sinon.

[root@lanhost ~]# /var/lib/nrpe/plugins/check_proxy_http_url.sh -p internal_proxy:8181 -u some_allowed_website_that_isnt_accessible.com
CRITICAL: URL some_allowed_website_that_isnt_accessible.com isn't available and it should - 403

Code source

Comme d’habitude avec mes plugins « Nagios compatibles », les sources sont disponibles sur Github à l’adresse suivante :

github.com/zwindler/check_proxy_http_url

Le lien pour Nagios Exchange est également disponible ici !

Mes autres plugins sont également disponibles sur le Github :

Impossible de faire disparaitre les hôtes après suppression d’un poller Centreon

Tue, 22 Aug 2017 11:45:21 +0000

Des hôtes qui n’existent plus sont toujours visible dans l’interface de Centreon

Je plante le décor : Vous avez une infrastructure supervisée avec Centreon. Cool :). Vous aviez des collecteurs distants (aka poller) et vous avez décidé de les supprimer finalement (je sais pas, imaginons que finalement le client décide d’annuler le projet par exemple, même si ça n’arrive jamais).

Et là, surprise. Vous n’aviez pas remarqué avant d’avoir définitivement supprimé la machine poller et toute sa configuration, mais les hôtes précédemment supervisés sont toujours visibles dans l’interface de Centreon, avec leur état en date de la dernière fois qu’un check a eu lieu, indéfiniment.

Ici, une capture d’écran du 17, avec des serveurs qui ont répondu la dernière fois le 16 !

Pourtant, ils n’existent plus dans votre configuration !! Tout est désactivé (ou supprimé). Vous ne voyez pas ce que vous pouvez faire de plus !

Back in time

Il faut déjà se rappeler comment marche Centreon, dans un premier temps.

Historiquement, Centreon se basait sur Nagios. Et Nagios est un programme des années 2000, monolithique, codé en C, et qui ne dispose pas, par conception, de stockage pour historiser les états des serveurs surveillés.

Ça peut paraître fou aujourd’hui, mais Nagios n’a pas de base de données ! L’ensemble des états à un moment donné des serveurs était (est) stocké dans un fichier plat, tout le temps réécrit et que vous pouvez trouver dans un sous répertoire de nagios (var/status.log).

Les premières lignes du status.log

Cette méthode de fonctionnement « simple » (l’interface HTTP en CGI a juste à lire le fichier plat pour afficher les états des serveurs) est catastrophique pour les performances. J’ai vu des contextes où ce fichier était stocké en RAM via un ramdisk pour essayer de supporter un peu mieux la charge…

Conscients du manque qu’occasionne l’absence de base de données pour historiser l’état des serveurs au delà de leur état instantané, les gens de chez Nagios ont créé un connecteur externe (le « broker » ndo2db) qui permet de transmettre une copie des résultats à une base de données (MySQL le plus souvent mais je me demande si il n’y a pas aussi Oracle ?). Le modèle de la base NDO est accessible sur le site de Nagios.

Où je veux en venir avec tout ça ?

Ce broker externe a été un peu détourné de son but initial par plusieurs projets, dont Centreon, qui l’a utilisé en tant que source principale pour afficher les status des serveurs. Utiliser la base NDO comme source principale a un 2ème avantage : il est possible d’agréger plusieurs serveur Nagios dans une même base de données. On a donc la possibilité de gérer plusieurs serveur depuis une même interface => c’est le principe utilisé par les collecteurs de Centreon.

Le collecteur par défaut (Central) est composé du cœur de Centreon lui même gérant l’interface et la configuration de tous les pollers ainsi que de la base NDO et du connecteur NDO2DB. Les pollers eux ne sont que des moteurs Nagios, leur configuration « Nagios » est générée par le Central, et les données sont collectées via ndomod (le connecteur qui envoie les données sur le ndo2db).
[Avant de me prendre la remarque, ce que je dis ici n’est plus tout à fait vrai car Centreon et réécrit depuis longtemps tous ces composants, notamment centreon-broker pour ndo2db, centreon-engine pour le moteur Nagios. Mais le principe reste le même]

Comme la base contenant la configuration des pollers est distincte de la base NDO, il est « normal » que l’inactivation d’un poller n’ait pas d’impact sur le contenu de la base NDO. NDO ne stocke des données venant des serveurs Nagios, au fil de l’eau, et n’a aucune connaissance de la configuration dans Centreon…

La vraie méthode

Si vous n’avez pas encore tout pété comme je le décris dans le premier paragraphe, vous serez content d’apprendre qu’il existe une meilleure méthode. La « vraie » méthode (à moins qu’il y en ait encore une autre que je ne connais pas) est décrite dans ce post que j’ai retrouvé sur le forum Monitoring-fr (lien mort, pas sauvegardé par Internet Archive).

David GUENAULT (un des piliers de Monitoring-fr et qui a contribué sur plusieurs projets) nous donne la solution :

bah en fait c’est tout simple
tu réaffecte tes hôtes sur le poller principal :

configuration->hosts puis filtre sur le poller que tu veux enlever

selection des hôtes

dans la combo => massive change

dans la combo monitored from => tu selectionne ton central et validation

tu supprimes ensuite le poller dans l’interface de centreon :

tu supprime ta config ndo relative au poller que tu veux enlever : configuration -> centreon -> ndomod

tu supprime le poller dans : configuration->centreon->pollers

tu pousses ta configuration : configuration -> nagios -> generate

Bon et si c’est trop tard ?

Mais si vous êtes sur cet article c’est peut être que c’est déjà trop tard et que vous n’avez plus moyen de réaliser la procédure ci-dessus ?

Et bien là, pas le choix. Il va falloir aller bidouiller la base de données NDO !

Le plus simple est de se connecter directement via le shell mysql depuis votre serveur Central. Dans la base de données NDO, on peut donc chercher les instances existantes :

select * from nagios_instances;
+-------------+---------------+----------------------+
| instance_id | instance_name | instance_description |
+-------------+---------------+----------------------+
| 1 | Central | |
| 3 | Poller1 | |
| 4 | Poller2 | |
| 5 | Poller3 | |
+-------------+---------------+----------------------+

Dans mon cas, c’est Poller1 que j’ai supprimé. Pour essayer de ne pas trop faire n’importe quoi, je préfère toujours regarde un peu ce que je compte modifier avant de le faire ;-)

Je liste tous les objets de Nagios, puis je compare avec ceux de mon instance 3.

SELECT count(*) FROM nagios_objects;
+----------+
| count(*) |
+----------+
| 11820 |
+----------+
1 row in set (0.00 sec)
SELECT count(*) FROM nagios_objects where instance_id = 3;
+----------+
| count(*) |
+----------+
| 815 |
+----------+
1 row in set (0.00 sec)

Connaissant mon infra, cela parait cohérent. Le Poller1 est un petit poller peu chargé. Je peux donc utiliser ma baguette magique : on a de la chance, NDO prévoit un « flag » is_active qui permet d’activer ou non un objet. Et il se trouve que Centreon gère correctement ce flag. Pour cacher nos hôtes fantômes dans Centreon, il suffit juste de les désactiver avec la commande suivante :

UPDATE nagios_objects SET is_active=0 WHERE instance_id = 3;

Normalement c’est quasi-instantané. Tous les hôtes précédemment liés au Poller1 doivent disparaître de l’interface.

Et la même en un peu plus chirurgical :

select object_id,instance_id,name1,is_active from nagios_objects where name1 like &quot;VIEUX_SERVEUR_OUBLIE_HS&quot;;
+-----------+-------------+-------------------------+-----------+
| object_id | instance_id | name1 | is_active |
+-----------+-------------+-------------------------+-----------+
| 6462 | 4 | VIEUX_SERVEUR_OUBLIE_HS | 1 |
| 6472 | 4 | VIEUX_SERVEUR_OUBLIE_HS | 1 |
+-----------+-------------+-------------------------+-----------+
UPDATE nagios_objects SET is_active=0 where name1 like &quot;VIEUX_SERVEUR_OUBLIE_HS&quot;;
Query OK, 2 rows affected (0.01 sec)
Rows matched: 2 Changed: 2 Warnings: 0

« J’aime beaucoup les zèbres, les rayures sont bien parallèles. »

J’ai eu le plaisir récemment de ré-écouter le sketch de Pierre Desproges : « Le maniaque ». Voilà la toute première phrase du sketch :

« Je ne suis pas à proprement parler ce qu’on appelle un maniaque. Simplement j’aime que tout brille et que tout soit bien rangé. »

Si vous non plus, vous ne pouvez pas vous résoudre à laisser trainer dans NDO des milliers d’objets, certes inactivés, mais toujours bien présents, cachés sous le tapis, la suite de cet article est pour vous (ou si vous êtes simplement curieux).

Pour descendre un peu plus dans les arcanes de NDO, je vous propose de regarder un peu ce qu’on peut trouver avec les requêtes suivantes :

select host_id,instance_id,display_name
from nagios_hosts
where instance_id != 1 limit 10;
+---------+-------------+--------------------+
| host_id | instance_id | display_name |
+---------+-------------+--------------------+
| 32149 | 2 | AAAAAA-HHHHHH01 |
| 32157 | 2 | AAAAAA-DADADADAD02 |
| 32150 | 2 | AAAAAA-DAD02 |
| 32146 | 2 | AAAAAA-GGGG |
| 32151 | 2 | AAAAAA-DDDDDA |
| 32152 | 2 | AAAAAA-DDDDDB |
| 32153 | 2 | AAAAAA-EEEE02 |
| 32154 | 2 | AAAAAA-FFFFFFF02 |
| 32155 | 2 | AAAAAA-FFFFFF02 |
| 32156 | 2 | AAAAAA-UUUUUUUUU01 |
+---------+-------------+--------------------+
10 rows in set (0.00 sec)
select object_id,instance_id,name1,name2,is_active from nagios_objects where instance_id != 1 limit 10;
+-----------+-------------+------------------+-------+-----------+
| object_id | instance_id | name1 | name2 | is_active |
+-----------+-------------+------------------+-------+-----------+
| 3307 | 0 | XXXXXXXXXX_ILO | ping | 0 |
| 5365 | 3 | check_icmp | NULL | 0 |
| 5366 | 3 | AAAAAA-CCC01 | NULL | 0 |
| 5367 | 3 | 24x7 | NULL | 0 |
| 5368 | 3 | AAAAAA-BBBBBA | NULL | 0 |
| 5369 | 3 | AAAAAA-BBBBBB | NULL | 0 |
| 5370 | 3 | AAAAAA-AAA | NULL | 0 |
| 5371 | 3 | AAAAAA-SAVE | NULL | 0 |
| 5372 | 3 | AAAAAA-SGBD01 | NULL | 0 |
| 5373 | 3 | AAAAAA-VMOTION01 | NULL | 0 |
+-----------+-------------+------------------+-------+-----------+
10 rows in set (0.01 sec)
select service_id,host_object_id,instance_id,display_name
from nagios_services
where instance_id != 1 limit 10;
+------------+----------------+-------------+------------------+
| service_id | host_object_id | instance_id | display_name |
+------------+----------------+-------------+------------------+
| 213526 | 4686 | 2 | BasculeClusterHA |
| 213527 | 4686 | 2 | ping |
| 213528 | 4687 | 2 | BasculeClusterHA |
| 213529 | 4687 | 2 | ping |
| 213530 | 4688 | 2 | ping |
| 213678 | 4669 | 2 | /appli |
| 213531 | 4689 | 2 | ping |
| 213532 | 4700 | 2 | ping |
| 213533 | 4703 | 2 | ping |
| 213534 | 4704 | 2 | ping |
+------------+----------------+-------------+------------------+
10 rows in set (0.00 sec)
select nagios_hosts.display_name,nagios_services.display_name,nagios_services.instance_id
from nagios_hosts,nagios_objects,nagios_services
where nagios_hosts.host_object_id = nagios_objects.object_id
and nagios_services.host_object_id = nagios_objects.object_id
and nagios_services.host_object_id in
(select host_object_id from nagios_hosts where instance_id = 3) limit 10;
+-----------------+-------------------------------+-------------+
| display_name | display_name | instance_id |
+-----------------+-------------------------------+-------------+
| SRV | BasculeClusterHA | 3 |
| SRV | check_http_aaaa | 3 |
| SRV | check_mountpoint_cifs_log | 3 |
| SRV | check_mountpoint_cifs_spl | 3 |
| SRV | ping_lan | 3 |
| SRV2 | BasculeClusterHA | 3 |
| SRV2 | ping_lan | 3 |
| SRV3 | BasculeClusterHA | 3 |
| SRV3 | ping_lan | 3 |
| ILO | ping_lan | 3 |
+-----------------+-------------------------------+-------------+
10 rows in set (0.01 sec)

[Aparté]Je pense qu’il faut que je trouve un module WordPress pour pseudonymiser les données automatiquement, je me fatiguerais moins à changer le nom des serveurs…[/Aparté]

Comme vous pouvez le constater, il y en a partout : c’est terrible !

DELETE FROM nagios_hosts WHERE instance_id =3;
DELETE FROM nagios_services WHERE instance_id =3;
DELETE FROM nagios_hostgroups WHERE instance_id =3;
DELETE FROM nagios_servicegroups WHERE instance_id =3;
DELETE FROM nagios_objects WHERE instance_id =3;

check_emc_rlp : supervision des LUNs dans le RLP sur baies VNX EMC²

Tue, 25 Apr 2017 12:00:51 +0000

Dans la série …

… plugins pour les outils de supervision Nagios(r) like et « Nagios(r) compatibles » (Icinga, Naemon, Shinken, …), je met à disposition un script que j’ai écris il y a quelques années et qui permet de vérifier et de grapher que vous disposez toujours des LUNs dans le RLP (Reserved LUN Pool). Je l’ai appelé sobrement check_emc_rlp et j’en parle aussi dans cet article à propos de NaviSecCli.

Mon problème initial était que j’avais plusieurs fois eu mes snapshots bloqués lors de l’utilisation un peu trop intensive du LUN source. Il n’y avait plus de place sur les LUNs dans le RLP, ce qui a pour effet de bloquer le snapshot et donc la base de préproduction que j’avais dessus. Un petit script qui vérifie qu’il y a toujours au moins 1 LUN non utilisé par LUN snapshoté permet de garder un peu de marge avant plantage.

Voilà ce que donne ce check_emc_rlp une fois mis en place dans Centreon :

Le script nous informe qu’il reste suffisamment de LUN dans le RLP lorsqu’il y a des snapshots actifs

La courbe de performance (PERFDATA Nagios) indique ici qu’il reste 3 LUN par LUN snapshoté (12 en fait en tout), et qu’on remonte à 6 par LUN à minuit (moment où on rafraichit notre préproduction et que les snapshots se vident)

La vue agrégée avec à la fois le nombre de LUN disponibles dans le RLP ainsi que le remplissage des LUN utilisés pour stocker le différentiel, par LUN snapshoté. Ce qui est intéressant ici c’est qu’on voit bien l’évolution du remplissage et le moment où la baie décide qu’elle a besoin d’un nouveau LUN en provenance du RLP

Comme d’habitude pour le téléchargement et la documentation, c’est sur Nagios Exchange et Github que ça se passe.

Pour rappel, vous trouverez aussi mes autres plugins Nagios dans le même repository Github.

Superviser des onduleurs/UPS avec Nagios/Centreon et SNMP

Tue, 17 Jan 2017 13:00:52 +0000

Être alerté par l’onduleur en SNMP

Il n’est pas rare que les onduleurs (ou Uninterrupted Power Supply chez nos amis anglosaxons), même sans être très haut de gamme, disposent de sortie Ethernet permettant de superviser l’état de l’onduleur, sa charge, …

Généralement, ce genre d’onduleur est également livré avec des clients propriétaires qui vous permettent de configurer la partie réseau de l’onduleur, puis ensuite de définir des alertes, voire des actions à réaliser lorsque l’onduleur commence à se décharger. Cependant, dans un environnement un tant soit peu industrialisé, ce genre d’outil est rarement pratique :

Il y a généralement déjà un outil de supervision en place, et en ajouter un va à l’encontre de l’efficacité pour les équipes support. Des consoles de supervision doivent être installés sur les postes des administrateur.
Les agents pour éteindre les serveurs alimentés doivent être installés (ce qui induit une tâche d’exploitation/maintenance supplémentaire), parfois en s’appuyant sur des versions hors d’age de Java comme dépendance, et avec bien peu de support une fois que le produit est chez vous.

Heureusement, la plupart des onduleurs exposent également une MIB SNMP standard, que vous pouvez donc très simplement ajouter pour réaliser vous même votre propre supervision. Et même pourquoi pas votre propre agent d’extinction, en se basant sur un script ainsi qu’un agent déjà présent sur les machines pour la supervision (NSClient/NRPE pour moi).

Pour trouver cette MIB (.1.3.6.1.4.1.21111.1.1, originalement nommée UPS), j’ai tout simplement utiliser un snmpwalk sous Unix en me connectant à l’adresse IP de l’onduleur après configuration. Sous Windows, on peut aussi utiliser un utilitaire graphique pour faire la même chose, notamment avec iReasoning MIB Browser qui nous donne également quelques informations sur les indicateurs disponibles.

MIB Browser donne des informations sur la MIB de manière graphique, ce qui peut être plus lisible qu’un simple snmpwalk

Quoi surveiller ?

Les indicateurs de la MIB UPS qui m’ont parus les plus opportuns à surveiller sont les suivants :

upsBatStatus (.1.3.6.1.4.1.21111.1.1.3.1.0) : L’état de la batterie qui peut être chargé ou en cours de déchargement. Tout ce qui n’est pas 2 est inquiétant.
upsBatEstChargeRemaining (.1.3.6.1.4.1.21111.1.1.3.4.0) : L’estimation de la charge restant de la batterie en %age. Si on descend sous 90% c’est que l’onduleur se décharge et que ce n’est pas une microcoupure !
upsBatEstMinutesRemaining (.1.3.6.1.4.1.21111.1.1.3.3.0) : L’estimation du temps restant avant que la batterie soit épuisée. Je trouve cet indicateur pratique pour 2 raisons
- On peut lancer des actions d’urgence (ssh + shutdown sur tous les linux) à partir d’un certain temps avant l’épuisement plutôt qu’un pourcentage, car on peut estimer que 5 minutes avant l’échéance, on aura plus le temps de rétablir avant coupure. Ce qui est plus difficile à fixer en pourcentage.
- On peut éventuellement détecter un problème sur les batteries ou sur la charge de l’onduleur si en fonctionnement normal (sur secteur) on se retrouve avec un temps de charge trop bas.
upsBatSecondsOnBattery (.1.3.6.1.4.1.21111.1.1.3.2.0) : Le nombre de secondes depuis que l’onduleur est sur batterie et n’est donc plus sur secteur. Si on dépasse 0, c’est mauvais signe mais pour éviter les alertes intempestives j’ai mis 2.

Et comme je suis sympa, je vous passe la configuration Nagios/Centreon (ou tout autre produit compatible) associée qui vous permettra d’obtenir les indicateurs en question sans effort. Enjoy !

define command {
command_name check_snmp
command_line $USER1$/check_snmp -H $HOSTADDRESS$ -o $ARG1$ -w $ARG2$ -c $ARG3$
}
define service {
service_description Template_par_défaut_pour_tous_les_serivces
name generic-service
contacts generic-contact
check_period 24x7
notification_period 24x7
max_check_attempts 5
check_interval 5
retry_interval 5
notification_interval 15
notification_options w,u,c
first_notification_delay 0
register 0
notifications_enabled 1
}
define service {
service_description 2_tentatives_et_interval_de_5_minutes_en_24_7
name 2retry_5min_24x7
check_period 24x7
max_check_attempts 2
check_interval 5
retry_interval 5
notification_interval 5
register 0
use generic-service
}
define service {
service_description Check_SNMP_upsBatStatus
name snmp_upsBatStatus
check_command check_snmp!.1.3.6.1.4.1.21111.1.1.3.1.0!2!2
register 0
use 2retry-5min-24x7
}
define service {
service_description Check_SNMP_upsBatEstChargeRemaining
name snmp_upsBatEstChargeRemaining
check_command check_snmp!.1.3.6.1.4.1.21111.1.1.3.4.0!90:!80:
register 0
use 2retry-5min-24x7
}
define service {
service_description Check_SNMP_upsBatEstMinutesRemaining
name snmp_upsBatEstMinutesRemaining
check_command check_snmp!.1.3.6.1.4.1.21111.1.1.3.3.0!30:!20:
register 0
use 2retry-5min-24x7
}
define service {
service_description Check_SNMP_upsBatSecondsOnBattery
name snmp_upsBatSecondsOnBattery
check_command check_snmp!.1.3.6.1.4.1.21111.1.1.3.2.0!2!2
register 0
use 2retry-5min-24x7
}

Module Ansible ansible-module-clapi : automatiser la configuration dans Centreon

Tue, 20 Dec 2016 13:00:49 +0000

Avant de parler de ansible-module-clapi

Cet article fait parti d’une suite d’articles ayant trait à l’automatisation de la configuration de la supervision Centreon à l’aide de CLAPI et d’Ansible, dont 2 que j’avais lu sur monitoring-fr. Dans l’article précédent, j’avais montré comment aller encore un peu plus loin que ce que Cédric Temple nous avait présenté.

A la fin de l’article, j’introduisais le fait qu’Ansible n’est pas seulement un outil permettant d’exécuter des tâches. Ansible est surtout un gestionnaire de configuration (comme Puppet, Salt, …).

Ansible is the simplest way to automate apps and IT infrastructure. Application Deployment + Configuration Management + Continuous Delivery.

Le but est de garantir qu’un ensemble de serveurs donnés, on a toujours la même configuration.

Si on utilise Ansible de cet manière, le playbook n’a plus vocation a être utilisé « one shot » après installation d’un serveur. La gestion de la configuration de supervision devient un sous ensemble des configurations par défaut qui sont régulièrement vérifiées. Les playbooks qui définissent le SI sur l’ensemble des serveurs pour s’assurer qu’ils sont tous « conformes », tout est automatique et on élimine ainsi le risque d’erreurs humaines (type « oublis » ou « suppression accidentelle »).

Quelle conséquence sur nos playbooks ?

Car bien entendu, cela demande un peu plus de travail et de réflexion.

Les exécutions multiples

Si on exécute plusieurs fois le même playbook sur un serveur, -il faut impérativement que les commandes de ce playbook n’aient aucune incidence sur l’état du serveur si celui ci est déjà correctement configuré.

J’insiste… La modification ne doit ce faire que si nécessaire. Dans le langage Ansible, on dit d’une commande qu’elle est idempotent. Retenez bien, c’est important ;-).

Prenons pour exemple l’ajout d’une ligne dans le fichier /etc/sudoers pour permettre à notre client NRPE d’avoir le droit de réaliser un sudo pour avoir l’exhaustivité des informations renvoyées par multipath. On pourrait « naïvement » réaliser la tâche suivante dans Ansible de la façon suivante :

---
- hosts: all
tasks:
- shell: 'echo 'nrpe ALL = NOPASSWD: /sbin/multipath' >> /etc/sudoers'

Ce playbook fonctionnerait parfaitement.

Vraiment ?

Pour autant, à chaque exécution du playbook, une ligne sera ajoutée dans chaque serveur et on se retrouvera potentiellement avec des effets de bords à force de modifications successives.

On peut repérer ces changements à l’aide du récapitulatif en fin d’exécution qui serait toujours en changed.

PLAY RECAP *********************************************************************
srv-nouveau-01 : ok=11 changed=1 unreachable=0 failed=0

En fait, il est recommandé d’éviter d’utiliser les modules shell et command d’Ansible lorsqu’il existe des modules pour réaliser la même action. Typiquement dans ce cas là, l’idéal sera plutôt d’utiliser le module lineinfile, qui permet de s’assurer qu’une ligne bien précise est présente ou non, et de ne surtout rien faire (et donc ne rien modifier) si la ligne est déjà présente.

---
- hosts: all
tasks:
- lineinfile: 'dest=/etc/sudoers state=present line='nrpe ALL = NOPASSWD: /usr/sbin/pvs, /sbin/multipath''

Pour vérifier que votre playbook est idempotent, le plus simple est donc de lancer plusieurs fois un même playbook et de vérifier que le résultat à la seconde exécution est bien du type :

PLAY RECAP *********************************************************************
srv-nouveau-01 : ok=12 changed=0 unreachable=0 failed=0

Les erreurs

Il ne faut pas non plus que les commandes renvoient un code erreur lorsqu’elles s’exécutent pour la 2ème fois. Auquel cas, l’exécution du playbook sera arrêtée en cours de route.

Si j’exécute une première fois le playbook centreon_add_host.yml, j’obtiendrais le retour suivant.

TASK [monitor : centreon add host] *********************************************
changed: [srv-nouveau-01 -> superviseur.company.lan]

Tout va bien, mon hôte apparaît dans Centreon. Par contre, si je l’exécute une seconde fois …

TASK [monitor : centreon add host] *********************************************
fatal: [srv-nouveau-01 -> superviseur.company.lan]: FAILED! => {'changed': true, 'cmd': '/usr/bin/centreon -u admin -p admin -o HOST -a add -v \'srv-nouveau-01;srv-nouveau-01;192.168.1.12;generic-host;central;Ping_LAN\'', 'delta': '0:00:00.098198', 'end': '2016-07-25 17:17:01.268410', 'failed': true, 'rc': 1, 'start': '2016-07-25 17:17:01.170212', 'stderr': '', 'stdout': 'Object already exists (srv-nouveau-01)', 'stdout_lines': ['Object already exists (srv-nouveau-01)'], 'warnings': []}

Ignorer les erreurs

La méthode la plus simple pour gérer ce problème serait d’ignorer les erreurs. Ici CLAPI ne renvoie une erreur que pour m’informer que l’hôte existe déjà. Donc la gestion des erreurs et ici l’ajout multiple d’un même hôte est correctement géré par CLAPI.

Ansible le permet à l’aide de l’option ignore_errors: True. Dans ce cas là, l’exécution de la commande CLAPI qui renvoie une erreur sera ignoré dans le cas où l’hôte est déjà présent.

Mais la solution n’est pas satisfaisante : on peut se retrouver à masquer de vraies erreurs. Par exemple, si je n’ai pas fourni le bon chemin d’accès au binaire, l’erreur sera cachée et je ne saurai pas que mon playbook ne fonctionne jamais correctement. On peut imaginer plein d’autres cas d’erreurs qui nous laisseraient penser que l’ajout d’hôte se fait bien alors qu’en fait l’erreur est juste masquée.

A l’inverse, on peut trouver des cas où masquer l’erreur peut être légitime. Vous pouvez donc aller voir ici pour plus de renseignements.

Tester préalablement la présence de l’hôte

Toujours dans l’esprit idempotent, le mieux est donc de vérifier préalablement que le serveur n’est pas déjà renseigné avant de réaliser l’action d’ajout dans Centreon.

Malheureusement, à date, il n’existe pas de fonction dans CLAPI permettant de faire une recherche dans un seul hôte. Je le leur soufflerais peut être ;-). En attendant, on peut quand même s’en sortir grâce à la fonction show qui affiche une liste de tous les serveurs et un grep.

En fonction de la présence ou non de la ligne, on obtiendra un code retour de 0 ou 1, ce qui nous permet de valider la présence ou non du serveur.

- name: centreon check presence
shell: /usr/bin/centreon -u '{{ clapi_username }}' -p '{{ clapi_password }}' -o HOST -a show | grep '{{ inventory_hostname }};' >/dev/null
delegate_to: '{{ centreon_poller }}'
register: centreon_output
- name: centreon add host
shell: /usr/bin/centreon -u '{{ clapi_username }}' -p '{{ clapi_password }}' -o HOST -a add -v '{{ inventory_hostname }};{{ inventory_hostname }};{{ ansible_default_ipv4.address }};generic-host;{{ centreon_poller }};Ping_LAN'
delegate_to: '{{ centreon_poller }}'
when: centreon_output.rc != 0

Cette solution fonctionne mais est loin d’être optimale. D’abord, elle se base sur grep, un binaire externe à CLAPI, pour valider la présence du serveur. Ça peut ne pas marcher à tous les coups !

Ensuite, le module shell à la fâcheuse caractéristique de ne pas être idempotent (c’est une obsession). A chaque exécution, Ansible considérera que le simple fait d’exécuter la commande change le système et affichera toujours « changed » même quand en réalité vos serveurs n’auront pas été modifiés !

PLAY RECAP *********************************************************************
srv-nouveau-01 : ok=10 changed=1 unreachable=0 failed=0

Avec shell il n’y a pas vraiment de parade au niveau Ansible. L’idéal serait donc pouvoir disposer d’un module Ansible capable d’interagir avec CLAPI tout en étant idempotent. #Teasing ;-)

Créer un nouveau module Ansible

Heureusement il est très facile de créer un nouveau module dans Ansible. Un exemple est proposé sur le site officiel avec des guides pour la proposition de module pour ajout dans les « extra modules ». Et j’ai également pas mal utilisé ce site pour me guider (blog.toast38coza.me, lien mort pas sauvegardé dans Internet Archive).

J’ai donc développé pour mon usage personnel des modules Ansible qui utilisent CLAPI et qui permettent pour l’instant de :

ajouter/supprimer un hôte
ajouter/supprimer des templates d’hôtes à un hôte
ajouter/supprimer un groupe d’hôtes
ajouter/supprimer des serveurs dans un groupe d’hôtes
régénérer la configuration et redémarrer un poller pour prise en compte des modifications

Et le code est disponible ici sur mon Github dans le projet ansible-module-clapi sous licence GPLv3.

Une fois les sources récupérées, vous pouvez exécuter ces modules Ansible complémentaires en créant un dossier librairie au même niveau que vos playbooks et en collant les fichiers Python du dépôt.

Un dossier test_suite contient le fichier hosts de cet article, le dossier group_vars avec les variables par groupes, ainsi qu’un playbook de test qui réalisera les actions suivantes :

ajouter un hôte dans centreon
supprimer ce même hôte de centreon
le resupprimer pour vérifier que la suppression d’un hôte déjà supprimé ne provoque pas d’erreur car l’hôte n’existe plus
supprimer un groupe testgroup qui n’existe pas pour voir si une erreur est renvoyée
ajouter le groupe testgroup
ajouter le groupe testgroup pour voir si cela génère une erreur à la 2ème exécution
ajouter l’hôte au groupe testgroup
ajouter un template à l’hôte
si un template d’hôte a été ajouté (oui, on vient de le faire)
- déclencher un « handler » => appliquer à l’hôte l’ensemble des templates de services liés au template d’hôte
et si n’importe laquelle de ces actions a provoqué une modification sur la base de Centreon (toutes en réalité)
- déclencher un « handler » => régénérer la configuration et redémarrer le moteur

Conclusion

Ceci vous permet d’avoir une vue d’ensemble des fonctionnalités disponibles pour l’instant. Ce n’est bien entendu qu’un début et je continuerai d’ajouter des fonctionnalités à partir de l’API CLAPI qui propose beaucoup plus de fonctionnalités.

Pour autant, ce module me permet aujourd’hui automatiser complètement l’ajout et la suppression des hôtes dans mon serveur Centreon. Actuellement pratiquement 120 serveurs sont gérés de cette manière :

J’attends bien entendu vos remarques, que ce soit sur le blog ou directement sur Github, avec impatience !

Automatisation de la supervision avec Centreon et Ansible (3)

Wed, 07 Dec 2016 13:00:47 +0000

Articles précédents sur Centreon et Ansible

Cet article fait suite aux deux articles rédigés en mai 2015 par Cédric Temple (ici et ici) qui donnent des pistes pour automatiser l’ajout de nœuds à superviser dans un console Centreon grâce à Ansible et CLAPI.

Pour ceux qui ne connaissent pas Ansible, je vous invite fortement à vous documenter sur cet outil de déploiement et de gestion de configuration très complet et qui bénéficie en ce moment d’un fort engouement, surtout depuis qu’Ansible a été racheté par RedHat ;-).

Et pour ceux qui ne connaissent pas CLAPI, il s’agit d’une API mise à disposition avec Centreon. Elle est installée par défaut dans les dernières versions. Elle permet de réaliser la totalité des opérations pouvant être faites depuis la console web en ligne de commande.

Les deux articles sur Monitoring-fr que je cite au début sont une bonne base pour appréhender ces deux sujets. Pour autant, on peut encore aller un peu plus loin et c’est pourquoi je vous propose de repartir de là où s’arrête l’article précédent.

L’exemple de l’ajout de l’hôte

A la fin de l’article précédent, on sait donc :

installer automatiquement les clients de supervision sur un nouvel hôte
et réaliser de manière unitaire via Ansible et des playbooks l’ajout et la modification d’hôtes dans Centreon.

J’aimerai revenir sur l’ajout d’hôtes dans Centreon. Pour reprendre l’exemple du playbook d’ajout d’hôtes de Cédric :

cat centreon_add_host.yml
- name: centreon add host
shell: /usr/share/centreon/www/modules/centreon-clapi/core/centreon -u admin -p admin -o HOST -a add -v '{{ inventory_hostname }};{{ inventory_hostname }};{{ ansible_default_ipv4.address }};generic-host;central;ALL_HOST'
delegate_to: superviseur.company.lan

Et voici le fichier d’inventaire dans lequel on déclare l’ensemble de nos serveurs, triés par groupes.

cat /etc/ansible/hosts #fichier hosts d'Ansible
#ne pas confondre avec le hosts d'un serveur Linux
[serveurs-centreon]
superviseur.company.lan
pollerprod.company.lan
[serveurs-prod]
srv-prod-01
srv-prod-02
[serveurs-rect]
srv-rect-01
srv-rect-02
[nouveaux]
srv-nouveau-01
srv-nouveau-02
[serveurs-linux:children]
serveurs-prod
serveurs-rect
nouveaux

Dans cet exemple simple, la première chose qu’on se dit si on regarde un peu rapidement, c’est qu’on aurait pu réaliser cet ajout à la main (ou via un script) avec CLAPI.

Le gain apporté par Ansible se situe « seulement » dans l’apport des variables inventory_hostname et ansible_default_ipv4.address.

Ici on tire partie de la faculté qu’a Ansible de récupérer des « facts » sur les machines, telle que l’adresse IP, que nous n’avons pas eu à renseigner.

C’est déjà un bon point par rapport à un script ou une commande à la main … mais on peut faire mieux !!

Aller plus loin : avec les variables de groupes

La première chose que je vais montrer dans cet article est qu’on peut également affecter aux groupes d’hôtes dans Ansible des variables.

Dans notre exemple, je vais donc créer un répertoire group_vars dans lequel je vais créer des fichiers de configuration dédiés à chaque groupe. J’en créé un par groupe (ou pas), et Ansible analysera automatiquement le répertoire group_vars et appliquera à mes hôtes toutes ces variables en fonction de ses groupes.

cat /etc/ansible/group_vars/serveurs-linux.yml
#NRPE Servers
nrpe_servers: ['192.168.100.10', '192.168.100.11']
#Poller Centreon
centreon_server: 'superviseur.company.lan'
centreon_pollername : 'Central'
centreon_clapi_username : 'admin'
centreon_clapi_password : 'admin'
centreon_clapi_path : '/usr/share/centreon/www/modules/centreon-clapi/core/centreon'

Je modifie donc mon playbook de la façon suivante :

cat centreon_add_host.yml
---
- name: centreon add host
shell: '{{centreon_clapi_path}}' -u '{{ centreon_clapi_username }}' -p '{{ centreon_clapi_password }}' -o HOST -a add -v '{{ inventory_hostname }};{{ inventory_hostname }};{{ ansible_default_ipv4.address }};generic-host;{{ centreon_pollername }};ALL_HOST'
delegate_to: '{{centreon_server}}'

Le playbook est beaucoup plus réutilisable qu’avant. Qu’est ce qui a changé ?

J’ai variabilisé le chemin vers le binaire d’appel de CLAPI, qui était quand même vraiment long (Même si on préfèrera probablement plutôt ajouter le chemin dans le PATH, simplement) !
Je n’ai plus à renseigner le username et le mot de passe pour CLAPI à chaque appel.
Si j’ai plusieurs serveurs Centreon (plusieurs réseaux distincts par exemple), je n’ai qu’à créer un groupe et un fichier de variables dans group_vars dans lequel je renseignerai « centreon_server », « clapi_username » et « clapi_password » différents. Mon playbook restera inchangé.
Si j’ai plusieurs pollers (pollerprod pour la prod dans cet exemple), je peux affecter le serveur directement au bon poller avec la variable « centreon_pollername ».

Encore un peu plus loin : avec les groupes et l’héritage

Dans la configuration exemple que je donne plus haut, vous aurez peut être remarqué le groupe serveurs-linux qui regroupe tous les serveurs des groupes serveurs-prod, serveurs-rect et nouveaux.

[serveurs-linux:children]
serveurs-prod
serveurs-rect
nouveaux

De cette manière, tous les paramètres communs à tous les serveurs linux peuvent être configurés au niveau serveurs-linux. Les variables seront héritées lors de l’exécution du playbook.

On peut aussi utiliser les groupes comme conditions de l’exécution d’un playbook. Ainsi, le playbook suivant ne s’exécutera que si le serveur fait parti du groupe serveurs-prod.

cat centreon_add_host_prod.yml
---
- name: centreon add host when in serveurs-prod
shell: '{{centreon_clapi_path}}' -u '{{ centreon_clapi_username }}' -p '{{ centreon_clapi_password }}' -o HOST -a add -v '{{ inventory_hostname }};{{ inventory_hostname }};{{ ansible_default_ipv4.address }};generic-host;{{ centreon_pollername }};ALL_HOST'
delegate_to: '{{centreon_server}}'
when: "'serveurs-prod' in group_names"

Toujours plus loin : avec les variables et les templates

Les variables sont vraiment un gros plus !

Elles me permettent notamment de configurer les fichiers nrpe.conf (ou ntpd.conf, snmpd, resolv.conf, …) pour accepter les connexions des bons serveurs en fonction de la localisation ou du groupe.

La fonctionnalité la plus utile dans ce cas là est l’utilisation de templates. Il s’agit de fichiers de configurations variabilisés qui sont déployés uniquement si nécessaire sur les serveurs cibles en fonction de leurs variables.

Exemple d’un template de fichier nrpe.conf

{{ ansible_managed }}
cat nrpe.conf.j2
log_facility=daemon
pid_file=/var/run/nrpe.pid
server_port=5666
nrpe_user=nagios
nrpe_group=nagios
allowed_hosts={% for i in nrpe_servers %} {{ i }}, {% endfor %}
debug=0
command_timeout=60
connection_timeout=300
command[check_users]=/libexec/check_users -w 5 -c 10
[...]

Le playbook suivant permettra de le déployer sur l’ensemble de mes serveurs CentOS et Redhat le package du client nrpe et ses dépendances et configurer le fichier nrpe.cfg en fonction du contexte (pour ceux qui n’ont pas encore ce fichier ou une version différente).

cat nrpe.yml
---
- hosts: all
tasks:
- yum: name={{ item }} state=installed
with_items:
- nrpe.x86_64
- net-snmp
- sysstat
- ...
- template: src=nrpe.cfg.j2 dest=/etc/nagios/nrpe.cfg

Une fois exécuté avec la commande suivante, Ansible balayera l’ensemble des serveurs renseignés dans le fichier /etc/ansible/hosts, vérifiera qu’ils ont tous les packages nrpe d’installés, puis déploiera sur les serveurs nécessaires le fichier de configuration en fonction des variables de chacun.

ansible-playbook -i /etc/ansible/hosts /etc/ansible/nrpe.yml

Et dans mon exemple on obtiendra un fichier de la forme suivante :

# Ansible managed: nrpe.cfg.j2 modified on 2016-08-14 10:52:51 by ansible on hostname
log_facility=daemon
pid_file=/var/run/nrpe.pid
server_port=5666
nrpe_user=nagios
nrpe_group=nagios
allowed_hosts=192.168.100.10, 192.168.100.11,
debug=0
command_timeout=60
connection_timeout=300
command[check_users]=/libexec/check_users -w 5 -c 10
[...]

Mais Ansible est avant tout un gestionnaire de configuration

Ansible ne sert pas uniquement à déployer des applications sur un serveur ou à exécuter des tâches automatisables. Au delà de ces rôles qu’il rempli à merveille, Ansible est surtout un gestionnaire de configuration (comme Puppet, Salt, …).

Ansible is the simplest way to automate apps and IT infrastructure. Application Deployment + Configuration Management + Continuous Delivery.

On le voit avec mon dernier exemple : le but est de garantir qu’un ensemble de serveurs donnés, on a toujours la même configuration.

C’est le principe fondamental des outils de gestion de configuration et on comprend vite le gain :

Si une modification est réalisée par erreur, elle sera automatiquement corrigée au prochain passage du playbook => on n’aura pas besoin d’attendre qu’un administrateur passe par hasard sur un serveur pour remarquer une anomalie sur le NTP par exemple.

Appliqué à la supervision et Centreon

Je garanti que tous les serveurs inscris dans Ansible sont automatiquement ajoutés dans Centreon, en fonction de leur groupe. Si un administrateur oublie d’ajouter un serveur ou en supprime un, il sera ré-ajouté à l’exécution d’après sans intervention manuelle.

C’est donc de cette manière qu’il est conseillé d’utiliser Ansible. Le playbook n’est pas là pour être joué une fois par serveur, au fil de l’eau, car c’est source d’erreur ou d’oublis. On préférera plutôt exécuter régulièrement l’ensemble des playbooks qui définissent le SI sur l’ensemble des serveurs pour s’assurer qu’ils sont tous « conformes », sur tous les aspects dont la supervision.

Le réel gain en terme d’automatisation ce trouve ici.

Et dans l’article qui va suivre ?

Et c’est sur cette deuxième partie que nous nous attarderons dans le prochain article : la gestion de playbook pour automatiser la configuration de la supervision pour l’ensemble de nos hôtes via des playbooks idempotent (#teasing) !