Recyclage d'une miroir SDS sous ZFS

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

et

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

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

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

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

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

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

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

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

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.