NRPE : Problème avec la commande check_procs.
Dernièrement, j'ai eu la malchance d'avoir un problème hard (carte RAID H.S.) sur un de mes serveurs de production.Bon, ça arrive, le serveur n'était pas tous jeune... Le problème c'est que ce genre de désagrément se produit toujours le week-end :-) Sans être fataliste, d'un autre côté le week-end, l'utilisation des services est moindre, donc l'un d'en l'autre : on va pas se plaindre !!!
La priorité était de remettre les services en route le plus rapidement possible. Une fois le problème hardware mis en évidence (impossible de redémarrer le serveur), il était plus couteux d'essayer de réparer plutôt que de migrer sur un serveur de secours. Donc la solution choisie, voire imposée par les circonstance et le bon sens, consistait à migrer les services.
Après migration et remise en production des services, tous était redevenu à la normale. Ouf, j'ai eu chaud... C'est dans de telle situation que l'on est content d'avoir mis en place des sauvegardes régulières :-)
Touche finale: il ne restait plus qu'à remettre en place mes scripts de supervision sur le nouveau serveur de production.
Une partie du serveur étant déjà supervisé, je n'avais que les scripts spécifiques à mes services à remettre en place. Et là, grosse surprise, la supervision de la présence de certain processus me renvoyer :
- PROCS CRITICAL: 0 processes with args 'com.naos.enews.privateInterfaces.utilities.SendingSchedulingEmailings'
- PROCS CRITICAL: 0 processes with args 'com.naos.enews.privateInterfaces.utilities.NewNpaiManager'
Bizarre, car après vérification sur le serveur de production, les processus étaient bien présent et en cours d'exécution.
J'ai exécuté les commandes en direct sur le serveur sans passer par NRPE et là, le résultat était bien celui attendu :
# ./check_procs -c 1:1 -a com.naos.enews.privateInterfaces.utilities.NewNpaiManager
PROCS OK: 1 process with args 'com.naos.enews.privateInterfaces.utilities.NewNpaiManager'
Déduction logique : le problème venait du check_nrpe...
Hop, un petit coup de google and co... Dur dur de trouver la bonne informations...
Après pas mal d'heures de tests, de compilation des sources et pas mal d'heure de recherche sur le net (voire quelques jours...), j'ai enfin trouver "THE SOLUTION".
A priori, le problème proviennait d'une variable d'environnement permettant de limiter le nombre de caractères en sortie de la commande "ps". Lorsque je passais mes tests en local, j'utilisais le compte root. Donc il était normal que j'obtienne le résultat attendu. Par contre en passant pas NRPE, le compte utilisateur était celui de nagios. Le résultat de la commande "ps" était tronqué et la pattern recherchée était absente.
Finalement, la solution la plus élégante pour corriger le problème, a été trouvé via le lien suivant.
J'ai mis en application en modifiant mon fichier de configuration NRPE sur la machine à superviser :
command[check_sending_enews_procs]=COLUMNS=512 /usr/lib/nagios/plugins/check_procs -c 1:1 -a com.naos.enews.privateInterfaces.utilities.SendingSchedulingEmailings
command[check_smtp_log_enews_procs]=COLUMNS=512 /usr/lib/nagios/plugins/check_procs -c 1:1 -a com.naos.enews.privateInterfaces.utilities.NewNpaiManager
Après avoir sauvegardé et relancer le daemon nrpe, j'obtiens afin sur le serveur de supervision le résultat attendu :
# /usr/local/nagios/libexec/check_nrpe -H 192.168.0.146 -c check_smtp_log_enews_procs
PROCS OK: 1 process with args 'com.naos.enews.privateInterfaces.utilities.NewNpaiManager'
# /usr/local/nagios/libexec/check_nrpe -H 192.168.0.146 -c check_sending_enews_procs
PROCS OK: 1 process with args 'com.naos.enews.privateInterfaces.utilities.SendingSchedulingEmailings'
En conclusion :
Il devient de plus en plus dur de trouver de l'information pertinente sur les moteurs de recherche. Pourtant les problèmes à résoudre sont de plus en plus pointus et demandent quand même une bonne dose de réflexion... D'un autre côté, si c'était facile, ça ne serait pas aussi marrant :-) pour se remuer les méninges non ???