Les aventures d'un Geek Unixien

Patch multi packet pour NRPE 2.13

2011-12-19T17:20:00.000+01:00

Malgré le faible intérêt de la sortie de nrpe 2.13, je vais tout de même le déployer pour la simple et bonne raison que nous allons bientôt migrer notre infrastructure nagios de Solaris à Linux. C'est donc dans ce cadre que j'ai voulu changer de version et surtout réappliquer le patch que j'utilise depuis pas mal de temps permettant de gérer des sorties longues.

Problème, le patch de tonvoon (dont je parle ici) n'est plus utilisable en l'état. Comme de toute façon le code source a très peu été retouché (juste l'ajout d'une fonction dans le démon nrpe), nous allons voir comment faire pour récupérer ce patch et forcer son application.

Tout d'abord, il nous faut récupérer une copie de notre patch sur notre machine :

wget https://dev.icinga.org/attachments/download/113/nrpe_multiline.patch

Passons maintenant à la transformation de notre patch au format Windows (eurk !) :

unix2dos ./nrpe_multiline.patch

Il ne nous reste plus qu'à passer le patch en indiquant la ligne de commande patch --binary -l -p1. Si tout se passe bien, la sortie devrait ressembler à ce qui suit :


nous@roulette:~/nagios/nrpe-2.13$ patch --binary -l -p1 < ../nrpe_multiline.patc
h 
patching file include/common.h
patching file src/check_nrpe.c
patching file src/nrpe.c
Hunk #1 succeeded at 972 (offset -57 lines).
Hunk #2 succeeded at 1190 (offset -57 lines).
Hunk #3 succeeded at 1206 (offset -57 lines).
Hunk #4 succeeded at 1235 (offset -57 lines).

Lançons maintenant la configuration et la compilation. Tout devrait bien se passer.

Nous allons maintenant nous assurer qu'il n'y a pas eu de régression. Tout d'abord créons un fichier nrpe.cfg avec le contenu suivant :


log_facility=daemon
pid_file=./nrpe.pid
server_port=5666
server_address=127.0.0.1
nrpe_user=nagios
nrpe_group=nagios
allowed_hosts=127.0.0.1
dont_blame_nrpe=0
debug=0
command_timeout=60
connection_timeout=300

command[short_output]=echo coucou
command[long_output]=/bin/cat /etc/wgetrc

La première commande affiche un simple coucou et la seconde affiche le contenu du fichier /etc/wgetrc.

Mais trêve de bavardage et lançons séance tenante notre démon :


nous@roulette:~/nagios/nrpe-2.13$ ./src/nrpe -c ./nrpe.cfg -d
nous@roulette:~/nagios/nrpe-2.13$ ps -ef | grep nrpe
nous      9374     1  0 17:04 ?        00:00:00 ./src/nrpe -c ./nrpe.cfg -d
nous      9376  5769  0 17:04 pts/0    00:00:00 grep --color=auto nrpe

Tout semble parfait. Lançons un test de notre première commande :


./src/check_nrpe -H localhost -c short_output
coucou

Ça semble plutôt pas mal. Regardons maintenant la taille de la sortie de notre commande longue et comparons cela au fichier d'origine :


nous@roulette:~/nagios/nrpe-2.13$ ./src/check_nrpe -H localhost -c long_output | wc
    126     797    4496
nous@roulette:~/nagios/nrpe-2.13$ wc /etc/wgetrc
 126  797 4496 /etc/wgetrc

C'est parfait ! Notre NRPE en version 2.13 avec patch sortie longue est prêt à fonctionner !

Sortie de NRPE 2.13

2011-11-26T12:28:00.001+01:00

Il y'a peu de temps, la version 2.13 de NRPE est sortie. Autant dire que je suis assez déçu sur le contenu de cette nouvelle version puisque nous n'avons qu'un seul changement pour définir qui a le droit de se connecter sur l'agent NRPE dans le fichier nrpe.cfg (ainsi que la compilation sous Solaris 10). En gros, auparavant, vous étiez obliger de donner explicitement l'IP de votre serveur nagios pour pouvoir vous connecter. Dorénavant, vous pouvez préciser un réseau avec un masque. Ci-dessous un exemple de fichier nrpe.cfg faisant appel à ce mécanisme :


log_facility=daemon
pid_file=/var/run/nagios/nrpe.pid
server_port=6666
nrpe_user=nagios
nrpe_group=nagios
# allowed_hosts=127.0.0.1
allowed_hosts=192.168.0.0/24

dont_blame_nrpe=0
debug=0
command_timeout=60
connection_timeout=300
command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10
command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
command[check_hda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/hda1
command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 150 -c 200

NB: ce démon tourne sur le port 6666 pour des besoins de test. La commande check_nrpe ci-dessous utilisera l'option -p 6666 pour pouvoir s'y connecter.
On va essayer de se connecter sur notre agent NRPE. Ci-dessous l'adresse de mon poste :


drayan@robert:~/dev/nrpe-2.13$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 1c:6f:65:21:7b:c0  
          inet adr:192.168.0.17  Bcast:192.168.0.255  Masque:255.255.255.0
[...]

Lançons un test en tant que localhost (qui devrait nous jeter du fait qu'on se présente avec l'adresse IP 127.0.0.1) :


drayan@robert:~/dev/nrpe-2.13$ ./src/check_nrpe -H localhost -c check_load -p 6666
CHECK_NRPE: Error - Could not complete SSL handshake.

Parfait ! Lançons maintenant la même chose en utilisant notre adresse IP :


drayan@robert:~/dev/nrpe-2.13$ ./src/check_nrpe -H 192.168.0.17 -c check_load -p 6666
OK - Charge moyenne: 0.03, 0.06, 0.09|load1=0.030;15.000;30.000;0; load5=0.060;10.000;25.000;0; load15=0.090;5.000;20.000;0;

Voilà, c'est tout ... Je suis notamment assez déçu que le patch pour gérer les sorties longues (dont j'avais parlé ici il y'a quelque temps) ne fasse pas partie de cette release.

Compilation de NRPE 2.13 sous Ubuntu 11.10

2011-11-26T10:38:00.001+01:00

Si comme moi vous voulez compiler votre démon NRPE 2.13 sous Ubuntu oneiric, vous avez dû tomber sur un bien beau message d'erreur :


drayan@robert:~/dev/nrpe-2.12$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
[...]
checking for type of socket size... size_t
checking for SSL headers... SSL headers found in /usr
checking for SSL libraries... configure: error: Cannot find ssl libraries
drayan@robert:~/dev/nrpe-2.12$

Autant dire qu'avec ça, je suis bien avancé. Après quelque recherche, je tombe sur un bug référencé sur launchpad : https://launchpad.net/ubuntu/oneiric/+source/nagios-nrpe/2.12-4ubuntu3.

Dans le bug, le mainteneur du paquet nous fait part d'un laconique message invitant à rajouter l'option --with-ssl-lib=<multiarch dir>. N'ayant pas trop d'idée de ce que ça pouvait bien vouloir dire, j'ai donc tâtonné avant de tomber sur un configure qui passait. Dans l'espoir de faire gagner du temps à d'autre, je vous fais donc part de cette merveilleuse option (dans le cas d'une machine avec un kernel x86_64) :


drayan@robert:~/dev/nrpe-2.13$ ./configure --with-ssl-lib=/usr/lib/x86_64-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
[...]
checking for SSL headers... SSL headers found in /usr
checking for SSL libraries... SSL libraries found in /usr/lib/x86_64-linux-gnu

*** Generating DH Parameters for SSL/TLS ***
Generating DH parameters, 512 bit long safe prime, generator 2
This is going to take a long time
.+......................[...].....++*++*++*++*++*++*
checking for Kerberos include files... could not find include files
checking for perl... /usr/bin/perl
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating subst
config.status: creating include/config.h


*** Configuration summary for nrpe 2.13 11-11-2011 ***:

 General Options:
 -------------------------
 NRPE port:    5666
 NRPE user:    nagios
 NRPE group:   nagios
 Nagios user:  nagios
 Nagios group: nagios


Review the options above for accuracy.  If they look okay,
type 'make all' to compile the NRPE daemon and client.

Bref, maintenant, je vais pouvoir me battre avec le patch long output pour NRPE.

Optimisation de PNP4Nagios avec RRDcached

2011-11-09T19:04:00.001+01:00

Suite à l'article sur l'utilisation du démon NPCD, j'ai voulu voir quel pourrait être l'impact de la mise en place du démon RRDCached sur le fonctionnement de PNP4Nagios. Pour se faire, il faut bien comprendre à quoi sert ce fameux démon.

Pour cela, il faut revenir sur le fonctionnement de PNP4Nagios à savoir de prendre un grand nombre de métrique et d'alimenter au fur et à mesure un grand nombre de petit fichier : les fichiers RRD. Au delà d'un certain nombre de service, nous pouvons nous retrouver avec une machine qui fait énormément d'IO et qui du coup n'a plus le temps de mettre à jour certaines métriques (mécanisme de timeout de PNP4Nagios). Nous voyons donc qu'au delà un certain seuil, PNP4Nagios peut retomber sur tous les travers classiques des infrastructures de surveillance : consommer de la puissance CPU et être lent (qui a soufflé le nom de NDO utils ?). Le démon RRDCached prend ici tout son sens. En effet, ce dernier va buffuriser les mises à jours RRD au lieu de les faire unitairement réduisant grandement les IO sur notre serveur nagios.

Pour mieux comprendre, prenons le cas d'un serveur nagios remontant en moyenne 10 métriques par services. Si vous êtes comme moi et que vous avez explosé vos fichiers RRD en n fichiers pour chaque services, vous aurez un fichier par métrique. Si nous scruptons toutes les 5 minutes nos différents services (toujours en moyenne), nous nous retrouvons à mettre à jour 10 fichiers pour chaque test de service nagios. Si on reporte ce chiffre sur 1 heure, nous aurons donc environ 120 écritures sur une heure. Si vous multipliez tout ceci par le nombre de service présent sur vos machines (on va dire 5000), vous vous retrouvez à faire environ 600000 écritures par heure. Si vous ajoutez à cela que votre serveur faire appel à des métriques qui sont plus régulière (toutes les 2 minutes voir toute les minutes), vous pouvez commencer à avoir des problèmes.

RRDCached, en s'intercallant entre les outils RRD et les écritures sur le disque, va regrouper ces dernières et ainsi mieux exploiter les capacités de la machine. Imaginons que ce dernier procéde à une buffurisation des écritures sur 1/2 heure, vous diviserez par 6 vos IOs pour des services scruptant toutes les 5 minutes. Ce chiffre pouvant monter à 30 pour des services remontant des métriques toutes les minutes.

Voyons maintenant comment mettre en oeuvre ce démon.

NB : Par la suite, il est évident que je considérerai que PNP4Nagios sera configuré en mode NPCD (cf mon article sur la configuration de PNP4Nagios en mode NPCD) et surtout qu'il utilisera le module RRDs de perl pour faire ses mise à jour (cf mon article sur le sujet).

Installons tout d'abord notre démon rrdcached (sous Debian ou ubuntu) :

sudo apt-get install rrdcached

Et regardons si ce dernier est bien lancé :

$ /etc/init.d/rrdcached status
rrdcached (1262) is running.
$ ps -fp 1262
UID        PID  PPID  C STIME TTY          TIME CMD
root      1262     1  0 18:46 ?        00:00:00 /usr/bin/rrdcached -l unix:/var/run/rrdcached.sock -j /var/lib/rrdcached/journal

Tout semble aller pour le mieux. Nous allons maintenant configurer le script process_perfdata.pl afin qu'il passe par ce démon pour la mise à jour des fichiers RRD. Pour se faire, nous allons modifier le fichier process_perfdata.cfg et notamment la ligne suivante :

RRD_DAEMON_OPTS = unix:/var/run/rrdcached.sock

