Supervision avec Nagios 1

Nagios est un moniteur de supervision. Successeur de NetSaint, logiciel libre reconnu dans le monde de la supervision, utilis par les
plus grands oprateurs, il permet une supervision active et passive de serveurs, quipements rseaux, et surtout de services divers et
varis.
Trs puissant, mais utilisant des principes simples, il reste nanmoins complexe mettre en uvre dans un environnement de
production.

1 )Concepts de supervision
La supervision est un ensemble de concepts recouvrant la surveillance du bon fonctionnement d'une production. Les diffrentes
possibilits de supervision sont en gros les suivantes :
Supervision via SNMP (y compris la mtrologie) : Nagios peut utiliser SNMP pour surveiller par exemple les quipements rseau.
Supervision des journaux : est aussi simple faire qu'un tail sur /var/log/messages. Plus pratiquement, cela passe maintenant par
l'utilisation d'un serveur syslog centralisant les messages, coupl un analyseur temps-rel de ces messages. (Consulter Locust)
Supervision active des services et infrastructures.

Via des greffons (plugins), Nagios propose de simuler le fonctionnement du client d'une application (comme un client HTTP pour un
service Web) pour valider le bon fonctionnement de cette application. Les greffons peuvent aussi effectuer les actions entreprendre
pour vrifier qu'un systme de fichier n'est pas satur.
Mais superviser simplement sans prendre d'action ne sert pas grand chose.
Nagios intgre un moteur de gestion d'alertes, avec escalades, ces alertes tant diffuses soit par le biais de l'interface Web (avec alerte
sonore via un champ EMBED), par courriel (pourvu que le serveur Nagios voie son serveur de messagerie local interconnect avec la
messagerie d'entreprise) ou par tout autre biais imaginable travers une commande.
On peut mme imaginer prendre des actions correctives directement sur la dtection d'un problme. Par exemple, redmarrer un
processus serveur Web qui montre des signes de faiblesse.
Nagios permet en standard de satisfaire la plupart de ces besoins, hormis la mtrologie, mais plusieurs projets peuvent aider sur ce
besoin prcis.

2 )Concepts de supervision avec Nagios

Nagios permet donc une supervision active et passive de serveurs, quipements rseaux, et surtout de services divers et varis.
Il utilise des principes simples, mais reste nanmoins complexe mettre en oeuvre dans un environnement de production, du fait de sa
grande souplesse de configuration et d'utilisation ; et ce d'autant plus que le nombre d'objets (matriels et services) configurer est
important.
Ces derniers peuvent de plus avoir des dpendances plus ou moins fines entre eux, ce qui peut encore augmenter le temps de mise en
uvre.

2.1 )Architecture
L'architecture de base de Nagios est simple :
Un ordonnanceur : Nagios est d'abord un moteur grant l'ordonnancement des vrifications, ainsi que les actions prendre sur
incidents (alertes, escalades, prise d'action corrective) ;
Une IHM : la partie graphique visible travers un simple serveur Web, tel Apache, est base (pour les versions jusqu' la 2.0) sur
des CGI ;
Des sondes : les sondes de Nagios (les greffons ou plugins) sont de petits scripts ou programmes qui sont la base des vrifications.
Le projet Nagios fournit en standard bon nombre de greffons de base, mais la simplicit de leur mode de fonctionnement permet d'en
crire pour besoins propres, que ce soit pour superviser SAP par exemple ou pour vrifier que des clients peuvent bien se connecter sur
l'intranet.

2.2 )Principes de base

Nagios est, entre autre, un moteur d'ordonnancement de vrifications diverses et varies.
Ces vrifications sont assures par des greffons (plugins en anglais), dont le dveloppement est spar du moteur principal (pour les
greffons de base).
La relation entre le moteur et les greffons est assure :
d'une part dans la configuration de Nagios, pour que Nagios sache quelles vrifications lancer sur ou destination de quelles
machines ou services,
d'autre part par le code retour ainsi que la sortie standard d'un greffon.
Supervision avec Nagios 2
En effet, un greffon n'est qu'un script(programme) qui doit fournir un code retour (0 : tout va bien ou OK, 1 : avertissement ou
WARNING, 2 : alerte ou CRITICAL et 3 : UNKNOWN ), et ventuellement un petit message dcrivant le droulement de l'excution
(aide au diagnostic en cas de problme).

Ce sont les tats (code retour des greffons) qui seront ensuite remonts au moteur devant prendre les dcisions et lancer les actions
programmes.

Ces greffons fonctionnent soit en local sur la machine supervise (par exemple les vrifications sur les disques), soit effectuent des tests
distance (tests sur des protocoles rseaux tels SMTP ou excution distance via SSH ou autre).

Les vrifications peuvent tre passives (rarement ou dans certains cas o la scurit impose d'interdire une connexion dans un sens, ou
encore dans le cas de supervision hirarchique), mais le plus souvent actives.

2.3 )Mise en rseau de la supervision

Les greffons locaux au serveur de supervision sont excuts directement par Nagios. La vrification d'un service distance (par
l'excution d'un greffon situ sur une autre machine, par exemple, ou par SNMP), se fait, elle aussi, par le biais de l'excution d'un
greffon local au serveur Nagios.

Pour l'excution de greffons distance, plusieurs possibilits :

Par le biais d'autres serveurs de supervision Nagios distants : Dans le cas de supervision distribue qui concentrent les vrifications
sur un site distant, et ne remontent que les problmes.

Les agents de transport ou d'excution des tests, tels :

NRPE, (le Nagios Remote Plugin Executor) permet l'excution de plugins distance, choisir parmi un certain nombre de
services disponibles.
NSCA (Nagios Service Check Acceptor) permet de son ct la remonte d'informations de faon passive (vu du point de vue de
Nagios).
check_by_ssh, qui suppose la cration de comptes non privilgis sur les machines, accessibles par l'utilisateur qui excute le
daemon Nagios, et qui ont les droits suffisants pour lancer les plugins ncessaires. Cette dernire solution a des implications en
termes de scurit.
NSCIient++, greffon lourd pour des serveurs Windows surveiller.
Winrpe (Nagios NRPE For Wibndows)
check_snmp, pour la supervision de valeurs SNMP travers le rseau.

