Nagios Exchange 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.

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.

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.

Plugin check_mem_ng.sh compatible RHEL 7+

Thu, 16 Jul 2015 12:28:35 +0000

Si vous utilisez Nagios(r) ou un des produits compatibles, vous « graphez » probablement l’usage de la RAM sur vos serveurs Linux.

Il existe plusieurs méthodes pour le faire : via SNMP, via NRPE, … Un des scripts que j’utilisais en production sur l’ensemble de mes Linux (qui m’avait plu par sa simplicité) était check_mem.sh. Je l’exécutais à distance à l’aide de NRPE.

Cependant, depuis la version 7 de RedHat, un changement dans la commande « free » remontait un résultat erroné (changement du nombre de colonnes).

J’en ai donc profité pour le réécrire, corrigeant ainsi le « bug » et en ajoutant quelques fonctionnalités qui me manquaient, comme des valeurs par défaut, des options supplémentaires et une meilleure gestion des perfdata(*).

Le nouveau mode de graphiques …

Je l’ai laissé compatible avec les installations check_mem.sh existantes. En théorie, vous avez juste à remplacer le script et tout devrait fonctionner comme avant, sans dépendances supplémentaires ou modification de configuration côté client et côté serveur.

C’est ici que ça se passe :

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

(*)pour mon usage. Mais je donne aussi la possibilité de conserver les perfdata historique à l’aide de la variable PERFDATA_LEGACY que vous pouvez positionner à 1, ou utiliser l’option check_mem_ng.sh -l

… et le mode legacy