Attendons un petit peu et allons consulter l'interface de PNP4Nagios. Cette dernière ne devrait plus nous remonter de statistique sur notre moteur PNP4Nagios. Ce comportement est tout à fait normal étant donné que l'interface PHP de PNP4Nagios n'a aucune connaissance de ce nouveau démon. Ce dernier continue donc de s'appuyer sur les fichiers RRD présent alors que ces derniers ne sont plus mis à jour en temps réel.

Modifions maintenant la configuration de PNP4Nagios (fichier config_local.php qu'il faudra créer s'il n'existe pas) afin de lui préciser le pipe nommé de notre démon de cache :

$conf['RRD_DAEMON_OPTS'] = 'unix:/var/run/rrdcached.sock';

Dorénavant, le graphique se met bien à jour en temps réel. En effet, en précisant au binaire RRDTool que nous avons un démon de cache, ce dernier va simplement dire au démon de vider ses buffers sur les fichiers RRDs que nous sommes en train de consulter afin qu'il nous fasse profiter des dernières valeurs que ce dernier avait emmagasiné.

Vous pourriez vous dire que le fait de vider le cache de notre démon avant de pouvoir consulter nos graphiques est une perte de temps. Effectivement, ce comportement sera peu avantageux pour les fichiers RRDs que nous voudrons consulter. En revanche, il sera avantageux pour les milliers d'autres qui pourront continuer à être buffurisé.

ATTENTION !!! Dorénavant, votre démon RRDcached est un élément vitale de votre infrastructure. Je vous recommande chaudement de le surveiller avec votre moteur nagios sous peine de ne plus avoir de mise à jour si ce dernier devait tomber.

Vous allez me dire que tout ça c'est très bien mais vous voudriez savoir si le jeu en vaut la chandelle. Comme généralement les graphiques parlent plus que les chiffres, voici les résultats des temps de réponse moyen de PNP4Nagios suite à la mise en place de ce merveilleux plugin (ici sur 1 mois) :

Comme vous pouvez le constater, du jour où le démon a été mis en place, j'ai vu une grosse diminution de l'effet yoyo et surtout une baisse assez importante du temps moyen pour les mise à jour de PNP4Nagios (passage de 9 secondes avec pointe à 70 secondes à une moyenne sans pique autour de 5 secondes). Autant vous dire que tout ceci est une très bonne nouvelle et que je vais pouvoir continuer mon travail de big brother !

Template wlsagent pour PNP4Nagios

2011-09-20T00:00:00.001+02:00

Il y a de ça peu de temps, j'ai présenté l'utilisation de wlsagent pour le suivi sous nagios d'instance WebLogic. J'avais également donné quelques exemples de graphique sous PNP4Nagios mais sans donner le template de présentation :

Le template est maintenant disponible à l'adresse suivante : http://docs.pnp4nagios.org/templates/check_wlsagent

Il faut copier-coller ce fichier dans le répertoire template de PNP4Nagios (en principe, quelque chose comme /usr/local/pnp4nagios/share/templates/) et se débrouiller pour que PNP4Nagios arrive à faire le lien entre le plugin de lancement et le template.

Personnellement, comme j'appelle tout au travers de NRPE, j'ai simplement créé un doublon de la commande check_nrpe en l'appelant check_wlsagent :

# 'check_wlsagent' command definition
define command{
  command_name check_wlsagent
  command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

J'appelle ensuite mes surveillances à l'aide de commande de ce genre :

# Application WebLogic à surveiller
define service{
  use generic-service
  host_name remotehost
  service_description Application hyperimportante
check_command check_wlsagent!check_application_hyperimportante
}

Optimisation du couple nagios/PNP4Nagios

2011-09-13T23:44:00.000+02:00

Description de l'installation

J'utilise depuis maintenant plusieurs années un moteur nagios sur notre infra pour avoir un suivi de ce qu'il se passe sur nos serveurs.

Au début, nous avions axé notre déploiement sur la partie serveur d'application Java (à base de WebLogic). Nous avons très rapidement activé l'utilisation du moteur de base de données ndo2db. Par la suite nous avons intégré environ 60 serveurs sous cette surveillance pour un total d'environ 600 services. Les choses sont restés en l'état en raison de la machine que nous utilisions qui était particulièrement lente et pauvre en IO disque (pour les plus curieux, il s'agissait d'un Sunfire V210 avec un bi-processeur Ultrasparc III@1Ghz et 2 Go de mémoire).

Il y'a de ça un an et demi, nous avons échangé notre vieille machine poussive contre une machine Solaris flambant neuve (à base de M5000). De là, j'ai profité pour changer nos outils d'autant que je n'étais pas particulièrement content de ndo2db. C'est à cette occasion que j'ai mis en place la toute dernière version de PNP4Nagios en version 0.6 (que j'avais testé en version béta quelques temps auparavant).

De là, j'ai découvert le super système de template de PNP4nagios (cf cet article) et j'ai commencé à mettre ça en oeuvre sur tous nos éléments vitaux d'infrastructure (apache, oracle, MySQL etc.).

Le mode synchrone de PNP4Nagios étant particulièrement lent, j'ai très vite déployé PNP4Nagios en mode bulk lancé par nagios. Mais, le succès aidant, je suis rapidement passé de 60 à 100 machines puis 200. Comme un SI ne diminue jamais, dernièrement nous sommes arrivé à environ 300 machines pour environ 3000 services. Loin d'être énorme (en tunant la configuration de nagios, on parle de configuration montant à 30000 services et plus), les performances du moteur nagios avaient tout de même tendance à se dégrader comme on peut le voir sur le graphique ci-dessous des temps de latence maximum :

On voit ici des temps de latence maximum qui monté à plus de 60 secondes. Même si c'est loin d'être complètement bloquant, ça indique une réactivité beaucoup moins bonne qu'au début du fonctionnement de la plateforme.

C'est donc à ce moment là que j'ai commencé à regarder les optimisations qu'il était possible de faire et notamment l'utilisation de NPCD. J'ai également mis en place le démon de cache RRD. Pour ce dernier j'essaierai d'en parler dans un autre article.

Mise en place de NPCD

La mise en place de NPCD se fait en deux temps : mise en place du démon puis modification de la commande d'insertion des données de performance dans PNP4Nagios. Ci-dessous un schéma extrait du site de PNP4Nagios expliquant le fonctionnement du démon NPCD :

Pour le lancement du démon NPCD, rien d'extraordinaire, il suffit simplement de lancer la commande suivante :

/usr/local/pnp4nagios/bin/npcd

On peut ensuite vérifier sa présence sur le serveur :

ps -ef | grep npcd

Le démon se lance en s'appuyant sur le fichier /usr/local/pnp4nagios/etc/npcd.cfg. Ce dernier va contenir toutes les informations sur le comportement que devra adopter le démon. Vous pouvez notamment tuner les éléments suivants :

Le temps de pause entre deux checks dans le répertoire de spool ;
Le nombre max de process perfdata à lancer en parallèle ;
La verbosité de la log.

Une fois NPCD, nous allons maintenant pouvoir basculer l'insertion des données en utilisant un répertoire de spool. Pour se faire, nous allons changer les commandes process-service-perfdata-file et process-host-perfdata-file (en principe dans le fichier /usr/local/etc/nagios/template/commands.cfg). Ces dernières ressemblaient aux lignes suivantes :

define command {
       command_name    process-service-perfdata-file
       command_line    /usr/local/pnp4nagios/libexec/process_perfdata.pl --bulk=/usr/local/pnp4nagios/var/service-perfdata
}

define command {
       command_name    process-host-perfdata-file
       command_line    /usr/local/pnp4nagios/libexec/process_perfdata.pl --bulk=/usr/local/pnp4nagios/var/host-perfdata
}

Nous les avons remplacé par les lignes suivantes :

define command {
       command_name    process-service-perfdata-file
       command_line    /bin/mv /usr/local/pnp4nagios/var/service-perfdata /usr/local/pnp4nagios/var/spool/service-perfdata.$TIMET$
}

define command {
       command_name    process-host-perfdata-file
       command_line    /bin/mv /usr/local/pnp4nagios/var/host-perfdata /usr/local/pnp4nagios/var/spool/host-perfdata.$TIMET$
}

Il s'agit simplement de substituer l'appel direct à la commande process_perfdata.pl de PNP4Nagios par un déplacement de fichier dans un répertoire. Pas grand chose me direz-vous mais nous allons vite voir que ce petit changement aura des conséquences très intéressante au niveau de nagios.

Résultat de l'optimisation

Et il se trouve que cette modification a eu un énorme impact sur les performances. Pour preuve un état du temps de latence moyen maximum :

On peut voir que nous avons gagné en stabilité au niveau des temps de réponse max et surtout que ces derniers restent largement en dessous les 5 secondes (sauf exceptionnellement mais rien à voir avec le comportement précédent).

Création d'un timelapse

2011-09-11T23:59:00.001+02:00

Depuis tout petit, j'ai toujours été intéressé par les étoiles et notamment les superbes images nous faisant découvrir les galaxies, les étoiles mortes, les nébuleuses etc. Paradoxalement, je ne m'étais jamais trop posé la question de faire ces observations par moi même puisque bien d'autre avant moi l'avait fait et - de mon point de vue - l'avait très bien fait.

Mais voilà, par un bel été il y a quelques années, ma mère m'a fait découvrir les anneaux de Saturne directement à l'aide de son petit télescope. C'est à ce moment que j'ai réalisé qu'il serait intéressant de contempler par moi même certain phénomène. Pour toute ces raisons (et pour d'autre comme par exemple la naissance de mon petit dernier), je me suis intéressé dans l'achat d'un appareil photo réflex et les techniques de photographie de type timelapse.

Ah, j'oubliais de vous préciser un truc : je n'utilise que des logiciels libre et ma machine principale héberge un Linux depuis des années. Pour ces raisons, j'essaye de faire partager ma petite expérience sur le sujet avec d'autre. Par la suite, nous utiliserons les logiciels suivant :

gphoto : il nous aidera à faire nos prises de vue à espace régulier. Je recommande néanmoins l'utilisation d'un intervalomètre pour éviter de se traîner un portable pendant une séance de photo ;
convert : outil de convertion d'image en ligne de commande ;
mencoder : outil de création de fichier vidéo.

Prendre des photos à intervalle régulier

Première chose, il faut utiliser un trépied afin que le cadre de vos photos reste identique de bout en bout. Il faut également désactiver l'autofocus de l'appareil ainsi que le stabilisateur d'image si vous en avez un. Fixer maintenant un élément qui vous intéresse et commencez à prendre vos photos à intervalle régulier. Pour se faire vous pouvez soit passer par un intervalomètre soit par le logiciel gphoto. En effet, ce dernier vous permet de prendre des photos directement à l'aide d'un ordinateur. Ci-dessous un exemple de ligne de commande :

gphoto2  --auto-detect --capture-image-and-download -I 1

Ci-dessous une petite explication des options présentes :

L'option --auto-detect à pour rôle d'inviter gphoto à utiliser le premier appareil détecté ;
L'option --capture-image-and-download invite gphoto à prendre une photo et à la télécharger automatiquement sur le PC ;
Enfin, l'option -I 1 indique le temps de pause entre chaque photo.

A la fin de votre séance de photo, vous devriez obtenir quelques centaines d'image que nous allons mettre maintenant bout à bout dans une vidéo.

Création de la vidéo

Nous allons procéder en deux étapes :

Retailler les photos ;
Assembler les photos dans une vidéo.

Pour la première étape nous allons utiliser l'outil convert de imagemagick. Nous allons également utiliser un petit bout de shell pour lancer cette convertion en boucle :

yannig@portable:~/Images/2011-09/timelapse/resize$ for i in ../*.JPG
do
  echo $i
  convert -resize 1440 $i $(basename $i)
done

L'option -resize 1440 indique à l'outil convert la taille désiré pour le fichier de résultat. Par défaut, la retaille se fait en préservant l'aspect de la photo.

NB : Pour éviter de tout mélanger, j'ai mis le résultat de la conversion dans un sous-répertoire resize.

Passons maintenant à la création de la vidéo à l'aide de mencoder (à lancer dans le répertoire contenant les fichiers retaillés) :

mencoder "mf://*.JPG" -mf fps=15:type=jpg -ovc x264 -x264encopts bitrate=3000 -o video-resultat.flv

Encore une fois, étudions ensemble les options de mencoder :

"mf://*.JPG" : donne le patron des fichiers à prendre en compte pour créer la vidéo ;
-mf fps=15:type=jpg : donne des informations sur la cadence désirée pour la vidéo ;
ovc x264 -x264encopts bitrate=3000 : information sur les paramètres d'encodage de la vidéo ;
-o video-resultat.flv : explicite le nom du fichier résultat.

Vidéo de résultat

Ci-dessous un petit exemple de ce que peu donner une vidéo réalisé avec ces outils :

Pour informations, cette vidéo à été réalisé avec 382 photos. Ces dernières ont été assemblées à une cadence de 25 images par secondes. Chaque image a été prise en mode automatique sur un Canon EOS 550D avec un intervalle de 10 secondes entre chaque prise de vue.

En espérant que tout ceci vous inspire !

Mise en place de wlsagent

2011-09-07T22:50:00.000+02:00

J'ai déjà parlé sur ce blog d'intégrer une surveillance des indicateurs interne de WebLogic sous nagios. Nous allons voir ensemble un nouvel exemple de plugin particulièrement intéressant que j'ai eu l'occasion de déployer : wlsagent.

Installation de l'agent wlsagent

Il nous tout d'abord récupérer une version récente de notre plugin :

yannig@portable:~/wlsagent$ svn checkout http://wlsagent.googlecode.com/svn/trunk/src src

Procédons maintenant à la récupération des librairies nécessaires au fonctionnement de wlsagent :

jetty-continuation-7.3.1.v20110307.jar
jetty-http-7.3.1.v20110307.jar
jetty-io-7.3.1.v20110307.jar
jetty-security-7.3.1.v20110307.jar
jetty-server-7.3.1.v20110307.jar
jetty-servlet-7.3.1.v20110307.jar
jetty-util-7.3.1.v20110307.jar
servlet-api-2.5.jar
wlclient.jar
wljmxclient.jar

Tous les jars de type jetty et servlet-api font partie du package jetty que vous pouvez récupérer à l'addresse suivante : http://www.eclipse.org/jetty/downloads.php

Déposons maintenant ces fichiers dans le répertoire lib, à la même hauteur que le répertoire src des fichiers sources de wlsagent. Concernant les fichiers wlclient.jar et wljmxclient.jar, vous les trouverez dans les binaires de WebLogic.

Récupérons ensuite le fichier de build ant suivant :




 name="wlsagent" basedir="." default="build">

     name="src.dir"     value="src"/>
     name="build.dir"   value="build"/>
     name="classes.dir" value="${build.dir}/classes"/>
     name="jar.dir"     value="${build.dir}/jar"/>
     name="lib.dir"     value="lib"/>
     name="main-class"  value="net.wait4it.wlsagent.WlsAgent"/>

     id="classpath">
         dir="${lib.dir}" includes="**/*.jar"/>
    

     name="clean">
         dir="${build.dir}"/>
    

     name="compile">
         dir="${classes.dir}"/>
         srcdir="${src.dir}" destdir="${classes.dir}" classpathref="classpath" includeantruntime="true"/>
    

     name="jar" depends="compile">
         dir="${jar.dir}"/>
         destfile="${jar.dir}/${ant.project.name}.jar" basedir="${classes.dir}">
            
                 name="Main-Class" value="${main-class}"/>
            
        
    

     name="build" depends="clean,jar"/>

Lançons ensuite le build avec ant, vous devriez obtenir le fichier wlsagent.jar dans le répertoire build/jar.

Passons maintenant à la création du fichier de démarrage de wlsagent :

#!/bin/bash
JAVA_HOME="/usr/lib/jvm/java-6-openjdk"
CURRENT_PATH=$(dirname $0)
LIB_PATH=${CURRENT_PATH}/lib
CLASSPATH=${CURRENT_PATH}/wlsagent.jar

for jar in $(find ${LIB_PATH} -name '*.jar'); do
  CLASSPATH=${CLASSPATH}:${jar};
done

start()
{
  ${JAVA_HOME}/bin/java -Xmx32m -cp ${CLASSPATH} net.wait4it.wlsagent.WlsAgent "9090" > $CURRENT_PATH/wlsagent.log 2>&1 &  echo $! > $CURRENT_PATH/wlsagent.pid
}

stop()
{
  kill $(< $CURRENT_PATH/wlsagent.pid)
}

case $1 in
  stop) stop ;;
  start) start ;;
  restart) stop ; sleep 1 ; start ;;
  status) ps -fp $(< $CURRENT_PATH/wlsagent.pid) ;;
  *) echo "Expected : start/stop/restart/status" ;;