L'ordonnancement des vrifications est assur de faon locale chaque machine, et surtout permet d'inverser le sens des connexions
entre serveur supervis et serveur superviseur, ce qui peut avoir un intrt dans un rseau scuris, avec des pares-feu en diode (ne
laissant passer les flux que dans un sens).

La diffrence entre NRPE et NSCA est l'initiateur de la vrification : NRPE reoit (1) la demande de vrification de la part de Nagios,
excute la vrification (2), puis renvoie le rsultat(3).
Alors qu'avec NSCA, la vrification est planifie en local, excute (1), puis le rsultat en est envoy Nagios (2).
Notons que la plupart de ces moyens supposent un greffon local au serveur Nagios, que ce soit check_nrpe, check_nt pour
NSCIient++, ou encore check_by_ssh et check_snmp.
Supervision avec Nagios 3
2.4 )tats hard et soft
Nagios fait la distinction entre les alertes en tat soft et celles en tat hard. Ds qu'un service remonte une erreur, celle-ci est d'abord
dfinie dans un tat soft et Nagios met ses alertes sonores habituelles. Si aprs un certain nombre d'essais infructueux, configurable, le
service renvoie toujours le mme type d'erreur, l'alerte passe alors en tat hard et Nagios envoie ses notifications (courriel, SMS, etc.).
L'tat hard dfinit donc une alerte reconnue par Nagios comme posant rellement un problme, il ne s'agit pas d'un greffon qui a
accidentellement renvoy une mauvaise valeur. Ces valeurs seront rutilises plus bas avec les gestionnaires d'vnements.

2.5 )Les escalades

Nagios supporte de faon optionnelle l'escalade des notifications envoyes aux contacts pour des services ou htes. Ainsi, on peut
dfinir diffrents groupes de personnes et donc diffrents moyens de contacter ces personnes en fonction du nombre de notifications
dj envoyes.
Il est possible par exemple, sur certaines alertes, contacter quelques personnes s'occupant de la supervision par courriel, puis si le
problme persiste aprs un temps dtermin, les contacter par SMS ou bien contacter d'autres intervenants.

3 )Configuration

3.1 )Configuration de Nagios : Apache

Dans le fichier httpd.conf d'Apache, inclure le fichier nagios.conf crire.
Includeconf/nagios.conf
Le fichier nagios.conf va contenir les directives suivantes :
Dfinition des correspondances entre rpertoires et URLs relatives
ScriptAlias /nagios/cgi-bin/usr/
Alias /nagios /usr/share/nagios/html

Notez que l'URL /nagios/cgi-bin doit tre dfinies avant /nagios car sinon, elle ne serait pas prise en compte car masque.

Cela permettra de pointer un navigateur sur le serveur Web o Nagios est install, grce une URL du style : http://monserver/nagios/.
CrationdesdclarationsdesrpertoirescorrespondantauxURLs
<Directory/usr/share/nagios/cgibin>
Allow0verrideAuthConfig
OptionsExecCGl
Orderdeny,allow
Allowfromall
AuthTypeBasic
AuthName"Nagios"
AuthUserFile/etc/nagios/htpasswd
<LimitGETPOST>
Requirevaliduser
</Limit>
</Directory>
<Directory/usr/share/nagios/html>
AllowOverrideAuthConfig
OptionsIndexesFollowSymLinks
Orderdeny,allow
Allowfromall
AuthTypeBasic
AuthName"Nagios"
AuthUserFile/etc/nagios/htpasswd
<LimitGETPOST>
Requirevaliduser
</Limit>
</Directory>

3.2 )Authentification
L'accs Nagios doit tre restreint, car il peut montrer des informations importantes voire confidentielles.
De plus, des actions peuvent tre entreprises via l'interface Web, actions qui vont de l'acquiescement d'une alarme au redmarrage d'un
serveur si l'event handler est dfini.
Supervision avec Nagios 4
La dfinition des rgles d'authentification est dj crite ci-dessus, il reste renseigner le fichier /etc/nagios/htpasswd. Cela se fait par
le biais de l'utilitaire htpasswd fourni avec Apache.

#htpasswd[c]/etc/httpd/htpasswdnagios
Newpassword:******
Retypenewpassword:******
Updatingpasswordforusernagios

Cet utilisateur nagios doit correspondre non l'utilisateur au sens POSIX cr plus haut, mais un contact dfini dans
/etc/nagios/contacts.cfg.

3.3 )Configuration Nagios

Les fichiers de configuration de Nagios se trouvent dans le rpertoire /etc/nagios.
Ces fichiers de configuration, l'exception des fichiers nagios.cfg et cgi.cfg, utilisent une structure unique de dfinition des objets sur
le principe suivant :
define{
param1value
param2value
...
paramnvalue
}
Cela implique qu'aucun espace ne pourra tre insr dans les valeurs des paramtres. Il faudra donc y faire attention. Pour tester la
cohrence de vos fichiers de paramtrage, utilisez la commande :
#/usr/bin/nagiosv../etc/nagios.cfg
ou, si le script de lancement /etc/init.d/nagios a t install :
servicenagiosreload
ou encore, si la distribution n'a pas fournit le script service (qui devrait tre obligatoire) :
/etc/init.d/nagiosreload
qui cumule vrification de configuration et lancement de Nagios.

3.4 )Objets de Nagios

Au commencement est le serveur (host). Ce serveur n'est pas tout seul, il doit donc pouvoir le dfinir ainsi que ses congnres, qui
peuvent ne pas tre des serveurs, mais tout quipement dot d'une interface rseau. Ces htes peuvent tre regroups dans un ou
plusieurs groupes, par exemple sur critres technologiques (les linux avec les linux, etc.), par clients .... Ce regroupement peut
permettre d'agir sur un ensemble de machines, par exemple si l'on a prvu d'arrter toute la plate-forme d'un client qui a 8 serveurs,
nous prvoirons un arrt sur le groupe du client, plutt que perdre du temps prvoir l'arrt sur chacun des serveurs. Viennent ensuite
les services. Ces services correspondent en fait au produit des machines par les greffons et par les paramtres qui peuvent leur tre
appliqus.

