Snmp on Zwindler's Reflection

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
}

Installer 3 plugins Nagios dans EON 1.2, coupé d’Internet, level 1

Fri, 03 Sep 2010 12:47:18 +0000

J’aimerai vous faire partager certains de mes déboires pour installer 3 malheureux plugins Nagios sur mes deux EyesOfNetwork en production. Évidemment, dans un environnement bien maitrisé, connecté à Internet, ce serait risible d’écrire un article pour si peu. Malheureusement, EyesOfNetwork, surtout dans sa version 1.2, impose certaines limitations, et le fait d’être coupé d’Internet en impose encore plus.

Bon alors, c’est sûr, cet article ne va pas toucher beaucoup de monde. Le nombre d’utilisateurs d’EyesOfNetwork 1.2 (2.15 FTW!) dans un environnement offline ne doit pas atteindre des sommets, et la plupart de ces personnes-là sont probablement capables de se débrouiller seules. Mais bon, qui sait…

Comme vous le savez très certainement si vous avez décidé de lire la suite de cet article, Nagios, ou plutôt son cœur, a pour but d’ordonnancer une série de vérifications à effectuer sur votre matériel et les services qui en dépendent. Ces vérifications sont faites, non pas par Nagios lui-même, mais par une foultitude de petits scripts et autres outils (sondes, ou plugins).

Et c’est là toute la force de Nagios : Si un équipement ou un service un peu exotique n’a pas son plugin pré-installé avec Nagios, qu’à cela ne tienne! Un utilisateur de la communauté a probablement écrit un plugin lui correspondant. Et au pire, vous pouvez toujours en modifier un similaire si vos besoins ne sont pas satisfait, ou même en écrire un autre (en utilisant SNMP, une api spécifique au produit…).

Pour mes besoins personnels, j’ai voulu ajouter les trois sondes suivantes :

check_esxi_wbem.py (lien mort, j’utilise Internet Archive)) (vérification du hardware d’un serveur VMware ESXi)
check_esx3 (lien mort, j’utilise Internet Archive) (outils très complet pour superviser plusieurs variables tels que la charge CPU, mémoire, réseau, pour toutes les VMs, Serveurs, Fermes VMware)
check_mssql_health (lien mort, j’utilise Internet Archive) (sonde de vérifications diverses pour les bases de données Microsoft SQL Server 2000 ou mieux, utile pour la base MSSQL Express d’un petit vCenter, par exemple)

Dans ce premier article, le vais commencer simple, avec check_esxi_wbem.py, histoire de se mettre en jambe. Déjà, il peut être intéressant de savoir à quoi sert de plugin. Vous l’aurez surement remarqué si jamais vous disposez d’un serveur VMware, il existe un onglet dans le client vSphere (ou VI Client pour Infrastructure) qui permet de superviser en temps réel une série de paramètres hardware de votre serveur. Habituellement, on irait chercher ses paramètres en discutant aimablement avec le serveur en SNMP de l’hyperviseur (comme pour ESX, par exemple).

Cependant, (je ne sais pas si c’est une limitation complète ou juste pour la version gratuite), VMware à simplement désactivé le support de SNMP dans ESXi. Je dis bien « désactivé », car pour ceux qui connaissent un peu ou qui ont lu mes précédents articles, ESXi n’est en fait qu’une distrib Linux minimaliste (Busybox modifié), mais pas minimaliste au point de ne pas supporter SNMP ! Je n’ai pas essayé, mais les premiers liens dans Google pour la recherche « activer snmp esxi » vous indiqueront très certainement comment faire.

Bon… SNMP est désactivé, mais vSphere client arrive bien à avoir des informations, lui!?! Comment fait il ? Tout simplement comme tout le reste de ce qu’il fait : en utilisant l’API VMware pour donner des ordres aux hyperviseurs (création de VM, allumage/extinctions de VMs, du serveur, ajout d’un disque virtuel…).