esac

Il ne nous reste plus qu'à lancer le tout et de vérifier le bon démarrage de l'agent :


yannig@portable:~/wlsagent$ ./wlsagent.sh start
yannig@portable-ots:~/wlsagent$ ps -ef | grep wlsagent | grep -v grep
yannig    3922     1  0 10:45 pts/2    00:00:04 /usr/lib/jvm/java-6-openjdk/bin/java -Xmx32m -cp ./wlsagent.jar:.[...]servlet-api-2.5.jar net.wait4it.wlsagent.WlsAgent 9090

Un coup d'oeil dans la log pour vérifier le bon démarrage de l'agent :


yannig@portable:~/wlsagent$ more wlsagent.log 
2011-09-03 10:45:49.961:INFO::jetty-7.3.1.v20110307
2011-09-03 10:45:50.069:INFO::started o.e.j.s.ServletContextHandler{/wlsagent,null}
2011-09-03 10:45:50.222:INFO::Started SelectChannelConnector@0.0.0.0:9090

Tout est prêt ! Nous allons maintenant pouvoir lancer nos tests de communication.

Utilisation du plugin wlsagent

Avant toute chose il faut créer un utilisateur nagios faisant parti du groupe Monitors dans le domaine WebLogic.

On lance ensuite une requête sur l'agent à l'aide d'un wget :


wget -q -O - "http://localhost:9090/wlsagent/WlsAgent?hostname=$(hostname)&port=7028&username=nagios&password=xxx&jvm=UsedMemory;80;90"
0|AdminServer: status OK|HeapSize=370M;;;0;910 UsedMemory=210M;;;0;910

Ici, pas de problème la communication se passe bien. Il suffit ensuite d'intégrer cette surveillance dans nagios pour obtenir une collecte. Pour se faire, vous pouvez récupérer un script d'invocation à l'emplacement suivant : http://code.google.com/p/wlsagent/wiki/Invocation

Il vous faudra également un outil de collecte des données de performance comme PNP4Nagios. Ci-dessous un exemple de résultat d'intégration à la suite de 2 semaines de collecte :

Pour info, il est possible de remonter les éléments suivants :

Threads sur la JVM ;
Nombre de transactions en cours sur la JVM ;
Nombre de requête / seconde (throughput) ;
État des connexion JDBC ;
Nombre de session utilisateur ;
Et enfin, l'utilisation des queues JMS.

Activité datasource de l'application

Pour gérer ces surveillances, il est nécessaire de rajouter des options pour préciser les éléments à surveiller dans nagios. Pour plus de détail, se reporter à la page suivante : http://code.google.com/p/wlsagent/

mod_proxy_http Apache et console de gestion du load-balancer

2011-04-11T20:18:00.001+02:00

J'ai eu à faire une petite étude entre deux type de load-balancing HTTP sur des serveurs d'application WebLogic et c'est à cette occasion que j'ai découvert une perle : la console apache de load-balancing.

Je vous propose de voir ensemble comment l'activer et ce qu'elle vous apporte.

Par la suite je travaillerai avec une RedHat Enterprise 5.3 mais le principe reste le même pour n'importe quelle distribution.

Activation du module mod_proxy_http

Premier point, il vous faut installer une version récente de apache 2.2 et vérifier que la conf de ce dernier fait bien référence au module mod_proxy_http :

[root@myserver conf]# pwd
/etc/httpd/conf
[root@myserver conf]# grep mod_proxy_http.so httpd.conf
LoadModule proxy_http_module modules/mod_proxy_http.so

Un petit coup de apachectl configtest nous assurera que nous n'avons rien oublié.

Création d'une boucle de charge

Placez-vous ensuite dans le répertoire conf de votre serveur apache et créez-y un nouveau fichier de configuration contenant les lignes suivantes (à adapter suivant vos besoins) :

<Proxy balancer://lb-http>
  BalancerMember http://127.0.0.1:7002
  BalancerMember http://127.0.0.1:7004
</Proxy>

ProxyPass        /sample/ balancer://lb-http/sample/
ProxyPassReverse /sample/ balancer://lb-http/sample/

Ici, les URLs sous le contexte /sample/ seront envoyées systématiquement vers nos deux serveurs d'applications Java hébergeant l'application sample.war.

Un arrêt/relance à l'aide de la commande apachectl restart et voici notre configuration pris en compte.

Activation de la console du load-balancer

Activons maintenant la console du load-balancer en ajoutant les lignes suivantes :

<Location /balancer-manager>
  SetHandler balancer-manager
  Order Deny,Allow
  # Deny from all    <- Decommenter ici pour bloquer les accès
  Allow from all #   <- lister les IPs autorisées en les séparant par des virgules
</Location>

Un arrêt/relance sera bien sûr nécessaire pour en profiter.

Utilisation de la console du load-balancer

Il suffit maintenant de rentrer l'URL de notre serveur apache suivi de /balancer-manager pour obtenir l'écran suivant :

De là, vous pourrez désactiver ou réactiver une instance en cliquant sur l'instance à modifier. L'écran en question est le suivant :

Il vous permettra également de modifier certains paramètres de poids sur vos serveurs HTTP/Java.

Pour finir ...

Le gros avantage de ce mécanisme est que vous pourrez ainsi désactiver une instance à la demande et pouvoir ainsi procéder à une maintenance, une mise à jour etc. en limitant au maximum les perturbations.

Pour les plus curieux, je n'ai pas d'autres conseils que d'aller consulter la documentation apache de ce module disponible à l'adresse suivante : http://httpd.apache.org/docs/current/mod/mod_proxy.html.

Patch du jour : NRPE et les sorties longues

2011-03-09T22:22:00.009+01:00

NRPE est vraiment un compagnon inséparable de nagios : lancer des plugins à distance sur un serveur et récupérer leurs résultats au travers d'une simple commande check_nrpe.

Pour l'illustrer, lançons un démon NRPE avec le fichier de configuration suivant :


log_facility=daemon
pid_file=./nrpe.pid
server_port=5666
server_address=127.0.0.1
nrpe_user=nagios
nrpe_group=nagios
allowed_hosts=127.0.0.1
dont_blame_nrpe=0
debug=0
command_timeout=60
connection_timeout=300

command[short_output]=/bin/cat /tmp/test
command[long_output]=/bin/cat /etc/screenrc

Nous y avons défini deux commandes (short_output et long_output) et nous l'avons fait écouter sur l'adresse localhost. Lançons maintenant notre process :


# ./nrpe -c ./nrpe.cfg -d
# ps -ef | grep nrpe
nagios   11411     1  0 22:39 ?        00:00:00 ./nrpe -c ./nrpe.cfg -d
root     11417  6370  0 22:39 pts/4    00:00:00 grep --color=auto nrpe

Essayons maintenant de récupérer le résultat d'une de nos commandes :


$ ./check_nrpe -H localhost -c short_output
Retour NRPE|Short_output=1

Tout semble fonctionner au mieux mais malheureusement dans le cas d'une sortie trop grande, tout ce qui dépasse 1024 ieme octet est ignoré :


$ ./check_nrpe -H localhost -c long_ouput | wc 
     34     160    1024

En creusant un peu, cette limitation vient de la définition d'une constante C dans le fichier include/common.h :

#define MAX_PACKETBUFFER_LENGTH 1024

Ici, la solution qui vient immédiatement à l'esprit est de simplement changer cette valeur et relancer la compilation. Une fois la recompilation terminée, nous obtenons un binaire check_nrpe et un binaire nrpe.