Si une machine a 200 systmes de fichiers, il sera fait 200 fois appel au greffon check_disk, chaque fois avec en paramtre le nom
du systme de fichier vrifier, et avec les seuils de criticit associs. Idem pour le greffon check_proc, qui peut compter les
processus actifs, les processus zombies, et les processus swaps. Donc trois services diffrents. Ces services s'appuient sur des greffons,
qu'il faut donc dfinir. C'est le rle des clauses command, qu'on retrouvera gnralement dans un fichier de configuration
checkcommands.cfg.

L'ordonnancement de la vrification des services se fait selon des calendriers dfinis par les clauses timeperiod (fichier
timeperiods.cfg).
Le rle de Nagios est donc de prvenir un contact lorsqu'un problme survient. C'est le rle des fichiers contacts.cfg (clauses
contact) et contactgroups.cfg. L'escalade des avertissements et autres alertes entre les diffrents groupes d'intervenants se
faisant dans le fichier escalations.cfg..
Enfin, les commandes externes, non-destines au lancement de greffons, sont centralises dans le fichier misccommands.cfg, tel
que l'envoi de courriels, de SMS (via l'utilisation d'outils tiers), etc.

D'autres fichiers :
Supervision avec Nagios 5
dependencies.cfg qui dfinit les dpendances entre services (sur le mme serveur ou sur des serveurs diffrents, clause
servicedependency), par exemple tel serveur Web virtuel dpend de la prsence d'un processus Apache ;
cgi.cfg pour la configuration des services CGI qui font la partie graphique de Nagios ;
hostextinfo.cfg : les petits plus graphiques (icnes, coordonnes des objets sur la carte graphique) pour les quipements ;
serviceextinfo.cfg : la mme chose, mais pour les services.

3.5 )Les patrons

L'arrive en 2002 de Nagios 1.04beta a vu l'introduction des patrons (templates) de configuration. Inutile donc, si l'on a plusieurs
serveurs identiques (Linux, Solaris ...) et quipements rseau des mmes constructeurs, avec des contraintes de disponibilit identiques,
de dupliquer manuellement les mmes paramtres sur chacun. Cela simplifie la lecture (seule l'information directement pertinente est
visible la dfinition du serveur/service), si l'on doit modifier manuellement les timeperiods de 200 services sur plusieurs serveurs
diffrents. Avec les patrons, il suffit de modifier le patron des services de chaque serveur, voire de modifier le patron des patrons si les
diffrents serveurs fournissent une mme application.
Exemples :
#definitiondupatronpardfaut
defineservice{
name genericservice ;lenomdupatron
register 0 ;objetnonenregistrecarc'estunpatronet
;nonunvraiservice
active_checks_enabled 1
passive_checks_enabled 1
parallelize_check 1
check_freshness 0
notifications_enabled 1
event_handler_enabled 1
flap_detection_enabled 0
retain_status_information 1
retain_nonstatus_information 1
notification_interval 120
notification_period 24x7
notification_options w,c,u,r
max_check_attempts 3
is_volatile 0
normal_check_interval 3
retry_check_interval 1
check_period 24x7
contact_groups networkadmins
}

Un patron voit un grand nombre de paramtres configurs, en fait, exactement les mmes que pour un service normal.
La seule diffrence se fait dans le paramtre register, positionn 0, qui fait que la dfinition est considre comme un patron.

Un patron peut tendre les informations d'un autre patron :

defineservice{
name switch1service
register 0
use genericservice ;Onluiditd'utiliserlesinfodupatron'genericservice'
host_name switch1
}

Enfin, voici comment utiliser le patron pour dfinir un service Ping :

#exempledeserviceutilisantunpatron
defineservice{
use switch1service ;ildoitutiliserlesinfodecepatron
service_description Ping
check_command check_ping!200,50%!400,80%
}
Supervision avec Nagios 6
3.6 )Notifications et escalades
Nagios vrifie rgulirement l'ensemble des services sur le parc configur. Cet intervalle de temps est configurable pour chaque service
l'aide du champ normal_check_interval. Si le greffon renvoie un tat diffrent de OK, une alerte en tat soft est leve. Nagios
vrifiera autant de fois que max_check_attempts lui indique le service toutes les retry_check_interval minutes
d'intervalle. Si celui-ci reste en erreur aprs tous les essais, une premire notification est envoye.

Si aprs un intervalle de notification_interval minutes, le problme n'est toujours pas rgl, Nagios enverra une autre
notification et continuera ainsi jusqu' ce que le problme soit rsolu ou acquitt.

Dans certains cas, il peut tre utile de mettre en place des escalades sur les services. Le principe est simple, pour chaque service o l'on
souhaite une escalade des notifications, il suffit de prciser quels groupes de contacts Nagios devra envoyer les notifications. Cela se
fait en fonction du nombre de notifications envoyes.
Voici un petit exemple :
defineserviceescalation{
host_name switch1
service_description Ping
first_notification 3
last_notification 5
notification_interval 90
contact_groups networkadmins,managers
}
defineserviceescalation{
host_name switch1
service_description Ping
first_notification 6
last_notification 0
notification_interval 60
contact_groups toutlemonde
}

On continue ici l'exemple des patrons : on possde un quipement rseau dsign par switch1. Par dfaut, les notifications sont
envoyes toutes les deux heures (120 minutes dans le patron par dfaut) au groupe de contacts networkadmins. Grce aux
escalades que l'on vient de configurer, si le problme est toujours prsent de la troisime notification (first_notification) la
cinquime (last_notification) et toutes les 90 minutes (notification_interval), celle-ci sera envoye aux groupes de
contacts networkadmins et managers.
Enfin, si au bout de six notifications au total, l'alerte continue, Nagios avertira les gens du groupe de contacts toutlemonde
indfiniment (d'o le 0 dans le champ last_notification) une priode de 60 minutes. Dans tous les cas, toutes les personnes
qui ont reu la notification de l'erreur recevront la notification de retour la normale du service.

3.7 )Les gestionnaires d'vnements (event-handlers)

