Nagios 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;

Hacker un calendrier javascript (datepicker) avec un scraper python

Tue, 09 May 2017 12:00:26 +0000

Mais quel rapport entre un datepicker javascript et un scraper python ?

Si vous ne savez ni ce qu’est un datepicker en Javascript ou un scraper python, je vous ai probablement déjà perdu. Pourtant, dans cet article ultra fun (ok, je suis bizarre), je vous montrerai comme j’ai automatisé via un scraper développé en python la recherche de dates libres dans un calendrier Javascript sur une page web :

en scriptant la génération de cette page via une ligne de commande
en simulant un clic pour passer au mois suivant
et enfin en récupérant les bonnes valeurs (pour me les envoyer par email par exemple)

Commençons donc par un peu de storytelling

Depuis quelques mois, je vais régulièrement sur un site web un peu artisanal sur lequel je fais des réservations. Pour se faire, ce site web propose une page web simple dans lequel a été intégré un composant calendrier :

Rien de particulièrement extraordinaire jusque là.

Mais (car bien sûr il y a un mais), ce site à l’inconvénient d’être victime de son succès. Pour vous donner une idée, c’est le genre de site web qui tombe 30 secondes après l’ouverture des réservations à 19h00. Et que dès que l’administrateur système le relance entre 20 et 50 minutes plus tard, les réservations sont complètes en quelques minutes.

Méthode 1 : F5

La première méthode, probablement plébiscité par la plupart des utilisateurs, est à base de refresh frénétique du site web, jusqu’à ce qu’il devienne inopérant… Une fois que le site est down, on peut continuer à appuyer sur F5 en espérant être le premier quand il reviendra.

Le souci de cette méthode, c’est que je manque cruellement de patience et que je lâche l’affaire assez vite. Et donc tous les mois, les plus hargneux (ou les plus chanceux) me passent toujours devant car j’ai loupé le moment où le site redevient accessible.

Méthode 2 : cURL

En bon administrateur système que je suis, je ne pouvais pas me résoudre à en rester là. Mon problème principal étant d’être prévenu lorsque le site devenait à nouveau opérationnel, j’ai sorti ma boîte à outils habituelle : cURL !

cURL (abréviation de client URL request library), est un outil à tout faire quand on veut jouer avec des URL sur un serveur Linux. C’est simple et efficace.

Dans le cas où le site est tombé suite à la connexion massive des internautes avides de réservations, j’ai donc créé un petit script basé sur ce oneliner

curl http://@IP_ou_FQDN/le_chemin_de_la_page/ -I 2>/dev/null | head -n 1
HTTP/1.1 200 OK

Dès que le code retour passe de 503 à 200, c’est que le site web est de nouveau accessible et je peux me remettre à faire F5 en espérant que les réservations ouvrent.

Méthode 2bis : aller plus loin avec cURL

Bon… La méthode précédente fonctionne… mais ce n’est pas encore ça !

Typiquement, il arrive que l’ouverture des dates soit reportée au lendemain, quand le site est vraiment trop longtemps dans les choux. Du coup le site répond (et mon test me revoie que le site est opérationnel), mais les dates ne sont pas disponibles pour autant…

Un rapide coup d’œil aux sources me donne l’info que je cherche. Il n’y a plus qu’à automatiser ça.

Mais évidemment ça n’est pas si simple…

Firefox interprète le Javascript, mais pas cURL, qui ne sait pas interpréter le Javascript (cf ce post de Stack Overflow). Le retour de ma commande contient donc le code source HTML avec le Javascript brut, mais pas les données que je recherche…

Méthode 3 : Un scraper ?

Je dois écrire un scraper qui va aller simuler l’action de l’humain qui va ouvrir la page dans un navigateur. Le post de Stack Overflow cite PhantomJS qui est probablement une bonne solution.

PhantomJS is a headless WebKit scriptable with a JavaScript API. It has fast and native support for various web standards: DOM handling, CSS selector, JSON, Canvas, and SVG.

Cependant je ne connais pas bien JS (ça fait longtemps on va dire) et je préfère capitaliser sur Python. J’ai donc cherché un module Python pour régler mon problème, et j’en ai trouvé 2 : un module python selenium et un plus simple appelé dryscrape.

J’ai installé dryscrape sur un de mes serveurs (un CentOS 7 minimal, sans environnement graphique). La documentation de dryscrape est disponible ici et ici (stable, documentation plus fournie).

yum install -y qt5-qtwebkit-devel gcc-c++
sed -i 's/PATH=$PATH:$HOME\/bin/PATH=$PATH:$HOME\/bin:\/usr\/lib64\/qt5\/bin/' .bash_profile
source .bash_profile
pip install dryscrape

Et j’ai tout de suite voulu tester un bout de code sans trop chercher à comprendre.

cat << EOF > test.py
import dryscrape
session = dryscrape.Session()
session.visit('http://@IP_ou_FQDN/le_chemin_de_la_page/')
response = session.body()
print response
EOF

… je me suis donc pris un bon gros Traceback :