En lançant notre nrpe patché, nous avons effectivement le résultat attendu. Petit soucis, si vous avez déjà des agents NRPE et que vous voulez lancer votre commande check_nrpe sur un ancien serveur, vous obtiendrez une belle erreur vous indiquant un soucis de communication :


$ ./check_nrpe -H localhost -c short_output
CHECK_NRPE: Received 0 bytes from daemon.  Check the remote server logs for error messages.

Si vous êtes comme moi avec environ 300 agents NRPE déjà existant, vous aurez quelques hésitations à les redéployer tous. Heureusement, tonvoon a écrit un patch assez astucieux à ce sujet il y a déjà quelques temps. Le principe est d'utiliser le champ packet_type pour indiquer un nouveau type RESPONSE_PACKET_WITH_MORE en plus des types RESPONSE_PACKET et QUERY_PACKET. Lorsque le plugin check_nrpe détecte ce type de paquet, au lieu de terminer la communication, le client récupère les packets suivants pour les concaténer jusqu'au maximum de 16ko. Et cerise sur le gateau : le plugin check_nrpe reste compatible avec les anciens clients NRPE !

Vous pouvez donc mettre votre plugin check_nrpe à jour et faire la mise à jour au fil de l'eau pour vos agents NRPE voir - si vous êtes vraiment un gros feignant - ne le faire que là où vous en avez besoin.

Pour appliquer le patch, récupérer une copie de NRPE en version 2.12, patcher là avec le fichier suivant puis lancer le classique configure ; make ; make install. Vous obtiendrez alors vos deux binaires à utiliser.

Exemple d'utilisation du répartiteur de charge Haproxy

2011-02-20T18:08:00.005+01:00

Il y a de ça quelques années, j'ai eu l'occasion de travailler sur le répartiteur de charge HAProxy. Le point fort de cet outil est qu'il est très simple à mettre en oeuvre. Nous l'avions à l'époque mis en place pour une boucle de charge avec des serveurs d'applications Java WebLogic.

L'architecture

L'application pour laquelle nous devions mettre en place cette solution était un Webservice hébergé sur des serveurs d'application Weblogic. Il est important de souligner que cette application n'avait pas de notion de session et la persistance s'appuyait sur la librairie hibernate.

Afin de faire face au trafic (supérieur à 300 transactions/secondes), il avait été décidé d'héberger cette application sur 32 d'instances Weblogics réparties sur 4 machines. Nous devions trouver une solution permettant de répartir la charge tout en offrant des possibilités de maintenance de certains noeuds de la boucle de charge. Ceci nous permettait également de faire des évolutions applicatives en pleine journée.

Pourquoi utiliser ce type de répartiteur de charge

Nous disposions de matériel dédié à la répartition de charge (type Alteon) qui ne gère que la répartition de charge au niveau TCP. Cette situation n'était pas satisfaisante puisque nous avions besoin de pouvoir gérer certaines informations au niveau du HTTP (Keepalive et gestion boucle de charge). De plus, les applications venant consulter ce webservice avaient tendance à garder leur connexion HTTP ouverte empêchant la sortie d'instance Weblogic de la boucle de charge.

C'est là où intervient le HAProxy puisque cet outil de répartition de charge comprend le HTTP. Nous pouvions donc nous en servir pour désactiver le Keepalive et garantir qu'à chaque requête, nos clients passe par une nouvelle connexion.

A noter que la désactivation du Keepalive avait un surcoût au niveau CPU : 1 à 2% (sur un V890 équipé de 8 Ultra IV à 1.3 Ghz). Il est important de qualifier ce coût supplémentaire avec des benchs pour ne pas avoir de mauvaise surprise.

Le HAProxy était capable de scrupter une page présente sur le serveur WebLogic lui indiquant s'il doit le prendre en compte où non. Pour cela nous avions créé une page Web (page JSP dans une WAR) nous permettant de débrayer automatiquement une instance via le dépot d'un fichier dans le répertoire properties de nos instances Weblogic.

Création d'une application Web pour gérer la validité d'une instance

Nous allons tout d'abord créer un petit programme java qui va gérer un état d'une page en fonction d'un fichier properties :


package haproxy;

import java.io.File;
import java.io.IOException;
import java.net.URL;
import java.util.ResourceBundle;

import javax.servlet.Servlet;
import javax.servlet.ServletException;

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class HaproxyTestServlet extends HttpServlet {
 public void doGet(HttpServletRequest req, HttpServletResponse resp)
  throws ServletException, IOException {
   if (isAlive()) {
    resp.setStatus(HttpServletResponse.SC_OK);
    resp.getWriter().print("OK");
    return;
   } else {
    resp.sendError(HttpServletResponse.SC_SERVICE_UNAVAILABLE,"Service non disponible");
   }
 }
 protected void doHead(HttpServletRequest req, HttpServletResponse resp)
  throws ServletException, IOException {
  if (isAlive()) {
   resp.setStatus(HttpServletResponse.SC_OK);
  } else {
   resp.setStatus(HttpServletResponse.SC_SERVICE_UNAVAILABLE);
  }
 }
 private boolean isAlive() {
  URL url = this.getClass().getResource("/haproxy.down");
  if (url != null) {
    return false;
  }
  return true;
 }
}

Il nous faut maintenant mapper cette applet au niveau de l'application Web en alimentant le fichier web.xml avec le contenu suivant :


<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp">
  <display-name>TestHaproxy</display-name>
  <servlet>
    <servlet-name>HaproxyTestServlet</servlet-name>
    <display-name>HaproxyTestServlet</display-name>
    <servlet-class>haproxy.HaproxyTestServlet</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>HaproxyTestServlet</servlet-name>
    <url-pattern>/HaproxyTestServlet</url-pattern>
  </servlet-mapping>
  <welcome-file-list>
    <welcome-file>index.html</welcome-file>
    <welcome-file>index.htm</welcome-file>
    <welcome-file>index.jsp</welcome-file>
    <welcome-file>default.html</welcome-file>
    <welcome-file>default.htm</welcome-file>
    <welcome-file>default.jsp</welcome-file>
  </welcome-file-list>
</web-app>

Reste à la mettre en place et de voir le résultat de son déploiement en consultant l'application en rentrant son URL (http://monserver:monport/haproxy/HaproxyTestServlet). Pour désactiver une instance ? Rien de plus simple : créer un fichier haproxy.down dans le répertoire des properties de l'instance. Remettre une instance dans la boucle ? Simplement en supprimant le fichier haproxy.down

Mise en place de la solution

Il faut d'abord créer un fichier de configuration pour notre HAProxy (haproxy.cfg).

Ce dernier contient l'adresse et le port d'écoute (ici host:8888) ainsi que de nombreux paramètres sur son fonctionnement. Ci-dessous un début de fichier de configuration intéressant :


global
 maxconn 4096
 daemon
 nbproc  2
 pidfile /var/run/haproxy-private.pid

listen proxy host:8888
 log global
 mode http
 option httplog
 option dontlognull
 cookie COOKIEID insert indirect nocache
 balance  roundrobin

La liste des serveurs dans la boucle de répartition de charge est représenté par la liste de ligne commençant par server.


        server inst11 web1:7011 check inter 2000 rise 2 fall 5
        server inst21 web2:7021 check inter 2000 rise 2 fall 5
        server inst31 web3:7031 check inter 2000 rise 2 fall 5
        server inst41 web4:7041 check inter 2000 rise 2 fall 5
[...]
        server inst18 web1:7018 check inter 2000 rise 2 fall 5
        server inst28 web2:7028 check inter 2000 rise 2 fall 5
        server inst38 web3:7038 check inter 2000 rise 2 fall 5
        server inst48 web4:7048 check inter 2000 rise 2 fall 5

Indiquons également l'emplacement de notre page de test ainsi que nos paramètres de répartition de charge :


 monitor-uri /haproxy/HaproxyTestServlet
 retries 3
 redispatch
 maxconn 2000
 contimeout 5000
 clitimeout 50000
 srvtimeout 50000

Enfin, dans le cas où vous voudriez désactiver le Keepalive HTTP, rajoutez les lignes suivantes :


 reqidel ^Connection:  # disable keep-alive
 reqadd  Connection:\ close
 rspidel ^Connection:
 rspadd  Connection:\ close

Il ne nous reste plus qu'à lancer le démon haproxy à l'aide de la commande suivante :

haproxy -D -f haproxy.cfg

Conclusion

Dans cet article, nous n'avons vu qu'une toute petite partie des capacités de ce répartiteur de charge. Son auteur (Willy Tarreau) a également inclu des fonctionnalités très intéressantes comme :
- la gestion d'IPV6 (v1.2)
- la gestion des cookies applicatifs pour garder le contexte d'un client vers un seul serveur (v1.2)
- la reconfiguration à chaud (v1.2)
- la répartition de charge avec poids (v1.2)
- la page de diagnostique (v1.2)
- la gestion des contenus statiques/dynamiques (v1.3)

Pour en savoir plus : http://haproxy.1wt.eu/#desc

Installation de shinken et configuration de l'interface Thruk

2010-12-23T14:26:00.012+01:00

J'utilise beaucoup nagios pour mon travail de tous les jours mais c'est un outil qui n'est pas parfait (loin de là! ). J'ai donc lu avec beaucoup d'intérêt le démarrage du projet shinken qui a comme gros avantage d'être beaucoup plus performant et d'être beaucoup plus modulable que son ainé.

Voulant m'en faire une idée pour de vrai, j'ai donc procédé à une installation from scratch. Comme la documentation ne parle pas du tout de l'ajout de l'interface, je laisse donc ici quelques mots à ce sujet.

Installation de shinken

Tout d'abord créer un utilisateur shinken. Très important, il faut un home qui soit valide (sinon, l'arbitrer ne démarre pas !).

Reste ensuite à procéder à l'installation. Ici, rien de plus simple, il faut simplement récupérer le package shinken-0.4.tar.gz puis de le décompresser. Se rendre dans le répertoire shinken-0.4 puis lancer la commande suivante :

sudo python setup.py install --install-scripts=/usr/bin

De là, shinken va créer pas mal de répertoire (notamment /var/lib/shinken et /etc/shinken). Par convenance, j'ai créé un fichier shinken.sh qui me lance tous les éléments dans le bon ordre :


patrice@Enclume:~/tmp/shinken-0.4$ cat /etc/init.d/shinken.sh
#!/bin/bash

cd /etc/init.d

for script in shinken-scheduler shinken-poller shinken-reactionner shinken-broker shinken-arbiter
do
./$script $1
done

De là, il suffit de faire un /etc/init.d/shinken.sh start et c'est parti ! Pour vérifier que tout va bien, il faut s'assurer que les process suivants sont bien présents :


patrice@Enclume:~/tmp/shinken-0.4$ ps -u shinken
PID TTY          TIME CMD
4358 ?        00:00:09 shinken-schedul
4367 ?        00:00:10 shinken-poller
4372 ?        00:00:00 shinken-poller
4380 ?        00:00:09 shinken-reactio
4385 ?        00:00:00 shinken-reactio
4949 ?        00:00:13 shinken-broker
4989 ?        00:00:00 shinken-poller
4990 ?        00:00:00 shinken-poller
4993 ?        00:00:00 shinken-poller
4996 ?        00:00:18 shinken-broker
4997 ?        00:00:00 shinken-broker
5001 ?        00:00:00 shinken-reactio
5004 ?        00:00:00 shinken-poller
5018 ?        00:00:10 shinken-arbiter

Configuration de l'interface Thruk

Ici, il faut récupérer l'interface Thruk à l'emplacement suivant. On la décompresse puis nous nous rendons dedans afin d'y créer un fichier thruk_local.conf. En voici le contenu :


~/tmp/Thruk-0.74$ cat thruk_local.conf
######################################
# Backend Configuration, enter your backends here
<component Thruk::Backend>
   <peer>
       name   = Shinken
       type   = livestatus
       hidden = 0             # make this backend hidden by default
       groups = admins        # make this backend only visible to the admin group
       <options>
           peer    = 127.0.0.1:50000
           verbose = 0
      </options>
   </peer>