Les gestionnaires d'vnements sont des commandes externes optionnelles qui sont excutes chaque fois qu'un changement d'tat
d'un hte ou d'un service a lieu. Une utilit triviale de ces gestionnaires d'vnements (particulirement pour les services) rside dans la
capacit de Nagios rsoudre les problmes de manire prventive avant que quelqu'un ne reoive une notification. Une seconde utilit
est celle d'enregistrer les vnements relatifs aux htes ou services dans une base de donnes externe.
Dans la plupart des cas, les commandes de gestionnaires d'vnements seront des scripts crits en shell ou en Perl. Ils doivent
comporter au moins les macros suivantes comme arguments :
Macrosdegestionnaired'vnementsdeservice:$SERVICESTATE$,$STATETYPE$et$SERVICEATTEMPT$;
Macrosdegestionnaired'vnementsd'hte:$HOSTSTATE$,$STATETYPE$,$HOSTATTEMPT$.
Les scripts examinent les valeurs des arguments qui leur sont passs et excutent les actions ncessaires en fonction de ces valeurs.
Voir plus bas le principe de mise en redondance de Nagios comme exemple.

3.8 )La cosmtique

A l'aide des informations additionnelles sur les quipements, il est possible d'ajouter des logos, des descriptions, un lien telnet (qui
connat l'URL pour faire du SSH ?) vers les machines, etc. Tout a vous permettant de reconnatre facilement et accder directement
d'autres informations sur vos quipements.
Exemple :
Supervision avec Nagios 7
definehostextinfo{
host_name ts10001
icon_image base/cyclades_ts.gif
vrml_image base/cyclades_logo.png
statusmap_image base/cyclades_ts.png
icon_image_alt ServeurTerminaux
}
L'icne donne dans le champ icon_image sera affiche chaque fois ct du nom de la machine. Le champ vrml_image
renseigne sur l'image utilise dans la vue en 3D. statusmap_image est utilis dans la carte 2D (status map). Enfin, le texte donn
dans icon_image_alt sera affich en texte alternatif de l'icne.

On pourrait aussi ajouter un lien qui serait affich dans les informations de l'quipement avec le champ notes_url qui pourrait par
exemple pointer un logiciel de mtrologie.

Ou encore complter les champs 2d_coords et 3d_coords pour fixer l'emplacement de la machine sur les cartes 2D et 3D.

! Attention cependant la dfinition du chemin relatif vers les images. Les chemins se donnent de faon relative un rpertoire logos
(nom cod en dur, nous semble-t-il) du rpertoire image. Ce rpertoire image tant lui-mme un sous-rpertoire de la partie Web de
Nagios, ou plus exactement d'un paramtre de configuration des CGI. Ce paramtre est physical_html_path, et pourrait pointer
sur /usr/share/nagios.

4 )Les greffons

4.1 )Les greffons officiels

Les greffons officiels sont disponibles sur SourceForge, projet nagios-plug.
Ils sont diviss en deux catgories : les greffons principaux ( core plugins ) et les greffons dits contribus, qui ne sont pas forcment
maintenus, mais nanmoins distribus dans l'archive officielle.
D'autres greffons existent, mais sont bien souvent d'un usage limit car destins un usage particulier. Il est possible d'interroger un
moteur de recherche ( Nagios et plugin mots-cls indispensables).
La compilation des greffons officiels (pour ceux crits en langage C) ne posent pas de problme particulier, sinon qu'il faut bien
videmment prter attention aux dpendances, en particulier les bibliothques permettant d'crire des clients de service rseau, radius
ou LDAP tant des exemples.

4.2 )crire un greffon