Dans votre pseudo-console de configuration de ESXi (si si, l’espèce de mocheté, jaune et grise, après l’install!), vous aurez probablement déjà vu la ligne « Restart Management Agents ». Management agents fait référence à un démon (au sens Unix du terme, hein…) appelé hostd. En fait, ce n’est ni plus ni moins qu’un serveur web un peu spécial. Il est utilisé par le client vSphere pour commander le serveur ESXi via des requêtes HTTPS sur le port 8333. Mais là où ça nous intéresse, c’est que les outils vCLI et PowerCLI utilisent le démon, avec le même protocole. En théorie, il est donc possible de faire tout ce qu’on peut faire dans le client vSphere (dont le monitoring du hardware du serveur) en ligne de commandes.

Je vois déjà les yeux de tous les « scripteurs fous » s’allumer de désir. Calmez vos ardeurs, gens du monde du libre, la version non licenciée de ESXi (comprendre « gratuite ») est bridée aux actions en lecture seule pour tout ce qui est scripting. Oui, c’est très frustrant!

Relativisons cependant, pour lire l’état d’un serveur, « Lecture Seule » reste suffisant. En partant de ce principe, la communauté nous a pondu un script en python, qui nous permet de superviser le hardware nos ESXi! Cependant, pour fonctionner, ce script nécessite l’installation d’un module python complémentaire, que nous allons devoir télécharger depuis un autre réseau, puisque nous sommes offline sur notre EON 1.2! Le module à télécharger s’appelle pywbem. Une fois copié sur votre EON, l’installation est plutôt simple (d’où le level 1, il n’y a jamais de challenge au level 1).

# tar xvzf pywbem-[version].tar.gz
# cd pywbem-version
# python setup.py build
# python setyp.py install

Une fois ce module installé, le script peut être utilisé. Pour ceux qui débutent avec EON, l’ensemble des outils sont installés dans le répertoire /srv/eyesofnetwork/, ce qui n’est pas du tout un dossier d’installation « standard » pour la plupart des outils que nous voudront installer plus tard, d’où d’éventuels micmacs lors des installations. Le script check_esxi_wbem.py est donc à placer dans le dossier /srv/eyesofnetwork/nagios-[version]/plugins/.

Certaines personnes préfèrent séparer les plugins officiels (ceux fournit lors de l’install de Nagios) des plugins additionnels, et préfèrent les installer dans le dossier /srv/eyesofnetwork/nagios/libexec. A vous de décider une fois pour toutes, dès le début, puis de s’y tenir après. C’est vrai que c’est plus « propre », mais est-ce vraiment utile ?

Maintenant, vous pouvez admirer le résultat (il est préférable de tester le script avec l’utilisateur nagios, pour éviter les bêtes problèmes de droits) :

# su nagios
$ ./check_esxi_wbem.py [@IP_serveur_ESXi] [login_ESXi] [password_ESXi] [dell | hp]

Le dernier paramètre doit impérativement être dell ou hp, car le script ne gère que ces deux constructeurs (à l’heure actuelle), et va chercher des informations qui sont spécifiques au constructeur choisit.

Une fois que le retour de la sonde est correct

$ exit

Bon… pourquoi je râle ? Après tout, ce n’était pas si dur, juste un petit module de rien du tout à installer ! Rigolez si vous voulez, le prochain level ne sera pas aussi marrant…

Ah oui, pour finir, j’aimerais rappeler le petit tuyau d’Huggy :

Pour profiter de TOUTES les informations sur le hardware de votre serveur, votre ESXi (dans sa version 4, je ne suis pas trop sûr que ça soit encore exact) doit avoir être été installé avec la version de l’iso d’ESXi spécifique à votre constructeur.
Ainsi, pour un serveur HP, si vous avez la version « normale » d’ESXi 4.0 ou 4.0 U1, vous n’aurez par exemple pas l’état des disques du RAID, ce qui est dommage, vous en conviendrez.