</component>

De là, il ne nous reste plus qu'à lancer le démon Thruk :


~/tmp/Thruk-0.74/script$ ./thruk_server.pl
You can connect to your server at http://enclume:3000

NB : Attention, il s'agit d'un test. Il est possible de lancer l'interface Thruk en utilisant un serveur apache mais ce n'est pas l'objet de cet article.

De là, il ne nous reste plus qu'à accéder à l'interface http://localhost:3000 au travers un navigateur :

Bon, il va maintenant falloir que je configure correctement ma map :D Mais bon, ça c'est une autre histoire ;).

Import des données de ndoutils dans pnp4nagios

2010-10-06T22:04:00.004+02:00

Il y a de ça 5 ou 6 mois, j'ai procédé à un refresh à notre infrastructure de suivi nagios. A l'époque nous utilisions un nagios couplé avec NDOUtils pour faire notre suivi de tendance des machines. J'avais par ailleurs créé un plugin permettant de grapher tout ceci en me basant sur la bibliothéque JPGraph.

Malheureusement, entre les problèmes sur la base de données, le fait que je sois sur Solaris (chouette encore un truc à compiler), les problèmes liés au broker nagios (pourquoi ce foutu machin ne veut pas se reconnecter à la base !!!), les problèmes de performance de la base (j'avais mis en place un système de rotation de la table nagios_servicechecks pour m'affranchir des problèmes de dégradation des performances avec le temps), la taille de tout ceci (200 Mo de place par jour pour 600 services !) et le plugin de graph à maintenir, j'ai fini par péter un cable !

Bref, à l'occasion d'un plan de refresh de ma machine, je suis tombé sur pnp4nagios et là, j'ai sérieusement réfléchi à me débarrasser de NDOUtils. En revanche, un point m'embêter : perdre mon historique de 100 jours de l'ancienne base MySQL. J'ai donc à ce moment pensé à utiliser les possibilités d'insertion en mode bulk de pnp4nagios afin de reconstituer mon historique.

Au démarrage, j'ai procédé par une extraction via un ensemble de scripts shells. J'ai ensuite procédé à un refactoring de ce script afin de le réécrire en perl que j'ai ensuite proposé à l'équipe de pnp4nagios. Ils m'ont simplement proposé de le déposer sur leur wiki à l'emplacement suivant.

Le script en question s'appelle ndo2pnp.pl et vous trouverez ci-dessous l'aide en ligne disponible sur l'outil :


$ ./ndo2pnp.pl --help
Usage :
-h  --help            Display this message.
    --version         Display version then exit.
-v  --verbose         Verbose run.
-u  --user ndouser    Log on to database with ndouser (default root).
-p  --pass passwd     Use passwd to logon (default gbu2kfe).
-t  --type dbtype     Change database type (default mysql).
    --host dbhost     Use dbhost (default localhost).
    --dbname db       Use db for ndo database name (default ndoutils).
    --list-machine    Display machine definition in ndo database.
    --list-service    Show services defined.
    --export-as-pnp   Export ndo content as a bulk file used by process_perfdata.pl.
>

Globalement, pour procéder à votre export/import, il faut suivre les étapes suivantes :

Extraction du contenu de la base : ./ndo2pnp.pl --user mysql_user -p mysql_pass --export-as-pnp > /tmp/perfdata.bulk

Import de l'extraction :/usr/share/pnp4nagios/libexec/process_perfdata.pl -b /tmp/perfdata.bulk --timeout 0

Quoi ? C'est tout ! Euh, juste une petite précision : l'import a duré 4 jours sur ma machine de production :). Un conseil : essayez de faire des extracts machine par machine (avec l'option --machines MAMACHINEAEXTRAIRE ou --services MESSERVICESAEXTRAIRE que j'ai oublié de documenté d'ailleurs ... Pas beau !). Les imports seront du coup moins long à faire (et éventuellement en parallèle) et peuvent vous donner une idée du résultat final sans avoir à vous coltiner l'intégralité de l'import de vos données.

Le résultat de tout ceci se trouve ci-dessous :

Toute la partie de décembre à février et le résultat de l'import (plus les quelques jours parasites d'octobre et novembre, date à laquelle nous avions eu des soucis avec la base MySQL). Vous remarquerez qu'entre temps, la base s'est alimentée avec de nouvelles valeurs.

Utilisation d'un robot avec Mediawiki

2010-09-05T10:15:00.000+02:00

Il y a de ça quelques temps, j'ai eu l'occasion de travailler sur un robot de mise à jour automatique des populations sur les articles des communes de Charente-Maritime. Le principe est assez simple : les articles de commune utilisent tous un système de modèle afin de donner un aspect uniforme à tous les articles. Jetons un coup d'oeil au code source de l'article Wikipedia sur la ville de La Rochelle :


{{Infobox Communes de France
| nomcommune         = La Rochelle
| image              = La Rochelle Vieux-Port.JPG
| image-desc         = Les tours du vieux-port de La Rochelle
[...]
| insee              = 17300
| cp                 = 17000
| maire              = [[Maxime Bono]]
[...]
| km²                = 28.43
| sans               = 76848
| date-sans          = 2007
| aire-urbaine       = 186271
| nomhab             = Rochelaise, Rochelais
| siteweb            = http://www.ville-larochelle.fr/
| géoloc-département = Charente-Maritime
}}

Comme vous pouvez le constater, l'article utilise un modèle Mediawiki (ici le modèle Infobox Communes de France) et utilise des paramètres nommés (aire-urbaine=186271 par exemple). L'idée de l'automate est donc de venir modifier les paramètres sans et date-sans (respectivement la population et la date de ce recensement) à partir de fichier plat. Ceci bien sûr afin d'éviter de faire le travail de mise à jour des centaines de communes de France à la main.

Pour les plus curieux, le code source du robot se trouve à l'adresse suivante : DroopigBot sur google code

Bref, le robot a fonctionné sur les communes de Charente-Maritime (ainsi que sur une partie de la Vendée) et m'a donné une idée lumineuse : alimenter automatiquement notre wiki de documentation interne. En effet, nous avions tout un tas de site différent dispersé avec des fonctionnalités différentes :

Un inventaire de machine

Un spip de documentation (avec une version complètement obsolète)

Un inventaire par mail de nos instances de serveurs Java

Mais également plein de chose avec des fichiers plats dans plein d'endroit différent

J'ai donc récupéré le code que j'avais utilisé pour mes communes afin d'en faire quelque chose de plus simple sous la forme d'un script d'extraction et de mise à jour de contenu d'article.

Je ne vais pas tout vous présenter mais juste l'utilitaire en ligne de commande qui me permet de faire cette mise à jour : update_article.sh. Vous pouvez le récupérer à l'adresse suivante : http://code.google.com/p/droopigbot/source/browse/#svn/trunk/public_html.

Pour le configurer, c'est assez simple : créer un utilisateur avec droit d'écriture sur votre mediawiki, créer un fichier robot_config.inc.php avec les informations de connexion. Ci-dessous un exemple pour ce fichier :

$robot = new DroopigBot("Nomdubot", "passdubot", "http://addresse-du-serveur/wiki");
?>

Une fois enregistré, votre robot est prêt à fonctionner. Faisons un test simple d'extraction :


drayan@robert:~/dev/droopigbot/public_html$ ./update_article.sh --name 'Page de test' --dump
Un article de test.

Alimentons maintenant un fichier pour mettre à jour cet article :

drayan@robert:~/dev/droopigbot/public_html$ cat > essai.txt
Mon article a été mise à jour.

Et j'en suis très content.

Lançons la mise à jour :

drayan@robert:~/dev/droopigbot/public_html$ ./update_article.sh --name 'Page de test' --update ./essai.txt --no-simulation --message 'Mise à jour par un robot'
Updating 'Page de test' with './essai.txt' content

Si on jette un coup d'oeil à l'article, nous voyons qu'il a été mis à jour :

Allons maintenant voir l'historique :

Reste maintenant plus qu'à faire vos scripts de mise à jour de votre wiki :)

Sortie de pnp4nagios 0.6.5

2010-07-11T11:55:00.007+02:00

Juste un petit billet pour signaler la sortie de pnp4nagios en version 0.6.5. Un rapide coup d'oeil sur le changelog nous donne les nouveautés suivantes (par rapport à la version 0.4.x) :

Interface Web se basant sur le moteur Kohana, thème jQuery et utilisation de plugin jQuery
process_perfdata.pl peut utiliser plusieurs bases RRD par source nagios
Nouvelle fonctionnalitée d'installation : possibilité de spécifier l'emplacement des fichiers layout (-–with-layout)
Lors d'une erreur de rendu, les erreurs sont affichées sous la forme d'image.
Les templates d'affichage ne peuvent plus changer la valeur des variables internes.
Possibilité d'utiliser les templates des versions 0.4.x.
Refonte du code PDF ainsi que pour les pages.
Optimisation du Template par défaut (default.php)
Export des bases RRD au format XML, CSV et JSON en utilisation la fonction RRDtool "xport"
Les erreurs font pointer sur la FAQ en ligne.
Plugin permettant d'afficher les graphiques dans un popup.
Support du rrdcached

Une fonctionnalité que je n'ai pas encore eu le loisir de tester est la partie "special template" qui permet apparemment de récupérer des informations sur plusieurs machines en même temps pour les afficher sur un même graphique. Une application de cette nouvelle fonction pourrait être de disposer d'un graphique indiquant le trafic en temps réel de 4 machines frontales Web.

Autre fonctionnalité nouvelle sur la version 0.6.5, la présence de fonction d'aide à la création de template (voir la page suivante : http://docs.pnp4nagios.org/pnp-0.6/tpl_helper). Ces fonctions vous permettront de simplifier la prise en main des outils RRD. Quelques exemples d'utilisation :