L'criture d'un greffon doit respecter deux rgles : lgret et simplicit. En effet, ce greffon doit passer inaperu dans son excution,
au sens o il ne doit pas se faire sentir sur la charge globale de la machine, et doit rester simple dans l'esprit d'un greffon Nagios. ce
titre, il doit accomplir une tche et une seule, mais le faire bien. Rappelons le but du greffon : renvoyer un code retour, ainsi qu'un petit
texte explicatif sur sa sortie standard.
Exemple : certains serveurs n'ont plus de disques SCSI sur une carte RAID. Vrifions que les miroirs logiciels mis en uvre sous
Linux fonctionnent correctement. Le greffon suivant va donc devoir lire le pseudo-fichier /proc/mdstats, analyser son contenu,
ventuellement croiser avec /etc/fstab ou /proc/mounts (pour viter de forker un nouveau processus, ce qui prendra du temps et des
ressources) afin de fournir le point de montage du systme de fichier en plus du priphrique RAID qui dfaille.
Tout d'abord, voici le script :
#!/usr/bin/perlw
usestrict;
usewarnings;
useEnglish;
useGetopt::Long;
usevarsqw($PROGNAME$opt_V$opt_h$opt_t);
uselib"/home/utilisateur/cvs/nagios/nagiosplugins1.4.0alpha1/pluginsscripts";
useutilsqw(%ERRORS&print_revision&support);
useData::Dumper;
$PROGNAME="check_linuxraid";
$REVISION='$:check_linuxraid.pl,v1.12006/03/2908:33:29utilisateurExp$';
subprint_help();
subprint_usage();
Supervision avec Nagios 8
my(%data,%slices,%types,%status,%alerts,%rcs);
my$msg='';#emptystring
Getopt::Long::Configure('bundling');
Get0ptions(
"V"=>\$opt_V,"version"=>\$opt_V,
"t"=>\$opt_t,"test"=>\$opt_t,
"h"=>\$opt_h,"help"=>\$opt_h
);
if($opt_V){
print_revision($PROGNAME,$REVISION);
exit$ERRORS{'OK'};
}
if($opt_h){
print_help();
exit$ERRORS{'OK'};
}
if(!$opt_t){
if(!openDATA,'</proc/mdstat'){
print"Unabletoopen/proc/mdstat\n";
exit$ERRORS{'UNKNOWN'};
}
}
while(<DATA>){
my$curdev;
chomp;
if(m/^(md\d+)\s*:\s*(.*)$/){
$curdev=$1;
$data{$curdev}=$2;
}
$data{$curdev}.="$1"ifm/^\s+(.*)$/;
}
foreachmy$md(keys%data){
foreach(split//,$data{$md}){
push@{$slices{$md}},$_if/\w+\[\d+\]/;
$types{$md}=$_if/raid\d/;
$status{$md}=$1if/\[([U_]+)\]/;
}
if($status{$md}=~/_/){
my$p=1;
while(($p=index($status{$md},'_',$p+1))!=1){
push@{$alerts{$md}},$slices{$md}[$p];
}
}
#onsortunCRITICALsidesmiroirsn'ontqu'unepatte
if($types{$md}eq'raid1'&&@{$slices{$md}}==0){
$rcs{'CRITICAL'}++;
$msg.="$md(2fewdev)";
}
}
#printDumper%slices,\%types,\%alerts,\%status;
foreachmy$md(keys%alerts){
$msg.="$md(";
foreachmy$slice(@{$alerts{$md}}){
$msg.="$slice";
if($slice=~/\(F\)/){
$rcs{'CRITICAL'}++;
}
elsif($data{$md}=~/recovery/){
#careconstruit
$msg.="rebuilding";
$rcs{'WARNING'}++;
}else{
#ilyadescasouledevicen'estpasfailed,et0lemiroirn'est
#pasactifnonplus(bugdudrivermd)
$rcs{'CRITICAL'}++;
}
}
$msg.=")";
}
my$rc=$rcs{'CRITICAL'}?$ERRORS{'CRITICAL'}:($rcs{'WARNING'}?$ERRORS{'WHARNING'}:$ERRORS{'OK'});
$msg=~s/\(\s/\(/g;
my%t=reverse%ERRORS;
Supervision avec Nagios 9
$msg="ALLRAIDdevicessane(".join(',',keys%data).")"
if$rc==$ERRORS{'OK'};
print"$t{$rc}:$msg\n";
closeDATA;
exit$rc;
subprint_usage(){
print"Usage:\n";
print"$PROGNAME\n";
print"$PROGNAME[hIhelp]\n";
print"$PROGNAME[V|version]\n";
print"$PROGNAMEt\n";
}
subprint_help(){
print_revision($PROGNAME,$REVISION);
print"Copyright@2004utilisaeur\n\n";
print_usage();
print"\n";
print"Usettotestthescript,/proc/mdstatsourceusedisinternaltothescript\n";
print"\n";support();
}

RESULTAT
_DATA_
Personalities:[raid1]
read_ahead1024sectors
md0:activeraid1sdb5[1]sda5[0]4200896blocks[2/2][_U]
md1:activeraid1sdb6[1]sda6[0]2104384blocks[2/2][UU]
md2:activeraid1sdb7[1]sda7[0]2104384blocks[2/2][UU]
md3:activeraid1sdc7[1]sdd8[2]sde5[0]1052160blocks[2/2][UU]
md4:activeraid5hdh1[3]hdg1[2]hdf1[1]hde1[0]360182016blockslevel5,256kchunk,algorithm2[4/4][UUUU]
md5:activeraid5sdf1[2]sde1[3]sdg1[l]sdd1[4]sdc1[0]1638144blockslevel5,64kchunk,algorithm0
[5/5][UUUUU]
md6:activeraid5sde2[7]sdf2[4]sdg2[3]sdd2[6]sdc2[2]sdb2[1]sda2[0]104196864blockslevel5,64k
chunk, algorithm 0 [7/6] [UUUUU_U] [===>.................] recovery = 17.0% (2966244/17366144)
finish=119.2minspeed=2011k/sec
md7:activeraid1hde5[0](F)hdf7[1]39262720blocks[2/1][_U]
md8:activeraid1sda5[0]4200896blocks[1/1][U]
unuseddevices:none

On utilise dans ce script un module venant des plugins Nagios : utils.pm. Il dfinit le hash qui sera utilis par la suite pour la
dfinition du code retour : %ERRORS, dfini comme suit :
%ERRORS=('OK'=>0,'WARNING'=>1,'CRITICAL'=>2,'UNKNOWN'=>3,'DEPENDENT'=>4);
Rien de bien sorcier dans l'criture de ce script, sinon que l'utilisation du hash %ERRORS permet d'viter les impairs et d'avoir un nom
sur un code retour (Attention nanmoins ne pas faire de faute d'orthographe dans l'criture de CRITICAL ou de WARNING, voire de
UNKNOWN).
L'option t permet de tester le script en situation avec les donnes.
Pour utiliser ce script, ne pas oublier de retirer la ligne use lib ou de mettre ce qu'il faut cet endroit.

5 )Configuration d'un agent NRPE

5.1 )Principe de fonctionnement

NRPE, "Nagios Remote Plugin Executor", est un des moyens de supervision distance offert par Nagios.

Il offre en effet la possibilit de profiter de la puissance des greffons, ceux-ci ne s'excutant pas pour autant sur le serveur Nagios.