Traceback (most recent call last):
File "test.py", line 3, in <module>;
session = dryscrape.Session()
[...]raise NoX11Error("Could not connect to X server. "
webkit_server.NoX11Error: Could not connect to X server. Try calling dryscrape.start_xvfb() before creating a session.

Ahhhhh oui… ça !

xvfb_ (necessary only if no other X server is available)

En fait il suffit d’ajouter un test pour exécuter dans xvfb si nécessaire.

Un premier exemple

Le bout de code suivant ne fait que récupérer le code source de la page et l’afficher à l’écran.

cat << EOF > simple_scraper.py
#!/usr/bin/python
# -*- coding: utf-8 -*-
import sys
import dryscrape
if 'linux' in sys.platform:
# start xvfb in case no X is running. Make sure xvfb
# is installed, otherwise this won't work!
dryscrape.start_xvfb()
session = dryscrape.Session()
session.visit('http://@IP_ou_FQDN/le_chemin_de_la_page/')
response = session.body()
print response
EOF

Mais la grosse différence avec le cURL précédent, c’est que dans le cas présent, ici le Javascript est interprété. Cette fois ci dans le code source retourné, je retrouve bien mon calendrier

A partir de là, il ne me reste donc en théorie qu’à terminer d’écrire un petit bout de script pour extraire les informations qui m’intéressent et à me notifier quand des places sont libres ! On progresse !

Méthode 3 : Scraper comme jamais

Ce montage pourri d’un clip de Maître Gimms avec des logos dans la main vous est offert par Zwindler

Mais je n’étais pas encore satisfait. Mon but est d’être prévenu lorsque des places sont disponibles. Or, les places s’ouvrent le 1er du mois, pour le mois suivant. En revanche, le composant Javascript datepicker a la mauvaise idée de donner les disponibilités pour le mois en cours. Mon script simple_scraper.py ne récupère donc pas les bonnes dates…

Pour contourner le problème, il faut aller encore un peu plus loin dans l’automatisation des actions. Il faut simuler le clic de l’utilisateur sur la flèche vers la droite, qui passe au mois suivant.

C’est possible avec dryscrape, qui propose notamment une fonction pour sélectionner des nodes XPATH et interagir avec. Pour ceux qui ne connaissent pas XPATH, vous pouvez aller sur la doc de dryscrape qui donne quelques exemples, et aussi sur le tutoriel de la W3School.

Comme j’ai examiné le code HTML retourné par le datepicker, je sais quoi chercher :

Pour changer de mois en cours, dans un premier temps j’ai essayé d’utiliser le label « » » mais le module dryscrape ne supporte pas les caractères non ASCII ! Une solution qui fonctionne est de cliquer sur le lien qui contient javascript:void(0) contenu dans le div de classe datepick-next :

cat << EOF > datepick_scraper.py
#!/usr/bin/python
# -*- coding: iso-8859-15 -*-
import sys
import dryscrape
if 'linux' in sys.platform:
# start xvfb in case no X is running. Make sure xvfb
# is installed, otherwise this won't work!
dryscrape.start_xvfb()
session = dryscrape.Session()
session.visit('http://@IP_ou_FQDN/le_chemin_de_la_page/')
datepicknext = session.at_xpath('//*[@class="datepick-next"]/a')
datepicknext.click()
response = session.body()
print response
EOF

Après vérification, cette version du script renvoie bien le tableau avec les date de Juin (quand on est en Mai) !

Le mot de la fin

A partir du moment où vous en êtes là, il n’y a plus vraiment de limites à ce que vous êtes capable de faire. Dans mon exemple, j’aurai pu aller encore plus loin, extraire les dates disponibles, et même pourquoi pas aller jusqu’à remplir automatiquement le formulaire pour réserver automatiquement une date prédéfinie (voire même toutes les dates disponibles).

Ce n’est pas mon but : je vais me contenter de m’envoyer un email dès qu’une date se libère. Mais c’est possible !

Si vous voulez explorer les possibilité de dryscrape, la documentation officielle donne quelques exemples, et notamment celui de l’envoi d’un email depuis Gmail, entièrement automatisé comme si c’était un humain (!)

De quoi donner des idées, pour scraper comme jamais !

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
}

Plugin de supervision check_wlst_sessions (WebLogic 9+)

Wed, 09 Nov 2016 13:00:18 +0000

Dans la série : plugin 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 n’avez pas atteint un certain nombre de sessions concurrentes dans le serveur d’application Java WebLogic d’Oracle.

Mon problème initial était que je n’arrivais pas à avoir de manière simple le nombre de sessions sur une JVM WbLogic. Je pouvais compter le nombre de processus/threads, mais ça ne correspond pas forcément à un nombre d’utilisateurs actifs.

Or, l’éditeur du progiciel nous avait fourni un sizing en fonction d’un nombre d’utilisateurs. Il était donc important d’avoir ce chiffre de manière fiable.

Il existait un plugin similaire pour la version 8 du serveur d’application (développé par Sergei Haramundanis), mais qui utilisait un module Weblogic.Admin, déprécié dans la version 10 que j’utilise.

Je me suis donc basé sur le WebLogic Scripting Tool (WLST) qui permet d’administrer et de récupérer des informations des serveurs WebLogic via des commandes Python interprété par Java (-_-« ). En fait, on peut réaliser l’ensemble des opérations disponibles dans la console WebLogic (l’AdminServer) en script.

La documentation du WLST est disponible à l’URL suivante.

Voilà ce que ça donne, une fois mis en place :

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.