Définir une nouvelle source de données RRD : $def = rrd::def('var1', $RRDFILE[0], $DS[0], 'MAX');
Définir un gradient : $def .= rrd::gradient('var1', '#ff0000', '#ffff00' );
Afficher une ligne : $def .= rrd::line1('var1', #ff00ff );

Autre point qui pourrait vous intéresser, j'ai reversé une traduction française de l'interface.

Compilation NRPE sous AIX 5.3 avec support du SSL

2010-06-25T21:58:00.004+02:00

J'ai eu dernièrement besoin de compiler un agent nagios NRPE pour AIX 5.3. Malheureusement pour moi, cet OS est livré sans librairie dynamique openssl (ie libssl.so). J'ai donc du compiler nrpe en static.

N'ayant pas trouver d'information intéressante sur le net (en dehors de désactiver le ssl), je me suis dit que ce genre d'information pourrait être utile à d'autre.

Tout d'abord, modifier le fichier configure de la manière suivante (sur une version 2.12 de nrpe) :


$ diff configure.orig configure
6673c6673
<                       if test -f "$dir/libssl.so"; then
---
>                       if test -f "$dir/libssl.a"; then
6687c6687
<                       LIBS="$LIBS -lssl -lcrypto";
---
>                       LIBS="$LIBS $ssllibdir/libssl.a $ssllibdir/libcrypto.a";

Le patch consiste à changer la nature du fichier recherché (libssl.a à la place de libssl.so) et remplacer les flags de compilation -lssl et -lcrypto par les fichiers des bibliothèques que l'on vient de trouver.

Il ne reste plus qu'à lancer configure avec les options suivantes :

./configure --with-ssl=/opt/freeware --with-ssl-lib=/opt/freeware/lib --prefix=/opt/nagios

Un coup de make ; make install et vous disposez maintenant des binaires nrpe et check_nrpe à la mode AIX et surtout avec le support du SSL.

Problème de performance avec pnp4nagios sous Solaris

2010-06-24T20:50:00.011+02:00

Depuis quelques temps déjà, je devais mettre en place pnp4nagios combiné à un nagios 3.2 sur une nouvelle machine. Auparavant, je passais par une machine un peu vieillotte (un sunfire V210 avec 2 Go de mémoire) que je devais remplacer par une plus récente (à base de M5000 Sun). L'ancienne plateforme passait par un nagios combiné avec ndoutils (un backend de stockage des données de performance sous MySQL). Cette plateforme était très contraignante pour plusieurs raisons :

Plugin de génération de graphique maison (c'est votre serviteur qui avait écrit ça)
Scripts de gestion du contenu de la table nagios_servicechecks : je découpais cette table en journée pour pouvoir supporté le volume de données (environ 200 Mo/jour et 17 Go d'historique)
Lenteur de la solution : nagios et le module de base de données (ndo2db) n'était pas très consommateur mais en revanche, la base MySQL était très consommatrice de ressource disque et CPU.

Bref, pour toutes ces raisons et après un rapide tour des solutions existantes, nous avions décidé de partir sur l'excellent plugin pnp4nagios pour l'historisation. Avec ce plugin, plus de serveur MySQL, moins d'IO, plus de script de maintenance. Bref, que du bonheur.

C'est donc assez confiant qu'il y a quelques jours que nous avons procédé à la mise en production. Mais comme toujours, j'ai eu une mauvaise surprise lors de la migration. Lors de la fin de la bascule de tous nos anciens services sur la nouvelle (environ 900 services), j'ai commencé à voir des messages d'erreurs m'indiquant un time out lors du lancement du script process_perfdata.pl au bout de 5 secondes. En y regardant de plus près, j'ai constaté que le timeout était fixé par la directive perfdata_timeout=5 et en urgence, j'ai donc fixé le timeout à 30 s.

Une fois ce contournement mis en place, j'ai pu regarder en détail le problème. J'ai notamment constaté que la machine passait énormément de temps à faire ses mises à jour. En rajoutant quelques traces, je me suis rendu compte que le script process_perfdata.pl n'utilisait pas la bibliothéque native perl RRD mais le binaire rrd ! Suite à quelques tests que j'avais pu faire il y a quelques temps sur les deux modes de fonctionnement, j'ai essayé de voir si le problème ne pouvait pas venir de là.

Après un coup d'oeil à la configuration de nagios et je suis tombé sur cette partie :

define command {
  command_name    process-service-perfdata-file
  command_line    /bin/perl /usr/share/pnp4nagios/libexec/process_perfdata.pl --bulk=/var/nagios/service-perfdata
}

define command {
  command_name    process-host-perfdata-file
  command_line    /bin/perl /usr/share/pnp4nagios/libexec/process_perfdata.pl -d HOSTPERFDATA --bulk=/var/nagios/host-perfdata
}

Rien de bien choquant mais le problème est que sous Solaris la version de RRD venant de sunfreeware s'installe dans /usr/local. Problème, ce dernier est livré avec un binding perl prévu pour la version 5.8.8. Malheureusement, la version installée par défaut (ie dans le répertoire /usr/bin) est une version 5.8.4 et n'est pas en mesure d'utiliser la bibliothéque native perl de RRD.

Bref, j'ai donc changé la version de perl par celle se trouvant dans /usr/local/bin :

define command {
  command_name    process-service-perfdata-file
  command_line    /usr/local/bin/perl /usr/share/pnp4nagios/libexec/process_perfdata.pl --bulk=/var/nagios/service-perfdata
}

define command {
  command_name    process-host-perfdata-file
  command_line    /usr/local/bin/perl /usr/share/pnp4nagios/libexec/process_perfdata.pl -d HOSTPERFDATA --bulk=/var/nagios/host-perfdata
}

Un coup d'arrêt relance et après quelques temps, j'ai obtenu une nette diminution au niveau des temps de traitement de perfdata :

Zoom sur la partie basse :

C'est ici qu'on constate tout l'intérêt de l'utilisation de la bibliothéque native RRD : on est passé à des temps de traitement d'environ 30s à des temps de traitement de l'ordre de la seconde.

Supervision de WebLogic à l'aide de nagios

2010-06-23T10:12:00.000+02:00

Afin de surveiller la consommation mémoire de nos instances WebLogic, j'ai commencé à écrire un plugin se basant sur le protocole SNMP.

Pour ceux qui ne le saurait pas, WebLogic est un serveur d'application Java propriétaire.

Ce besoin de surveillance vient du fait que les serveurs les hébergeants (des Sun V890 avec 40 Go de mémoire) sont sur le point d'arriver à saturation mémoire. Pour cette raison, nous avons donc essayé de savoir quelles instances consommées et à quelle hauteur.

Il faut dire que nous avons constaté que la mémoire allouée aux JVMs étaient le double de la mémoire physique ! Pour info, la machine héberge une centaine d'instance WebLogic en version 8.1 et Java 1.4. Comme vous vous en doutez, nous avons prévu de faire le ménage dans nos instances. Mais pour ça, il nous faudrait un petit état des lieux, d'où l'écriture d'un script.

Passons maintenant à l'écriture du script.

Premier point, il faut se débrouiller pour activer l'agent SNMP au niveau du domaine WebLogic. Nous pourrons ainsi interroger le serveur sans avoir à faire de couteuses interrogations à base de programme en java. Nous allons ensuite nous baser sur l'outil snmpwalk.

Pour mémoire, une page de référence de la MIB de ce serveur d'application est disponible à l'adresse suivante : http://download.oracle.com/docs/cd/E13222_01/wls/docs90/snmp/index.html

Commençons tout d'abord par interroger l'agent SNMP WebLogic en ligne de commande :

drayan@robinet:~$ snmpwalk -m ./BEA-WEBLOGIC-MIB.mib -c public -v 1 192.168.0.10:7061 .1.3.6.1.4.1.140.625.180

La branche .1.3.6.1.4.1.140.625.180 correspond aux informations sur les threads Java actifs. Nous pouvons également interroger la branche .1.3.6.1.4.1.140.625.340.1 pour récupérer la quantité de mémoire consommée (jvmRuntimeHeapSizeCurrent). A noter que pour connaître les instances présentes dans le domaine WebLogic, je fais appel à la branche 1.3.6.1.4.1.140.625.361.1.

Une fois enrobé tout ceci j'obtiens le script suivant :

#!/usr/bin/perl
use strict;
use File::Basename;
use Sys::Hostname;
use Getopt::Long;

my $verbose      = 0;
my $show_help    = 0;
my $show_version = 0;
my $snmp_address = 0;
my $instance     = 0;
my $snmp_cmd     = "snmpwalk -m ".dirname($0)."/../share/BEA-WEBLOGIC-MIB.mib";
my $show_only    = ".*";

sub usage {
my ($msg) = @_;
$msg = "" if(!$msg);
my $name = basename($0);
print "Usage :
  \$ $name [OPTION]

Get runtime information about  WebLogic instance
  -h  --help                   display this help and exit.
      --intance <SRVNAME>[,<>] name of the instances to check.
      --only <REGEXP>          show only instance corresponding to regexp.
      --snmp <HOST[:PORT]>     address (and port) of the snmp server.
  -v  --verbose                verbose.

Examples:
  \$ $name --port 10861 --instance srvback11,srvback12,srvback13,srvback14
".($msg ? "\n".$msg."\n" : "")
}

GetOptions(
"V"          => \$show_version,
"version"    => \$show_version,
"h"          => \$show_help,
"help"       => \$show_help,
"v"          => \$verbose,
"verbose"    => \$verbose,
"snmp=s"     => \$snmp_address,
"instance=s" => \$instance,
"only=s"     => \$show_only,
);

if($show_help) { usage(); exit(0); }
die("Please specify snmp address (--snmp host:port)") if(!$snmp_address);

if(!$instance) {
my(%instance_name, %instance_state) = ((), ());
my @tmp = ();
my ($i, $j) = (0, 0);
foreach(`$snmp_cmd -c public -v 1 $snmp_address 1.3.6.1.4.1.140.625.361.1 2> /dev/null`) {
if(/BEA-WEBLOGIC-MIB::serverLifeCycleRuntimeName.*STRING: "(\w+)"/) {
 $instance_name{$i++} = $1;
} elsif(/BEA-WEBLOGIC-MIB::serverLifeCycleRuntimeState.*STRING: "(\w+)"/) {
 my $label = $instance_name{$j++};
 $instance_state{$label} = $1;
 if($1 =~ /RUNNING/) {
   print "$label is RUNNING\n" if($verbose);
   push(@tmp, $label);
 } else {
   print "Ignoring $label\n" if($verbose);
 }
}
}
$instance = join(",", @tmp);
}

my $perfdata = "";
foreach my $srv(sort(split(/,/, $instance))) {
next if(!($srv =~ /$show_only/));
my @result = `$snmp_cmd -c public\@$srv -v 1 $snmp_address .1.3.6.1.4.1.140.625.340.1 2> /dev/null`;
my($label, $current_max_heap, $free_heap);
foreach(@result) {
if(/BEA-WEBLOGIC-MIB::jvmRuntimeName.*STRING:\s+"(\w+)"/) { $label = $1; }
elsif(/BEA-WEBLOGIC-MIB::jvmRuntimeHeapFreeCurrent.*INTEGER:\s+(\d+)/) { $free_heap = $1; }
elsif(/BEA-WEBLOGIC-MIB::jvmRuntimeHeapSizeCurrent.*INTEGER:\s+(\d+)/) {
 $current_max_heap = $1;
 $current_max_heap = int($current_max_heap / 1048576 + .5);
 $free_heap        = int($free_heap / 1048576 + .5);
 my $used = $current_max_heap - $free_heap;
 $perfdata .= " $label=$used;$current_max_heap;$current_max_heap;0;$current_max_heap";
}
}
}

print "WebLogic memory OK|$perfdata\n";

On configure notre agent pour accepter un nouveau type de commande :

command[check_weblogic_memory]=/usr/lib/nagios/plugins/check_weblogic --snmp localhost:7061

On configure un nouveau service sous Nagios :

define service {
host_name   machine-weblogic
use    generic-service
service_description  Suivi memoire WebLogic
check_command   check_nrpe!check_weblogic_memory
}

Et hop ! Au bout de quelques jours, vous obtenez le résultat suivant (en combinaison avec pnp4nagios) :

Recyclage d'une miroir SDS sous ZFS

2010-05-31T18:29:00.010+02:00

ATTENTION !!! Dans ce qui va suivre, je vais vous expliquer comment mettre en place un pool ZFS. Cette manœuvre supprimera entièrement le contenu de votre ancien FS. Pensez à faire des sauvegardes de vos anciennes données !!!

Il y a peu de temps, j'ai eu à préparer une machine Solaris (une T5120 pour les plus curieux d'entre vous). A l'origine cette machine n'utilisait que du SDS (un mirroring software livré en standard sous Solaris) en combinaison avec les slices Solaris (l'équivalent des partitions classiques sous Linux). Comme on ne peut faire que 7 slices et que 5 slices étaient déjà pris pour le système et que la machine n'avait que deux disques, je me suis donc trouvé très rapidement bloqué pour la création de nouveaux FS. Auparavant, pour contourner ce problème, nous utilisions le mécanisme de lofs de Solaris (l'équivalent de l'option de montage bind sous Linux). Mais je n'étais pas vraiment enchanté de la situation ...

J'ai donc décidé de recycler un slice des deux disques qui étaient auparavant alloué à un device SDS afin de le réaffecter à un pool ZFS. En effet, avec ZFS, plus de problème de limitation de slice, de problème de mirroring, de création de FS, etc. Bref quelque chose d'un petit peu plus poussé en terme de fonctionnalité.

Pour démarrer, nous allons jeter un coup d'oeil au miroir existant avant de le casser. Tout ceci se fait à l'aide de la commande metastat :


$ metastat d6
d6: Miroir
 Sous-miroir 0: d16
   Etat : Ok        
 Sous-miroir 1: d26
   Etat : Ok        
 Accès : 1
 Option de lecture : roundrobin (par défaut)
 Option d'écriture : parallel (par défaut)
 Taille : 179891328 blocs (85 GB)

d16: Sous-miroir de d6
 Etat : Ok        
 Taille : 179891328 blocs (85 GB)
 Bande 0 :
     Périphérique     Bloc de débu Base          Etat Redis Tranche dynamique
     c1t0d0s6                0     Non             Ok   Oui
[...]

Nous avons donc un device d6 constitué de deux sous-miroirs d16 et d26 eux-même étant les slices 6 des disques c1t0d0 et c1t1d0 (soit respectivement les slices c1t0d0s6 et c1t1d0s6). Nous allons donc supprimer tout ceci à l'aide de la commande metaclear :
- suppression du mirroir :

metaclear d6

- puis suppression des sous-mirroirs :

metaclear d16

metaclear d26

Maintenant que nous avons deux slices de disponible, nous allons les allouer à un pool ZFS en mirroir que l'on appellera zfs_pool :

$ zpool create -f zfs_pool mirror c1t0d0s6 c1t1d0s6

NB : ne pas oublier l'option '-f'. Dans notre cas, comme les devices étaient anciennement utilisé en tant que partition ufs, zpool refuse de créer le pool zfs avec le message suivant :

$ zpool create zfs_pool mirror c1t0d0s6 c1t1d0s6
spécification vdev incorrecte
utilisez '-f' pour ignorer les erreurs suivantes :
/dev/dsk/c1t0d0s6 contient un système de fichiers ufs.

Et voilà ! Notre pool ZFS est prêt !

Tentons maintenant de créer un FS :

$ zfs create -o mountpoint=/data zfs_pool/data

Et voilà ! Le FS est monté, formaté et prêt à l'emploi. A remarquer que par défaut, il n'y a aucune limitation dans l'utilisation du FS et qu'il est possible d'utiliser tout l'espace du pool. Bien sûr, il est possible de limiter l'utilisation à l'aide de l'option quota. Ceci peut se faire avec la commande zfs set :

$ zfs set -o quota=10G zfs_pool/data

Vérifions le résultat :

$ df -h /data
Filesystem             size   used  avail capacity  Mounted on
zfs_pool/data           10G     8K    10G     1%    /data

Et voilà, je pense que ça sera tout pour aujourd'hui.

Problème de buffer nrpe

2010-05-27T18:52:00.005+02:00

Cet après-midi, j'ai commencé à mettre en place une surveillance de tablespace sur Oracle. Petit soucis, j'ai dépassé sans trop m'apercevoir la limite du buffer de nrpe (1024 pour un résultat).

Autre petit problème, il est impossible de modifier la taille du buffer sans avoir à recompiler la commande check_nrpe et - petit bonus - le client check_nrpe obtenu est incompatible avec les anciens démons NRPE.

Donc, retour à l'ancienne version et du coup, j'ai modifié ma commande de surveillance pour faire mes stats en deux fois :).

Connexion via ipmi sur un serveur

2010-05-20T22:01:00.009+02:00

Je suis plutôt habitué au console Solaris mais il se trouve que récemment, j'ai eu l'occasion de bosser sur une console ipmi. Le principe est le même, à savoir une console texte accessible via le réseau.

Comment est-ce qu'on arrive à s'intéresser à ce genre de problème allez vous me demander ? Et bien simplement, j'ai eu besoin de modifier les paramètres du BIOS sur une machine d'un client qui se trouve chez un hébergeur. Et il est vrai que sans accès physique à la machine, on se trouve bien bête :).

Assez parlé, commençons l'activation de l'ipmi sur notre serveur. Il nous faut tout d'abord installer ipmitool :

# apt-get install ipmitool

Nous allons maintenant charger le module kernel ipmi :

# modprobe ipmi_si
# modprobe ipmi_devintf
# lsmod | grep ipmi
ipmi_devintf           13200  0
ipmi_si                43628  0
ipmi_msghandler        38520  2 ipmi_devintf,ipmi_si

Tout semble bon. Ajoutons maintenant le module au redémarrage :

# echo "ipmi_devintf" >> /etc/modules
# echo "ipmi_si" >> /etc/modules

Nous allons maintenant définir un utilisateur qui puisse se connecter à la console (nous utilisons ici l'id 8 pour l'utilisateur operator du fait que la société qui nous héberge utilise déjà les 7 premiers identifiants pour ses propres besoins) :

# ipmitool -U root user set name 8 operator
# ipmitool -U root user set password 8 operatorpass
# ipmitool -U root user enable 8

Nous allons maintenant essayer de nous connecter à la console :

ipmitool -I lanplus  -U operator -P operatorpass -H 10.10.10.10 sol activate

Malheureusement, nous allons nous retrouver bloquer puisque personne n'écoute. Néanmoins, si nous rebootons notre serveur, il nous permettra d'accéder au bios (le but de ce billet !). Un rapide coup de F2 au redémarrage et nous voyons apparaître l'écran suivant :

Activons ensuite le support Intel de virtualisation :

Il faudra ensuite arrêter électriquement la machine et la redémarrer à l'aide de l'interface Web de l'hébergeur.

Notre mission est terminée mais pourquoi s'arrêter en si bon chemin ? Nous allons ajouter la gestion de grub ainsi que celle de la console de Linux.

Pour la gestion de la console dans grub, il faut rajouter les lignes suivantes dans le fichier /boot/grub/menu.lst :

serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal --timeout=15 serial console

Et ensuite mettre à jour grub :

grub-install /dev/sda

Enfin, ajoutons le support du port série sur le kernel linux. Il faut pour cela ajouter console=tty0 console=ttyS0,9600n8 dans la ligne de démarrage du kernel. Exemple :

kernel          /vmlinuz-2.6.26-2-amd64 root=/dev/md1 ro quiet console=tty0 console=ttyS0,9600n8

Multiple vs single datasource sous pnp4nagios

2010-05-19T21:01:00.009+02:00

Voici maintenant quelques temps que nous utilisons pnp4nagios et je n'avais - jusqu'à maintenant - pas eu à me plaindre de ce produit plus que ça. Malheureusement, aujourd'hui, je suis tombé sur un os : la gestion des données de performances changeante. Dit comme ça, ça peut ne pas sembler complètement évident mais vous allez très vite comprendre que ça peut devenir embêtant ...

Sous nagios, les données de performances (ce qu'on retrouve après le '|' sous la forme param1=i;warn-i;crit-i;min-i;max-i param2=j) est en principe tout le temps identique. Malheureusement, vous l'aurez deviné, les choses ne sont pas toujours simple et vous pouvez rencontrer des commandes qui à un moment vous donnez un certain résultat et qui le moment d'après vous sorte un résultat d'une autre forme. Ce type de désagrément arrive dans les cas suivants :
- changement du comportement d'un script
- changement des indicateurs surveillés (comme dans check_disk par exemple).

Dans ce cas, pnp4nagios perd un peu la boule et du coup, remplace des séries de données par d'autre et plus embêtant, fait un mélange in fine entre les différentes séries. Ce petit désagrément m'est arrivé cet après-midi et j'ai donc regarder un peu si j'étais la seule personne a qui c'était arrivé. Donc en épluchant la documentation, j'ai compris qu'il s'agissait de l'utilisation des datasources de type SINGLE vs MULTIPLE sous RRD. Plus simplement, dans le cas d'un RRD SINGLE (par défaut), toutes les données sont stockées dans un seul fichier. Très pratique pour réduire le bazard dans un répertoire. En revanche, dès que mes sources changent, c'est l'anarchie. L'autre option MULTIPLE quand à elle va créer un datasource par source de données.

C'est bien beau vous allez me dire mais qu'est ce que je fais du coup de mes 6 mois d'historique ? Et bien là, mauvaise nouvelle pour l'instant, il faudra restaurer le fichier avant le changement de datasource ... Ensuite, le script rrd_convert.pl est là pour faire le découpage des fichiers et - cerise sur le gateau - positionner un fichier de configuration dans le répertoire etc/check_commands de pnp4nagios afin de préciser au script process_perfdata.pl de ne plus utiliser un datasource SINGLE mais MULTIPLE.

Ci-dessous, quelques exemples de l'utilisation de cette commande :
- Consultation des commandes disponibles :


$ /usr/share/pnp4nagios/libexec/rrd_convert.pl --list_commands
XML Files analyzed                       14
XML Files found                          0
Old XML Files ignored                    1
Number of unique check_commands          7
\ List of Check Commands
 |- check-host-alive                         7
 |-                                          2
 |- check_ping                               1
 |- check_load                               1
 |- check_all_disks                          1
 |- check_users                              1
 |- check_http                               1

- Etat des indicateurs sur mon nagios de test avant conversion :


$ ls -ltr Current_Load.*
total 6084
-rw-rw-r-- 1 nagios nagios 1151496 2010-05-19 20:46 Current_Load.rrd
-rw-rw-r-- 1 nagios nagios   12872 2010-05-19 20:46 Current_Load.xml

- Lancement de la conversion :


$ /usr/share/pnp4nagios/libexec/rrd_convert.pl --check_command=check_load

Search pattern                           check_load
XML Files analyzed                       14
XML Files found                          1
Old XML Files ignored                    1
Number of unique check_commands          7
Start Converter [n|Y]?:Y

Config for command check_load created (/usr/share/pnp4nagios/etc//check_commands/check_load.cfg)
File 1/1
RRDtool dump to /tmp/rrd_convert/localhost-Current_Load.dump
Manipulating /tmp/rrd_convert/localhost-Current_Load.dump
............ done 48166 lines
Restoring File
/var/spool/pnp4nagios/perfdata/localhost/Current_Load_load1.rrd
/var/spool/pnp4nagios/perfdata/localhost/Current_Load_load15.rrd
/var/spool/pnp4nagios/perfdata/localhost/Current_Load_load5.rrd
... done
DONE


 \Statistics:
 |- runtime         3.048887
 |- rrd_out         3
 |- old_xml         1
 |- rrd_in          1

- Etat après la conversion :
$ ls -ltr Current_Load*


-rw-rw-r-- 1 nagios nagios 1151496 2010-05-19 20:51 Current_Load.rrd
-rw-rw-r-- 1 nagios nagios   12840 2010-05-19 21:21 Current_Load.xml
-rw-r--r-- 1 nagios nagios  384952 2010-05-19 21:21 Current_Load_load5.rrd
-rw-r--r-- 1 nagios nagios  384952 2010-05-19 21:21 Current_Load_load1.rrd
-rw-r--r-- 1 nagios nagios  384952 2010-05-19 21:21 Current_Load_load15.rrd

Le fichier Current_Load.rrd existe toujours, mais au vu de la date du fichier, il n'est plus alimenté. Nous pouvons également jeter un coup d'oeil dans le répertoire etc/check_commands de pnp4nagios :


$ more /usr/share/pnp4nagios/etc/check_commands/check_load.cfg 
# Generated by rrd_convert.pl 0.6.3
RRD_STORAGE_TYPE = MULTIPLE

Comme nous pouvons le voir, l'outil rrd_convert.pl a bien créé un fichier pour la commande check_load afin de lui indiquer que le type de stockage étant maintenant MULTIPLE.

Demain, nous testerons ça sur des vrais données de recette !

Personnalisation de PNP4Nagios : écriture d'un template

2010-05-15T16:05:00.009+02:00

L'import de mon historique ndoutils sous pnp4nagios s'est bien passé et j'ai maintenant quelques courbes avec lesquels je peux m'amuser. J'ai notamment personnalisé l'aspect des courbes CPU afin d'y faire apparaître une tendance sur une certaine période. Pour info, j'ai mis à disposition le plugin à l'emplacement suivant : http://docs.pnp4nagios.org/templates/check_cpu

Nous allons voir ensemble comment fonctionne la création de template pour pnp4nagios. Pour cela, il suffit de se rendre dans le répertoire de pnp4nagios dans le sous-répertoire share/templates. De là, on va créer un nouveau fichier et nous allons commencer à personnaliser l'aspect de nos graphiques (ici check_cpu.php).

Ce qu'il faut savoir avant de commencer est que l'interface pnp4nagios génère des fichiers PNG à l'aide des RRDTools. Notre template est donc en réalité un petit programme en PHP qui initialisera les valeurs envoyé au programme RRDTool.

Commençons tout d'abord par changer le titre de notre graphique :


#
# Copyright (c)  2010 Yannig Perre
# Plugin: check_cpu
#
$ds_name[1] = "Activité CPU";

$opt[1] = "--vertical-label CPU -l0  --title \"Activité CPU sur $hostname\" ";

Nous allons maintenant définir les périodes pendant lesquelles nous allons dessiner une tendance :


$trend_array = array(
  "one_month"    => array(strtotime("-1 month", $this->TIMERANGE['end']), $this->TIMERANGE['end'], "Tendance sur 1 mois:dashes=10", "#FF007F", "LINE3"),
  "global_trend" => array($this->TIMERANGE['start'], $this->TIMERANGE['end'], "Tendance globale:dashes=20", "#707070", "LINE2"),
);

Ci-dessous, nous définissons simplement les sources de notre graphique.

NB : Nous allons cumuler les valeurs des sources afin d'obtenir un graphique sous forme d'aire (io en haut du graphique, user puis consommation système). Pour se faire nous utilisons la notion de CDEF des outils RRDs :


$def[1] =  "DEF:var1=$RRDFILE[1]:$DS[1]:AVERAGE " ;
$def[1] .= "DEF:var2=$RRDFILE[2]:$DS[2]:AVERAGE " ;
$def[1] .= "CDEF:user=var2,var1,+ " ;
$def[1] .= "DEF:var3=$RRDFILE[3]:$DS[3]:AVERAGE " ;
$def[1] .= "CDEF:io=var3,var2,+,var1,+ " ;

Une fois nos sources redéfinies, nous allons maintenant définir nos tendances en fonction du tableau $trend_array que nous avons définit précédemment :


$trend_elements = "";

foreach(array_keys($trend_array) as $trend) {
  $def[1] .= "DEF:var1$trend=$RRDFILE[1]:$DS[1]:AVERAGE:start=".$trend_array[$trend][0]." ";
  $def[1] .= "DEF:var2$trend=$RRDFILE[2]:$DS[2]:AVERAGE:start=".$trend_array[$trend][0]." ";
  $def[1] .= "CDEF:user$trend=var2$trend,var1$trend,+ " ;

  $def[1] .= "VDEF:dtrend$trend=user$trend,LSLSLOPE ";
  $def[1] .= "VDEF:htrend$trend=user$trend,LSLINT ";
  $def[1] .= "CDEF:curve_user$trend=user$trend,POP,dtrend$trend,COUNT,*,htrend$trend,+ ";
  $trend_elements .= $trend_array[$trend][4].":curve_user$trend".$trend_array[$trend][3].":\"".$trend_array[$trend][2]."\" " ;
}

Ici, on rajoute les valeurs de warning et critical si présente :


if ($WARN[1] != "") {
    $def[1] .= "HRULE:$WARN[1]#FFFF00 ";
}
if ($CRIT[1] != "") {
    $def[1] .= "HRULE:$CRIT[1]#FF0000 ";       
}

Enfin, nous allons dire aux RRD tools de dessiner 3 graphiques d'aire : les io en premier (en vert), la consommation user en bleu et enfin la consommation système en dernier. A noter que nous ajoutons des lignes noirs pour mieux définir les 3 aires.


$def[1] .= "AREA:io#00FF00:\"iowait\" " ;
$def[1] .= "GPRINT:var3:LAST:\"%6.2lf\" " ;
$def[1] .= "GPRINT:var3:AVERAGE:\"moy %6.2lf\" " ;
$def[1] .= "GPRINT:var3:MAX:\"max %6.2lf\\n\" " ;
$def[1] .= "AREA:user#005CFF:\"user  \" " ;
$def[1] .= "GPRINT:var1:LAST:\"%6.2lf\" " ;
$def[1] .= "GPRINT:var1:AVERAGE:\"moy %6.2lf\" " ;
$def[1] .= "GPRINT:var1:MAX:\"max %6.2lf\\n\" ";
$def[1] .= "AREA:var2#FF5C00:\"sys   \" " ;
$def[1] .= "GPRINT:var2:LAST:\"%6.2lf\" " ;
$def[1] .= "GPRINT:var2:AVERAGE:\"moy %6.2lf\" " ;
$def[1] .= "GPRINT:var2:MAX:\"max %6.2lf\\n\" " ;
$def[1] .= "LINE1:io#000000:\"\" " ;
$def[1] .= "LINE1:user#000000:\"\" " ;
$def[1] .= "LINE1:var2#000000:\"\" " ;
$def[1] .= $trend_elements;

Voici notre fichier template terminée, il ne nous reste plus qu'à consulter le résultat sur l'interface PNP. Voici ce que j'obtiens par exemple après quelques petits réglages au niveau de la tendance sur une de mes machines sur 6 mois d'historique :

Compilation NRPE et génération d'un binaire statique sous Solaris 8 ou 10

2010-05-12T23:14:00.010+02:00

On va pas aller jusqu'à dire qu'en ce moment Nagios soit toute ma vie mais en tout cas, au taff, ça occupe pas mal mes journées. Donc, je vais essayer de sortir les astuces que j'ai pu utiliser pour arriver à compiler NRPE et les plugins de surveillance standard.

Donc, pour la compilation, récupérer le source de NRPE, le décompresser et commencer par modifier le fichier src/nrpe.c de la manière suivante :


617c617
<               log_facility=LOG_AUTHPRIV;
---
>               log_facility=LOG_AUTH;
619c619
<               log_facility=LOG_FTP;
---
>               log_facility=LOG_DAEMON;

Une fois la modification terminée, il nous faut maintenant lancer configure avec les options suivantes :

./configure --prefix=/path/to/nagios --with-ssl=/usr/local/ssl/lib

NB : Ici il faut s'assurer d'avoir télécharger un compilateur GCC et OpenSSL depuis le site www.sunfreeware.com.

Lancez ensuite la compilation. En principe, vous devriez obtenir un nrpe fonctionnel mais lié aux librairies situées dans /usr/local/lib et autant vous dire, vous n'aurez jamais cette librairie présente sur vos machines Solaris.

Pour cette raison, nous allons donc générer un binaire statique pour ne plus avoir de dépendance sur openssl. Pour se faire, se rendre dans le répertoire src et relancer manuellement la compilation de nrpe avec la commande suivante :


gcc -g -O2 -I/usr/local/ssl/include/openssl -I/usr/local/ssl/include -DHAVE_CONFIG_H -o nrpe-static \
  nrpe.c utils.c -lsocket -L/usr/local/ssl/lib  /usr/local/ssl/lib/libssl.a /usr/local/ssl/lib/libcrypto.a \
  -lnsl -lsocket  ./snprintf.o

Pour info, voici le résultat sous Solaris 10 :


$ ls -l nrpe nrpe-static
-rwxr-xr-x   1 root     root      118888 mars 19 14:42 nrpe
-rwxr-xr-x   1 root     root     1349532 mars 19 14:41 nrpe-static

Le binaire est maintenant parfaitement fonctionnel. Il ne vous reste plus qu'à le déployer sur vos machines.

Import en cours

2010-05-11T21:05:00.004+02:00

J'ai lancé mon script d'import de ma base ndo MySQL vers pnp4nagios. J'ai compté, il y en a pour environ 25 minutes par jour et j'ai environ 130 jours à importer. Après avoir parallélisé un peu les traitements j'ai réussi à descendre à 15 minutes pour chaque jour. Chouette, ça me fera donc environ 30 heures d'import ...

Courage ! On va y arriver.

Test du module RRD perl

2010-05-10T22:50:00.004+02:00

Je suis en ce moment en train de finir mes scripts de migration de la base MySQL ndoutils vers des bases RRD gérées par pnp4nagios.

Globalement, le script est terminé et je suis juste en train de faire quelques tests. A cette occasion, j'ai voulu connaître le différentiel de performance entre RRD via le binaire et via la bibliothèque Perl.

Pour se faire, j'ai donc écrit le script suivant :


#!/usr/bin/perl
use RRDs;
$use_system = 1;

$current = time();
$step = 30;
$range = 3600 * 24 * 7;
$start = $current - $range;
print "Début : ".scalar(localtime())."\n";
if($use_system) {
  system("rrdtool create test.rrd --start $start --step $step DS:valeur_test:GAUGE:600:U:U RRA:AVERAGE:0.5:1:".($range / $step));
} else {
  RRDs::create("test.rrd", "--start", $start, "--step", $step, "DS:valeur_test:GAUGE:600:U:U", "RRA:AVERAGE:0.5:1:".($range / $step));
}

$j = 0.;
$| = 1;
$i = 0;
for($t = $start; $t < $current; $t += $step) {
  $value = int(200.5 + cos($j) * 100.);
  if($use_system) {
    system("rrdtool update test.rrd $t:$value");
  } else {
    RRDs::update("test.rrd", "$t:$value");
  }
  $j += 0.001;
  $i++;
}
print "Insertion de $i valeurs\n";
if($use_system) {
  system("rrdtool graph speed.png --start $start --end $current DEF:def=test.rrd:valeur_test:AVERAGE LINE1:def#000000 -w 1000 -h 400");
} else {
  RRDs::graph("speed.png", "--start", $start, "--end", $current,
            "DEF:def=test.rrd:valeur_test:AVERAGE", "LINE1:def#000000", "-w", 1000, "-h", 400);
}
print "Fin   : ".scalar(localtime())."\n";
system("gwenview speed.png");

En gros, le script génère une sinusoïde que j'affiche ensuite sous gwenview (prenez votre lecteur d'image préféré).

Un rapide test nous donne le résultat suivant :
* via l'utilisation de la bibliothèque :


drayan@robinet:~/nagios/RRD$ ./generate_rrd.pl 
Début : Mon May 10 22:45:56 2010
Insertion de 20160 valeurs
Fin   : Mon May 10 22:45:57 2010

* via l'utilisation des binaires :


Début : Mon May 10 22:46:08 2010
ERROR: test.rrd: illegal attempt to update using time 1272919568 when last update time is 1272919568 (minimum one second step)
Insertion de 20160 valeurs
1081x449
Fin   : Mon May 10 22:48:57 2010

Donc 1 seconde contre environ 3 minutes dans le second cas. On va donc passer par la bibliothèque !

Utilisation de pnp4nagios

2010-05-08T14:15:00.003+02:00

pnp4nagios est un ensemble de script perl, PHP et C qui vont vous permettre de récupérer les métriques de nagios (les perfdata) dans des bases RRD. Ces bases vous permettront ensuite de générer des graphiques à l'aide d'une petite interface Web. La force de cet outil est de s'appuyer sur un outil simple et éprouvé : les outils RRD.

Il peut se configurer de trois manières différentes (si on compte la variante à base de NCPD) :
- mode synchrone. Il s'agit du mode le plus simple à mettre en oeuvre.
- mode asynchrone/nagios. Ici, nagios va écrire les perfdatas dans un fichier avant d'être traité par lot à interval régulier par un script pnp4nagios.
- mode asynchrone/NCPD. Ce mode est proche du précédent à la différence que la gestion du traitement se fera à l'aide d'un démon dédié à ce travail.

Comme toujours, le mode de fonctionnement dépendra du nombre d'élément que vous souhaitez surveiller. De mon point de vue, une petite infrastructure (inférieur à un ou deux milliers de services) pourra très bien fonctionner en mode synchrone. Au delà, il faudra se poser la question de mettre en place un mode asynchrone. Sachez que le premier mode asynchrone viendra bloquer nagios pendant les moments d'import des données. Sur très grosse infrastructure avec des surveillances distribués, il sera donc préférable de choisir le dernier mode.

Pour ma part, n'étant pas encore obligé de faire de la surveillance décentralisé (à l'aide de DNX par exemple), j'ai choisi la seconde solution pour son bon compromis performance/complexité. En effet, le dernier mode entrainte forcément l'ajout d'un démon supplémentaire.

Bref, après une petite période de test, je suis en train de commencer à déployer cet outil sur notre infrastructure. J'étudie également l'importation des anciens résultats de notre base ndo/MySQL afin de disposer dès le départ de l'ancien historique. J'ai déjà écrit les scripts d'export de la base et je suis en train de peaufiner les détails. Dès que j'aurais terminé cette petite migration, je viendrai vous en faire part ici même.