Le principe de fonctionnement est le suivant : les greffons sont installs sur la machine superviser, compils pour son architecture
(car c'est elle qui va les lancer), ainsi que le serveur (daemon) NRPE. Le client de ce serveur, un greffon comme un autre,
check_nrpe, est lui install sur le serveur Nagios.

Le serveur nrpe voit ensuite sa configuration compose d'une liste de vrifications nommes, auxquelles correspondent un greffon
avec ses paramtres, ainsi que quelques autres options de configuration pour le fonctionnement du serveur nrpe en lui-mme.
Supervision avec Nagios 10

Le serveur Nagios voit, lui, sa configuration s'enrichir d'appels au seul greffon check_nrpe, auquel on passe en paramtre le nom de
la vrification faire effectuer sur la machine supervise. Ce check_nrpe initiera donc une connexion vers l'agent nrpe et lui
demandera uniquement l'excution d'une vrification. L'agent nrpe lancera ensuite le greffon considr et retournera le code retour
ainsi que le contenu de la sortie standard du greffon.

Si le serveur Nagios demande une vrification non configure (i.e. un nom inexistant dans le fichier nrpe.cfg de l'agent NRPE), il se
verra opposer une fin de non-recevoir, et positionnera le statut de la vrification UNKNOWN.

On peut prciser des listes de machines autorises demander des vrifications dans la configuration de nrpe, de mme qu'un lien
SSL peut tre mis en place pour viter les coutes entre greffon check_nrpe et agent nrpe.

Enfin, et c'est l le nud du problme avec nrpe, les paramtres de seuils pour qu'une alarme soit remonte sont spcifis sur la
machine supervise.

Les implications de ce fait sont importantes : cela signifie que la configuration n'est pas centralise sur le seul serveur Nagios, mais
clate sur tout le parc.

Il faut donc trouver un moyen d'automatiser la cration de la configuration, pour maintenir la cohrence entre les services configurs
sur le serveur Nagios et ceux sur l'agent nrpe, grer la quantit de services (par exemple des serveurs avec prs de 200 systmes de
fichiers distincts, sans compter les montages d'un mme systme de fichier plusieurs endroits), et par-l mme centraliser la
configuration.

5.2 )Dploiement
Il est trs simple de mettre en uvre la supervision via nrpe.

Le plus long est, comme nous venons de le voir, de configurer de faon synchrone la surveillance des systmes de fichiers et autres
greffons, dont la configuration apparat la fois sur le serveur Nagios (dans un fichier servicesmachine1.cfg inclus par
nagios.cfg, par exemple) et sur la machine supervise (dans nrpe.cfg).

L'idal est donc d'utiliser un script Perl qui prendra le contenu du fichier /etc/vfstab pour en extraire deux fichiers :
new_nrpe.cfg dont le contenu est reprendre pour la configuration de l'agent nrpe, et serviceshostname.cfg insrer
dans le fichier de configuration de Nagios sur le serveur de supervision. Ce script est cnrpe.pl :

#!/usr/local/bin/perlw
usewarnings;
usevarsqw/@nrpe@check_nrpe@line/;
my$hostname;
$hostname=qx/hostname/;
$hostname=~tr/[AZ]/[az]/;
chomp$hostname;
$count=0;
openVFSTAB,"</etc/vfstab";
while(<VFSTAB>){
chomp;
s/#.*//;#dropcomments
nextif/^\s*$/;#emptylines
@line=split(/\s/);
if(line[3]=~m/vxfs|ufs/){
$nrpe[$count]=$line[0];
$check_nrpe[$count]=$line[2];
$count++;
}
}
closeVFSTAB;
$count;
Supervision avec Nagios 11
openSTDOUT,">new_nrpe.cfg";
print<<"EOT";
#
#nrpe.cfgpour$hostname
#
server_port=5666
allowed_hosts=10.81.0.243
nrpe_user=nagios
nrpe_group=nagios
debug=0
#Servicechecks
command[check_users]=/opt/nagios/libexec/check_users1015
command[check_load]=/opt/nagios/libexec/check_load51015202530
EOT
foreach$i(0..$count){
print"command[check_disk".$i."]=/opt/nagios/libexec/check_disk8095";
print$nrpe[$i]."\n";
}

openSTDOUT,">services${hostname}.cfg";
print<<"EOT";
#Dfinitiondutemplatepour${hostname}
defineservice{
name ${hostname}service
use genericservice
host_name $hostname
notification_interval120
notification_period 24x7
notification_options w,u,c,r
max_check_attempts 3
is_volatile 0
normal_check_interval3
retry_check_interval 1
contact_groups sunadmins
check_period 24x7
register 0
}
#Servicedefinition
defineservice{
use ${hostname}service
service_description SMTP
check_command check_smtp
}
defineservice{
use ${hostname}service
service_description load
check_command check_nrpe!check_load
}
defineservice{
use ${hostname}service
service_description users
check_command check_nrpe!check_users
}
EOT
foreach$i(0..$count){
print<<"EOT";
defineservice{
use ${hostname}service
description $check_nrpe[$i]
contact_groups sunadmins
check_command check_nrpe!check_disk$i
}
EOT

};
Ce script est un exemple de ce qu'il est possible de faire pour Solaris. Il est ensuite possible, via des tables de dispatchs (des hash Perl),
d'affiner les paramtrages des greffons machine par machine.
Supervision avec Nagios 12
Ce script, une fois distribu sur toutes les machines du parc, permet de gnrer la vole les deux fichiers ncessaires nrpe.conf et
services-hostname.cfg. Il suffit ensuite de rapatrier via SSH le second, de le dposer au bon endroit (/etc/nagios par exemple) sur le
serveur Nagios, et de relancer Nagios. Toutes les oprations peuvent bien-sr tre encapsules dans un script shell qui fera toutes les
oprations.

6 )Interface et utilisation
L'interface utilisateur de Nagios se fait par le biais d'un serveur Web, comme d'ailleurs la plupart des autres outils utilisables. Cela
permet une ubiquit de l'outil, ainsi qu'une indpendance de fonctionnement vis--vis des matriels et logiciels systmes d'un poste
client.

6.1 )Revue de dtail des menus

Tactical overview
Vue synthtique o il est possible de trouver l'essentiel des informations importantes sur le bon fonctionnement du systme
d'information supervis.
Cette vue trs simple rassemble les informations quantitatives essentielles au premier abord : nombre d'quipements superviss,
services fonctionnels, services non fonctionnels, alarmes en cours, acquittes, non acquittes. Elle permet de naviguer facilement et
directement vers l'information pertinente. Par exemple, il suffit de cliquer sur un lien sur fond rouge (signifiant qu'un service ou un
serveur est tomb) pour aller directement la liste des problmes.
Service Dtail
La liste exhaustive, par quipement, des services superviss. Attention, cette vue peut tre lourde si vous avez un parc important avec
un grand nombre de services superviss.
Host Detail
La liste des machines, en vert si elles sont vues sur le rseau (soit par le biais d'une vrification par greffon, soit par un ping si aucun
service n'est dfini).
Status overview
La mme liste que prcdemment, mais avec les regroupements par hostgroup. Cela permet une vue rapide sur un sous-ensemble de du
parc (par site, par client, etc.)
Status summary
Une vue encore plus synthtique par hostgroup, avec indication du nombre d'quipements et de services dans les diffrents tats
possibles.
Status grid
Toujours par groupe d'quipements, une vue des machines, avec en regard les services (par leur nom) et leur tat (par la couleur).

Status map
Carte des tats des serveurs, en deux dimensions, permettant de voir les relations de dpendances entre objets telles qu'elles ont t
configures. Peu d'intrt, hormis le ct dpendances.

3D Status map
Vue navigable en 3D de l'infrastructure, plus gadget que rellement utile.

Non seulement ces diffrentes vues sont plthoriques, mais en plus, elles peuvent prendre divers paramtres afin de montrer tel ou tel
groupe, serveur, service. Leur intrt est donc limit, sauf dans le cas o l'on veut pouvoir donner l'accs la vue de son parc un
client externe.

Mais dans la majorit des cas, un PC avec un navigateur sur la tactical overview suffit amplement.

Voir le but des vues Service Problems, Host Problems, et Network outages pour les problmes.

Enfin, un historique des commentaires et des priodes d'arrt prvues sont disponibles derrire les liens Comments et Downtime.

Quelques informations sont aussi disponibles sur le fonctionnement de Nagios en lui-mme : paramtrage (dans les fichiers et dans ce
qu'il est possible de configurer dans l'interface, comme l'arrt de la notification) via View config et Process Info, le temps d'un cycle
complet de vrifications et quelques statistiques dans Performance Info, et enfin l'tat actuel de la file des vrifications venir.
Supervision avec Nagios 13
6.2 )Que faire quand un problme est remont ?
Lors de l'indication d'un problme, soit par le biais de l'alarme sonore, par mail ou par SMS (via Kannel par exemple) :
Se connecter Nagios puis slectionner les cases rouges ou orange, et acquittez l'alarme.
Dans le cas d'une possible correction rapide pour acclrer le retour la normale, dlectionner le lien Re-schedule the next check of
this service pour un service, ou sur Schedule An Immdiate Check Of All Services On This Host afin de remettre en dbut de file les
prochaines vrifications pour le service ou la machine considre. Cela permet deux choses : faire baisser le temps de dtection de
rsolution du problme, et surtout d'viter d'attendre les 3 5 minutes (suivant configuration) avant la prochaine vrification.
Dans le cas d'une impossible correction rapide, acquitter le problme afin qu'il ne remonte plus d'alarme, mais sera toujours vrifi
rgulirement par Nagios. Puis corriger le problme ultrieurement.

6.3 )Reporting
Nagios offre des possibilits de reporting, que ce soit du point de vue des machines supervises que des services.
Les donnes il est possible d'accder sont les suivantes, le reste est affaire de prsentation : historique des rsultats d'excution des
greffons, rapport de disponibilit des machines et services.

Trends
Les grandes tendances sur le parc supervis.

Availability
La disponibilit par machine, groupe de machines, services et bientt groupe de services. Cette disponibilit est fonction non seulement
du temps de bon fonctionnement d'un serveur, mais aussi de tous ses services. Attention donc ne pas plomber le contrat de service
(SLA) car le calcul ne sera pas sur le bon indicateur.

Alert histogram :
Gnration de graphiques (qui n'ont d'histogrammes que le nom) sur les alertes et les rtablissements.
Les rtablissements sont justes des acquittements sur des syslog.

Alert history
Une vue synthtique des dernires alertes remontes (que ce soit sur un problme ou un retour la normale).

Alert summary
Quasiment la mme information que le point prcdent, mais sous forme tabulaire, avec en plus les informations remontes par les
greffons. Un bon complment la Tactical overview.
Les liens sont le rsultat de l'utilisation du greffon urlize qui permet d'associer une URL au rsultat de l'excution du vrai greffon.
En l'occurrence, un lien vers la gestion des syslog.

Notifications:
Donne l'historique de tous les changes entre Nagios et ses utilisateurs (alertes, escalades, acquittements).

Event log:
Le journal des vnements, qui donne un peu la mme information que le point prcdent, mais sous une forme diffrente. Le journal
contient aussi les arrts et redmarrages de Nagios. C'est la main courante Nagios, en somme.

D'autres types de rapports sont imaginer en fonction de l'utilisation et des besoins. Dans les faits, Nagios donne en standard des outils
trs flexibles en matire de reporting.
Il est toujours possible de reprendre toutes les donnes dans les fichiers de journaux de Nagios, de les analyser, et d'en extraire des
'informations.
Pour ce qui est des informations de performance ventuellement remontes par les greffons, plusieurs projets existent pour les
exploiter. Citons-en deux : APAN et perfparse.
Supervision avec Nagios 14
7 )Nagios redondant
II est possible de configurer Nagios sur deux serveurs diffrents, de faon continuer avoir une supervision lors d'une
interruption d'une liaison entre deux sites, pour peu que les moyens de prvenir soient eux-aussi redondants.

7.1 )Le principe

On dispose d'une machine matre et d'une esclave. Les deux nagios vrifient chacun de leur ct tous les serveurs et les services.
Seulement le nagios esclave n'envoie aucune notification, ni courriel, ni SMS.
Si le matre tombe, l'esclave le dtecte par deux moyens : le matre ne rpond pas aux pings ou aucun processus avec le nom nagios ne
tourne sur le matre.
Un vnement est alors dclench sur l'esclave et celui-ci se met alors envoyer des notifications (courriels et SMS) pour le problme
du matre et pour les ventuels autres problmes.
Si le service nagios ou si le matre recommence rpondre aux requtes de l'esclave, ce dernier arrte alors les notifications et tout
revient dans l'ordre.

7.2 )Configuration du matre

On ajoute un service via nrpe pour vrifier la prsence d'un process nagios (/etc/nrpe.conf gnr par le script cnrpe.pl ).
command[check_nagios]=/usr/lib/nagios/plugins/check_procsc1:Cnagios
et c'est tout ! Le matre n'est pas au courant de la prsence de l'esclave.

7.3 )Configuration de l'esclave

On dsactive d'abord la notification (fichier /etc/nagios/nagios.cfg)
enable_notifications=0
On cre ensuite deux gestionnaires d'vnements (events handlers) qui, suivant l'tat du processus ou du serveur, activent ou
dsactivent la notification (/usr/lib/nagios/enventhandlers/handlermasterhostevent)
#!/bin/sh
#Onneprenddesdcisionsquelorsqu'onestsrdoncentathard
case"$2"in
HARD)
case"$1"in
DOWN)
#Lematreesttomb!
#IIfautdevenirlamachinematreet
#prendrelaresponsabilitdelasupervision
#durseau,doncactiverlesnotifications.
/usr/lib/nagios/eventhandlers/enable_notifications
;;
UP)
#Lamachinematreestremonte!
#Ilfautreprendrelaplaced'esclaveet
#laisserlematres'occuperdelasupervision,
#ondsactivedonclesnotifications.
/usr/lib/nagios/eventhandlers/disable_notifications
;;
esac
;;
esac
exit0

(et /usr/lib/nagios/eventhandlers/handlemasterprocevent)

#!/bin/sh
#Onneprenddesdcisionsquelorsqu'onestsr,doncentathard
case"$2"in
HARD)
case"$1"in
CRITICAL)
#LeprocessusprincipaldeNagiosnetournepas!
#IIfautdevenirlamachinematreet
#prendre1aresponsabilitdelasupervision
#durseau,doncactiverlesnotifications.
Supervision avec Nagios 15
/usr/1ib/nagios/eventhand1ers/enab1e_notifications
;;
WARNING)
;;
UNKNOWN)
#LeprocessusprincipaldeNagiostournepeut
#tre...Nousnefaisonsrienici,maispour
#tresr,onpourraitdciderquel'esclave
#deviennematredanscessituations.
;;
OK)
#LeprocessusprincipaldeNagiosrefonctionne!
#I1fautreprendrelaplaced'esclaveet
#laisserlematres'occuperdelasupervision,
#ondsactivedonclesnotifications.
/usr/1ib/nagios/eventhand1ers/disab1e_notifications
;;
*)
;;
esac
;;
esac
exit0

On dfinit ensuite deux nouvelles commandes pour grer les vnements dans /etc/nagios/misccommands.cfg :
#
#COMMANDEPOURLAMISEENPLACEDELAREDONDANCE
#
#Lescommandessuivantessontdes"eventhandlers",enfonctiondel'tat
#dumatreouduservicenagios,ildonnelamainl'esclavepourlanotification
#oularetire.
#
definecommand{
command_name handlemasterhostevent
command_line /usr/lib/nagios/eventhandlers/handlemasterhostevent$HOSTSTATE$$STATETYPE$
}
definecommand{
command_name handlemasterprocevent
command_line /usr/lib/nagios/eventhandlers/handlemasterprocevent$SERVICESTATE$$STATETYPE$}
On ajoute le gestionnaire d'vnements sur le serveur matre (/etc/nagios/hosts.cfg):
definehost{
use unixhost
host_name srvmaster
alias srvmasterSupervision
address srvmaster
event_handler handlemasterhostevent
parents cisco1
}
Puis le service vrifiant la prsence d'un processus nagios chez l'esclave (/etc/nagios/servicesdrivers.cfg) :
defineservice{
name Nagios
use srvmasterservice
checlk_command check_nrpe!check_nagios
event_handler handlemasterprocevent
service_description RedondanceNagios
}

7.4 )Les limites

La fonctionnalit prcdente n'est que la surveillance d'un serveur Nagios par son collgue, avec remplacement automatique. Cela ne
dispense nullement de rpliquer le reste de la configuration entre les deux serveurs, qui, rappelons-le, ne communiquent pas entre eux.
Et pour que cette mise en uvre de la redondance soit efficace, il vaut mieux que les configurations soient synchrones.
Cela peut bien videmment se faire par copie de fichiers de configuration, mais attention aux dpendances rseau (directive parent) : en
effet, un routeur ne sera pas forcment vu par la mme route, ni mme par la mme patte, et donc adresse.
Sans parler des parefeu qui peuvent tre prsents au milieu de tout a.
Supervision avec Nagios 16
8 )Conclusion
Nagios est un bon logiciel libre de supervision. Son faible cot d'acquisition ngligeable est nanmoins compens par une intgration
moindre par rapport un logiciel propritaire souvent plus esthtique .
Mais l'exprience nous a prouv qu'en quelques dizaines de jours/hommes il tait possible de mettre en uvre Nagios avec tous les
prrequis d'une production 24h/24.
Dans une socit, il est souvent plus rapide et moins cher de passer par un intgrateur comme une SSLL ou une SSII que de perdre du
temps le mettre en place soi-mme.
En effet, le gros du travail avec Nagios est de savoir o commencer, ce qu'il faut superviser, et ce qu'on peut oublier, et surtout de
mettre en place un cadre de travail volutif (tl-distribution). Une fois ce travail fait, il sera relativement simple de faire voluer les
choses, et d'ajouter ou enlever des sondes. Un des gros points non abords serait la mise en place d'une supervision hirarchise, avec
un site central recevant les notifications de sites distants, de faon limiter la bande passante utilise sur les liaisons loues.

9 )Rfrences
Nagios:http://www.nagios.org/
Locust:http://home.gna.org/locust/
DocumentationNagios:http://www.nagios.org/docs/
NSCIientetNRPE_NT:http://support.tsmgsoftware.com/
APAN:http://apan.sf.net/
perfparse:http://perfparse.sf.net/
NagiosPHP:http://nagiosphp.sourceforge.net/
Kannel:http://www.kannel.org