Installation

Récupérer les sources sur SourceForge puis suivre l'onglet Downloads du menu de navigation.

Pour installer un serveur Nagios, nous aurons besoin de deux archives : Nagios en lui-même, et les greffons de supervision, sans lesquels Nagios n'est rien.

Pré-requis

Nagios a, en plus des greffons, besoin de satisfaire un certain nombre de dépendances.

Sur une Mandrake, on comptera ainsi sur les paquetages GD de Thomas Boutell (libgd1-devel), ainsi que sur ceux installant Apache. Faites un urpmi apache libgd-devel pour installer le nécessaire.

Sur une autre distribution, comme RedHat ou Fedora, ce sera gd-devel. Yum, apt-rpm ou autres vous aideront.

gd-progs ou gd-utils pourra être utile plus tard lorsque viendra le moment de mettre de jolis dessins sur nos serveurs.

N'oubliez pas non plus que la bibliothèque GD s'appuie elle aussi sur d'autres bibliothèques comme les libjpeg, libpng et associées.

Compilation

La compilation de Nagios est un peu fastidieuse, car ne se réduisant pas à un simple ./configure && make install.

Nous avons pris l'option d'installer Nagios comme s'il était intégré à l'OS, afin d'avoir les fichiers de configuration dans /etc/nagios.

La première chose à faire est de créer un utilisateur pour Nagios, ainsi que son groupe :

 # groupadd nagios
 # useradd -g nagios -m -d /home/nagios -G apache nagios

Notez que cet utilisateur nagios fait aussi partie du groupe apache (nous sommes toujours sur une Mandrake), ce qui sera important pour plus tard. Modifiez ce groupe supplémentaire apache en www ou en ce qu'il convient pour votre distribution.

Ensuite vient le temps des choix. Pourquoi ? Parce que Nagios en version 1.x permet certaines choses que Nagios 2.x ne permettra pas, ou pas directement. En effet, pour Nagios 2.0, Ethan Galstad, l'auteur de Nagios, dans sa clairvoyance, a décidé de retirer les fonctionnalités permettant la mise en base de données des informations concernant les services, les serveurs, les performances, les commentaires, les états, les heures d'arrêt de service, etc. Ces extensions seront remplacés par l'event broker (le courtier - ? - d'évènements ).

Lancez la commande grep suivante pour voir de quoi nous parlons.

 $ ./configure --help | grep -E "mysql|pgsql"

N'oubliez pas d'installer les clients (y compris les paquetages de développement) PostgreSQL ou MySQL pour que le tout compile correctement.

Un autre point à voir est de savoir si l'on veut embarquer un Perl dans Nagios. Cela peut avoir son intérêt dans le cas d'une utilisation centrale de sondes Perl (il en existe un grand nombre), mais dans notre cas, nous allons utiliser le lanceur de sonde à distance nrpe.

 $ tar xvfz nagios-1.2.tar.gz
 ...
 $ cd nagios-1.2
 $ ./configure --prefix=/usr --sysconfdir=/etc/nagios \
               --localstatedir=/var/nagios --datadir=/usr/share/nagios/html \
               --sbindir=/usr/share/nagios/cgi-bin \
               --with-file-perfdata
 $ make all

Avant de lancer le make all, vous aurez pu vérifier que les chemins configurés sont les bons en regardant dans nagios-1.2/common/locations.h.

Quand la compilation s'est terminée (sans erreur normalement), on va pouvoir passer à l'installation (classique) :

 $ su -
 # make install

Il reste encore quelques opérations pour avoir un Nagios opérationnel :

make install-init pour installer le script de démarrage de Nagios (/etc/init.d/nagios). Il prend les options classiques.
make install-commandmode pour créer et mettre les droits sur le répertoire qui va contenir les fichiers de communication entre le serveur Nagios et les CGI de présentation.
make install-config pour installer un exemple de configuration de Nagios ; les fichiers de configuration ainsi copiés dans /etc/nagios verront leur nom se terminer par -sample. Vous n'aurez ainsi pas l'occasion de perdre votre configuration préexistante.

Nous allons donc pouvoir passer à la configuration de Nagios.

Configuration de Nagios

Apache

Dans le fichier httpd.conf de votre Apache, incluez le fichier nagios.conf que nous allons écrire.

  Include conf/nagios.conf

Le fichier nagios.conf va contenir les directives suivantes :

Définition des correspondances entre répertoires et URLs relatives
```
 ScriptAlias /nagios/cgi-bin /usr/share/nagios/cgi-bin
 Alias       /nagios         /usr/share/nagios/html
```
Notez que l'URL /nagios/cgi-bin doit être définie avant /nagios car elle ne serait sinon pas prise en compte car masquée.
Tout ça nous permettra de pointer un navigateur sur le serveur web où Nagios est installé, grâce à une URL du style : http://monserver/nagios/.

Création des déclarations des répertoires correspondant aux URLs

 <Directory /usr/share/nagios/cgi-bin>
      AllowOverride AuthConfig
      Options ExecCGI
      Order deny,allow
      Allow from all
      AuthType Basic
      AuthName "Nagios"
      AuthUserFile /etc/nagios/htpasswd
      <Limit GET POST>
        Require valid-user
      </Limit>
 </Directory>

 <Directory /usr/share/nagios/html>
      AllowOverride AuthConfig
      Options Indexes FollowSymLinks
      Order deny,allow
      Allow from all
      AuthType Basic
      AuthName "Nagios"
      AuthUserFile /etc/nagios/htpasswd
      <Limit GET POST>
        Require valid-user
      </Limit>
 </Directory>

Authentification

L'accès à 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 redémarrage d'un serveur si l'event handler est défini.

La définition des règles d'authentification est déjà écrite ci-dessus, il ne nous reste plus qu'à renseigner le fichier /etc/nagios/htpasswd. Cela se fait par le biais de l'utilitaire htpasswd fournit avec Apache.

 # htpasswd [-c] /etc/httpd/htpasswd nagios
 New password: ******¶
 Re-type new password: ******¶
 Updating password for user nagios

Cet utilisateur nagios doit correspondre non à l'utilisateur au sens POSIX créé tout à l'heure, mais à un contact défini dans /etc/nagios/contacts.cfg.

Configuration Nagios

Les fichiers de configuration de Nagios se trouvent dans le répertoire /etc/nagios.

Ces fichiers de configuration, à l'exception des fichiers nagios.cfg et cgi.cfg, utilisent une structure unique de définition des objets sur le principe suivant :

 define {
       param1 value
       param2 value
       ...
       paramn value
 }

Cela implique qu'aucun espace ne pourra être inséré dans les valeurs des paramètres. Il faudra donc y faire attention.

Pour tester la cohérence de vos fichiers de paramétrage, utilisez la commande :

 # /usr/bin/nagios -v ../etc/nagios.cfg

ou, si vous avez installé le script de lancement /etc/init.d/nagios :

  service nagios reload

ou encore, si vous n'êtes pas sur une distribution qui vous fournit le script service (qui devrait être obligatoire) :

  /etc/init.d/nagios reload

qui a le bon goût de cumuler vérification de configuration et lancement de Nagios.

Bien sûr, si vous n'aviez pas lancé Nagios auparavant, faites-le avec cette même commande en passant start au lieu de reload en paramètre.

Objets de Nagios

Au commencement est le serveur (host). Ce serveur n'est pas tout seul, il donc pouvoir le définir ainsi que ses congénères, qui peuvent ne pas être des serveurs mais tout équipement doté d'une interface réseau. Ces hôtes peuvent être regroupés dans un ou plusieurs groupes, chez nous à la fois par technologie (les linux avec les linux, etc.), mais aussi (nous assurons une prestation d'hébergement pour nos clients) par client.

Ce regroupement peut permettre d'agir sur un ensemble de machines, par exemple si l'on a prévu d'arrêter toute la plate-forme d'un client qui a 8 serveurs, nous prévoirons un arrêt sur le groupe du client, plutôt que perdre du temps à prévoir l'arrêt sur chacun des serveurs.

Viennent ensuite les services. Ces services correspondent en fait au produit des machines par les greffons et par les paramètres qui peuvent leur être appliqués. Si une machine a 200 systèmes de fichiers, il sera fait 200 fois appel au greffon check_disk, à chaque fois avec en paramètre le nom du système de fichier à vérifier, et avec les seuils de criticité associés. Idem pour le greffon check_proc, qui peut compter les processus actifs, les processus zombies, et les processus swapés (nous n'avons pas d'équivalent satisfaisant en français). Donc trois services différents.

Ces services s'appuient sur des greffons, qu'il faut donc définir. C'est le rôle des clauses command, qu'on retrouvera généralement dans un fichier de configuration checkcommands.cfg.

L'ordonnancement de la vérification des services se fait selon des calendriers définis par les clauses timeperiod (fichier timeperiods.cfg).

Le rôle de Nagios est donc de prévenir quelqu'un lorsqu'un problème survient. C'est le rôle des fichiers contacts.cfg (clauses contact, sans mauvais jeu de mots d'informaticien) et contactgroups.cfg (vous avez deviné la clause). L'escalade des avertissements et autres alertes entre les différents groupes d'intervenants se faisant dans le fichier escalations.cfg.

Enfin, les commandes externes, non-destinées au lancement de greffons sont centralisées dans le fichier misccommands.cfg, telles que l'envoi de courriels, de SMS (via l'utilisation d'outils tiers), etc.

Rapidement, passons les autres fichiers :

dependencies.cfg qui définissent les dépendances entre services (sur le même serveur ou sur des serveurs différents, clause servicedependency), par exemple tels serveur web virtuel dépend de la présence 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 (icônes, coordonnées des objets sur la carte graphique) pour les équipements ;
serviceextinfo.cfg : la même chose, mais pour les services.

Quelques trucs de configuration

Cet article n'a pas pour but de paraphraser la documentation de Nagios, qu'elle soit en anglais ou en français grâce aux efforts de Opsyx et contributeurs, dont Xavier Dusart, traducteur principal de celle de NetSaint.

Les patrons

L'arrivée en 2002 de Nagios 1.04beta a vu l'introduction des patrons (templates) de configuration. Comme tous les services doivent être explicitement définis, autant réduire leurs définitions à leur plus simple expressions. Idem pour les serveurs. Inutile donc, si l'on a 35 serveurs Linux, 25 serveur Solaris et 40 équipements réseau des mêmes constructeurs, avec des contraintes de disponibilité identiques, de dupliquer manuellement les mêmes paramètres pour tout le monde.

Cela simplifie la lecture (seule l'information directement pertinente est visible à la définition du serveur/service), fini les oublis lors d'un changement de classe (passage d'une supervision aux heures de bureau à du 24h/24 quand des serveurs passent en production) si l'on doit modifier manuellement les timeperiods de 200 services sur 4 serveurs différents. Avec les patrons, il suffit de modifier le patron des services de chaque serveur, voire de modifier le patron des patrons si les 4 serveurs fournissent une même application.

Exemples :

  # definition du patron par défaut
  define service {
    name                            generic-service        ; le nom du patron
    register                        0                      ; On enregistre pas cet objet, ce n'est pas un vrai service
    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                  network-admins
    }

Comme vous pouvez le voir, le patron voit un grand nombre de paramètres configurés, en fait, exactement les mêmes que pour un service normal. La seule différence se fait dans le paramètre register, positionné à 0, qui fait que la définition est considérée comme un patron.

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

  define service {
    name                 switch1-service
    register                        0
    use                  generic-service  ; On lui dit d'utiliser les informations
                                          ; du patron 'generic-service'
    host_name            switch1
    }

Enfin, voici comment utiliser le patron pour définir un service Ping :

  # exemple de service utilisant un patron
  define service {
    use                  switch1-service  ; On lui dit d'utiliser les informations
                                          ; du patron 'switch1-service'
    service_description  Ping
    check_command        check_ping!200,50%!400,80%
    }

Notifications et escalades

Nagios vérifie régulièrement 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 différent de OK, une alerte en état soft est levée. Nagios vérifiera 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 après tous les essais, une première notification est envoyée.

Si après un intervalle de notification_interval minutes, le problème n'est toujours pas réglé, Nagios enverra une autre notification et continuera ainsi jusqu'à ce que le problème soit résolu 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 préciser à quels groupes de contacts Nagios devra envoyer les notifications. Cela se fait en fonction du nombre de notifications envoyées.

Voici un petit exemple :

  define serviceescalation {
    host_name              switch1
    service_description    Ping
    first_notification     3
    last_notification      5
    notification_interval  90
    contact_groups         network-admins,managers
    }

  define serviceescalation {
    host_name              switch1
    service_description    Ping
    first_notification     6
    last_notification      0
    notification_interval  60
    contact_groups         tout-le-monde
    }

On continue ici l'exemple des patrons : on possède un équipement réseau désigné par switch1. Par défaut, les notifications sont envoyées toutes les deux heures (120 minutes) au groupe de contacts network-admins. Grâce aux escalades que l'on vient de configurer, si le problème est toujours présent à la troisième notification, celle-ci sera envoyée aux groupes de contacts network-admins et managers. Les prochaines notifications seront envoyées toutes les 90 minutes. Enfin, si au bout de six notifications, au total, l'alerte continue, Nagios avertira le gens du groupe de contact tout-le-monde indéfiniment (d'où le 0 dans le champ last_notification) à une période de 60 minutes.

Dans tous les cas, toutes les personnes qui ont reçu la notification de l'erreur recevront la notification de retour à la normal du service.

Les gestionnaires d'évènements (event-handlers)

Les gestionnaires d'évènements sont des commandes externes optionnelles qui sont exécutées à chaque fois qu'un changement d'état d'un hôte ou d'un service a lieu. Une utilité triviale de ces gestionnaires d'évènements (particulièrement pour les services) réside dans la capacité de Nagios à résoudre les problèmes de manière préventive avant que quelqu'un ne reçoive une notification. Une seconde utilité est celle d'enregistrer les évènements relatifs aux hôtes ou services dans une base de données externe.

Dans la plupart des cas, les commandes de gestionnaires d'évènements seront des scripts écrits en shell ou en Perl. Ils doivent comporter au moins les macros suivantes comme arguments :

Macros de gestionnaire d'évènements de service : $SERVICESTATE$ , $STATETYPE$ et $SERVICEATTEMPT$ ;
Macros de gestionnaire d'évènements d'hôte : $HOSTSTATE$ , $STATETYPE$ , $HOSTATTEMPT$ .

Les scripts examinent les valeurs des arguments qui leur sont passés et exécutent les actions nécessaires en fonction de ces valeurs. Le meilleur moyen de comprendre comment les gestionnaires d'évènements doivent fonctionner est de prendre un exemple. Aussi nous vous conseillons de voir le principe de mise en redondance de Nagios plus loin dans cet article.

La cosmétique

A l'aide des informations additionnelles sur les équipements, il est possible d'ajouter des logos, des descriptions, un lien telnet (qui connaît l'URL pour faire du SSH ?) vers les machines, etc. Tout ça vous permettant de reconnaître facilement et accéder directement à d'autres informations sur vos équipements.

Exemple :

  define hostextinfo {
    host_name             ts1000-1
    icon_image            base/cyclades_ts.gif
    vrml_image            base/cyclades_logo.png
    statusmap_image       base/cyclades_ts.png
    icon_image_alt        Serveur Terminaux
    }

L'icône donnée dans le champ icon_image sera affichée à chaque fois à coté du nom de la machine. Le champ vrml_image renseigne de l'image utilisée 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'icone.

On pourrait aussi rajouter un lien qui serait affiché dans les informations de l'équipement avec le champ notes_url que l'on pourrait par exemple faire pointer vers un logiciel de métrologie (qui a dit Cacti ? :-).

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

Attention cependant à la définition du chemin relatif vers les images. Les chemins se donnent de façon relative à un répertoire logos (nom codé en dur, nous semble-t'il) du répertoire image. Ce répertoire image étant lui-même un sous-répertoire de la partie Web de Nagios, ou plus exactement d'un paramètre de configuration des CGI. Ce paramètre est physical_html_path, et pointe (chez nous) sur /usr/share/nagios.

Les greffons

Les greffons officiels

Les greffons officiels sont disponibles sur SourceForge, projet nagios-plug.

Ils sont divisés en deux catégories : les greffons principaux (« core plugins ») et les greffons dit contribués, qui ne sont pas forcément maintenus, mais néanmoins distribués dans l'archive officielle.

D'autres greffons existent mais sont bien souvent d'un usage limité car destinés à un usage particulier. N'oubliez pas d'interroger votre moteur de recherche préféré (« Nagios » et « plugin » sont deux mots-clés indispensables).

La compilation des greffons officiels (pour ceux écrits en langage C) ne posent pas de problème particulier, sinon qu'il faut bien évidemment prêter attention aux dépendances, en particulier les bibliothèques permettant d'écrire des clients de service réseau, radius ou LDAP étant des exemples.

Lisez attentivement les messages d'erreur à la compilation, mais aussi et surtout les messages d'avertissement (qui ne sont pas des erreurs) indiqué par un gros WARNING émis par le ./configure. Ils vous indiqueront si tel ou tel greffon sera compilé ou non, sa ou ses dépendances ayant été trouvée(s) ou non.

Écrire son propre greffon

L'écriture d'un greffon doit respecter deux règles : légèreté et simplicité. En effet, ce greffon doit passer inaperçu dans son exécution, 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 tâche 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.

Pour prendre un exemple qui revient à la mode, les serveurs d'entrée de gamme que nous utilisons sur certains services n'ont plus de disques SCSI sur une carte RAID. Il va nous falloir vérifier que les miroirs logiciels mis en œuvre sous Linux fonctionnent comme il le faut.

Notre greffon 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 système de fichier en plus du périphérique RAID qui défaille.

Tout d'abord, voici le script :

  #!/usr/bin/perl

  use strict;
  use warnings;
  use English;
  use Getopt::Long;
  use vars qw($PROGNAME $opt_V $opt_h $opt_t);
  use lib "/home/jfenal/cvs/nagios/nagios-plugins-1.4.0alpha1/plugins-scripts";
  use utils qw( %ERRORS &print_revision &support );

  use Data::Dumper;

  $PROGNAME="check_linuxraid";
  $REVISION=': check_linuxraid.pl,v 1.1 2004/07/26 08:33:29 jfenal Exp';

  sub print_usage {
      print "Usage:\n";
      print "  $PROGNAME\n";
      print "  $PROGNAME [-h | --help]\n";
      print "  $PROGNAME [-V | --version]\n";
      print "  $PROGNAME -t\n";
  }

  sub print_help {
      print_revision($PROGNAME, $REVISION);
      print "Copyright © 2004 Jérôme Fenal\n\n";
      print_usage();
      print "\n";
      print "Use -t to test the script, /proc/mdstat source used is internal to the script\n";
      print "\n";
      support();
  }

  my (%data, %slices, %types, %status, %alerts, %rcs);
  my $msg=''; # empty string

  Getopt::Long::Configure('bundling');
  GetOptions(
          "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 (!open DATA, '< /proc/mdstat') {
          print "Unable to open /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" if m/^\s+(.*)$/;
  }

  foreach my $md (keys %data) {
      foreach ( split / /, $data{$md}) {
          push @{$slices{$md}}, $_ if /\w+\[\d+\]/;
          $types{$md} = $_ if /raid\d/;
          $status{$md} = $1 if /\[([U_]+)\]/;
      
      }
      if ($status{$md} =~ /_/ ) {
          my $p=-1;
          while (($p = index($status{$md}, '_', $p+1)) != -1 ) {
              push @{$alerts{$md}}, $slices{$md}[$p];
          }
      }
      # on sort un CRITICAL si des miroirs n'ont qu'une patte
      if ($types{$md} eq 'raid1' && @{$slices{$md}} == 0 ) {
          $rcs{'CRITICAL'}++;
          $msg.=" $md(2few dev)";
      }
  }

  #print Dumper \%slices, \%types, \%alerts, \%status;

  foreach my $md (keys %alerts) {
      $msg .= " $md(";
      foreach my $slice ( @{$alerts{$md}} ) {
          $msg .= " $slice";
          if ($slice =~ /\(F\)/) {
              $rcs{'CRITICAL'}++;
          }
          elsif ($data{$md} =~ /recovery/) {
              # ça reconstruit
              $msg .= " rebuilding";
              $rcs{'WARNING'}++;
          } else {
              # il y a des cas où le device n'est pas failed, et où le miroir n'est
              # pas actif non plus (bug du driver md)
              $rcs{'CRITICAL'}++;
          }
      }
      $msg .= ")"
  }

  my $rc = $rcs{'CRITICAL'} ? $ERRORS{'CRITICAL'} :
              ( $rcs{'WARNING'} ?  $ERRORS{'WARNING'} : $ERRORS{'OK'} ) ;

  $msg =~ s/\(\s/\(/g;

  my %t = reverse %ERRORS;

  $msg = "All RAID devices sane (" . join(', ', keys %data). ")"
    if $rc == $ERRORS{'OK'};

  print "$t{$rc}:$msg\n";

  close DATA;
  exit $rc;

  __DATA__
  Personalities : [raid1]
  read_ahead 1024 sectors
  md0 : active raid1 sdb5[1] sda5[0]
        4200896 blocks [2/2] [_U]
        
  md1 : active raid1 sdb6[1] sda6[0]
        2104384 blocks [2/2] [UU]
        
  md2 : active raid1 sdb7[1] sda7[0]
        2104384 blocks [2/2] [UU]
        
  md3 : active raid1 sdc7[1] sdd8[2] sde5[0]
        1052160 blocks [2/2] [UU]
        
  md4 : active raid5 hdh1[3] hdg1[2] hdf1[1] hde1[0]
        360182016 blocks level 5, 256k chunk, algorithm 2 [4/4] [UUUU]
        
  md5 : active raid5 sdf1[2] sde1[3] sdg1[1] sdd1[4] sdc1[0]
        1638144 blocks level 5, 64k chunk, algorithm 0 [5/5] [UUUUU]
        
  md6 : active raid5 sde2[7] sdf2[4] sdg2[3] sdd2[6] sdc2[2] sdb2[1] sda2[0]
        104196864 blocks level 5, 64k chunk, algorithm 0 [7/6] [UUUUU_U]
        [===>.................]  recovery = 17.0% (2966244/17366144) finish=119.2min speed=2011K/sec
  md7 : active raid1 hde5[0](F) hdf7[1]
        39262720 blocks [2/1] [_U]
        
  md8 : active raid1 sda5[0]
        4200896 blocks [1/1] [U]
        
  unused devices: none

On utilise dans ce script un module venant des plugins Nagios : utils.pm. Il définit le hash qui sera utilisé par la suite pour la définition du code retour : %ERRORS, définit 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 néanmoins à ne pas faire de faute d'orthographe dans l'écriture de CRITICAL ou de WARNING, voire de UNKNOWN pour votre script. OK ne devrait pas poser de problème (encore que...).

L'option -t permet de tester le script en situation avec les données.

Si vous voulez utiliser ce script, n'oubliez pas de retirer la ligne use lib ou de mettre ce qu'il faut à cet endroit.

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 que nous utilisons. Cela permet une ubiquité de l'outil, ainsi qu'une indépendance de fonctionnement vis-à-vis des matériels et logiciels systèmes d'un poste client.

Revue de détail des menus

Tactical overview
C'est la vue synthétique, où l'on trouve l'essentiel des informations importantes sur le bon fonctionnement du système d'information supervisé.

la tactical overview ou vue synthétique des opérations

Cette vue très simple rassemble les informations quantitatives essentielles au premier abord : nombre d'équipements supervisés, services fonctionnels, services non fonctionnels, alarmes en cours, acquittées, non acquittées. 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 problèmes.
Service Detail
La liste exhaustive, par équipement, des services supervisés. Attention, cette vue peut être lourde si vous avez un parc important avec un grand nombre de services supervisés.
Host Detail
La liste des machines, en vert si elles sont vues sur le réseau (soit par le biais d'une vérification par greffon, soit par un ping si aucun service n'est défini).
Status overview
La même liste que précédemment, mais avec les regroupements par hostgroup. Cela permet une vue rapide sur un sous-ensemble de votre parc (par site, par client, etc.)
Status summary
Une vue encore plus synthétique par hostgroup, avec indication du nombre d'équipements et de services dans les différents é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
Cette carte des états des serveurs, en deux dimensions, permet de voir les relations de dépendances entre objets telles qu'elles ont été configurées. Elle n'a cependant que peu d'intérêt hormis ce côté dépendances.

La carte des états des équipements
3D Status map
Une vue navigable en 3D de l'infrastructure, plus gadget que réellement utile, elle peut être visualisée à travers un navigateur VRML :

Carte 3D des états des équipements

Non seulement ces différentes vues sont pléthoriques, mais en plus elles peuvent prendre divers paramètres afin de montrer tel ou tel groupe, serveur, service. Leur intérêt est donc limité, sauf dans le cas où l'on veut pouvoir donner l'accès à la vue de son parc à un client externe. Mais dans la majorité des cas, un PC avec un brouteur sur la « tactical overview » suffit amplement. Le son y est déjà activé, et il est toujours temps d'aller cliquer sur les boîtes rouges ou oranges pour voir le détail de ce qui cloche. D'ailleurs, c'est aussi le but des vues Service Problems, Host Problems, et Network outages.

Enfin, un historique des commentaires et des périodes d'arrêt prévues sont disponibles derrière les liens Comments et Downtime.

Quelques informations sont aussi disponibles sur le fonctionnement de Nagios en lui-même : paramétrage (dans les fichiers et dans ce qu'il est possible de configurer dans l'interface comme l'arrêt de la notification) via View config et Process Info, le temps d'un cycle complet de vérifications et quelques statistiques dans Performance Info, et enfin l'état actuel de la file des vérifications à venir.

Que faire quand un problème est remonté ?

Quand vous êtes avertis d'un problème, que ce soit par le biais de l'alarme sonore, par mail ou par SMS (via Kannel[8] par exemple), que faire ?

Déjà, connectez-vous à Nagios si ce n'est déjà fait. Cliquer sur les cases rouges ou oranges, et acquittez l'alarme. Ça vous évitera de casser les oreilles de vos collègues d'openspace. Si vous êtes en mesure de corriger le problème rapidement, et que vous voulez accélérer le retour à la normale, cliquer sur le lien Re-schedule the next check of this service pour un service, ou sur Schedule An Immediate Check Of All Services On This Host afin de remettre en début de file les prochaines vérifications pour le service ou la machine considérée. Cela permet deux choses : faire baisser le temps de détection de résolution du problème (si vous avez un contrat sur les performances avec vos clients), et surtout d'éviter d'attendre les 3 à 5 minutes (suivant votre configuration) avant la prochaine vérification.

Si vous ne pouvez corriger le problème de suite, acquittez-le quand même, il ne remontera plus d'alarme, mais sera toujours vérifié régulièrement par Nagios. Vous avez ainsi tout votre temps (façon de parler) pour ouvrir votre ticket d'incident (Nagios peut le faire pour vous) et corriger le problème.

Reporting

Nagios offre de belles possibilités de reporting, que ce soit du point de vue des machines supervisées que des services.

Les données auxquelles vous avez accès sont les suivantes, le reste est affaire de présentation : historique des résultats d'exécution des greffons, rapport de disponibilité des machines et services.

Trends
Les grandes tendances sur le parc supervisé. Voici ce que ça peut donner pour un routeur.

Rapport des tendances
Availability
La disponibilité par machine, groupe de machines, services et bientôt groupe de service. 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 votre contrat de service (SLA) parce que vous ne calculez pas le bon indicateur. Cela doit aussi vous mettre la puce à l'oreille quand vous écrirez votre prochain contrat de service.

Rapport de disponibilité des équipements

Vous noterez qu'ici, la période allant du 1er janvier au 27 juillet, certaines machines un fort taux d'état non déterminé. C'est simplement que ces machines ont été installées en avril ou mai. Une autre source d'état indéterminé sont les périodes de temps où Nagios est arrêté.
Alert histogram :

Rapport histogramme des alertes

Génération de graphiques (qui n'ont d'histogrammes que le nom) sur les alertes et les rétablissements. La copie d'écran présentée ici est celle concernant un routeur sur une semaine. Les rétablissements sont justes des acquittements sur des syslog.
Alert history

Une vue synthétique des dernières alertes remontées (que ce soit sur un problème ou un retour à la normale).
Alert summary

Rapport résumé des alertes

Quasiment la même information que le point précédent, mais sous forme tabulaire, avec en plus les informations remontées par les greffons. Un bon complément à la Tactical overview pour une utilisation sur un écran perché sur une armoire ou accroché au mur.

Les liens sont le résultat de l'utilisation du greffon urlize qui permet d'associer une URL au résultat de l'exécution du vrai greffon. En l'occurrence un lien vers notre gestion des syslog.
Notifications :
Donne l'historique de tous les échanges entre Nagios et ses utilisateurs (alertes, escalades, acquittements).

Rapport sur les notifications

Notez la pollution des messages d'alerte avec un peu de HTML (le lien généré par urlize). Nous avons encore un peu de travail...
Event log :
Le journal des évènements, qui donne un peu la même information que le point précédent, mais sous une forme différente. Le journal contient aussi les arrêts et redémarrages de Nagios. C'est la main courante Nagios, en somme.

Rapport journal des événements

D'autres types de rapports sont à imaginer en fonction de votre utilisation et de vos besoins. Dans les faits, Nagios donne en standard des outils très flexibles en matière de reporting, le tout est de trouver les bonnes options, en adéquation avec ce que vous désirez réellement mesure en termes de qualité de service.

Si vous voulez aller plus loin, il vous est toujours possible de reprendre toutes les données dans les fichiers de journaux de Nagios, de les analyser, et d'en extraire l'information qui vous sied.

Pour ce qui est des informations de performance éventuellement remontées par les greffons, plusieurs projets existent pour les exploiter. Citons-en deux : APAN[5] et perfparse[6]. Gageons que vous saurez retrouver une personne francophone pour vous aider sur l'un des deux :)

Nagios

Chapeau de l'article

Concepts de supervision

Concepts de supervision avec Nagios

Architecture

Principes de base

Mise en réseau de la supervision

États hard et soft

Les escalades

Installation

Pré-requis

Compilation

Configuration de Nagios

Apache

Authentification

Configuration Nagios

Objets de Nagios

Quelques trucs de configuration

Les patrons

Notifications et escalades

Les gestionnaires d'évènements (event-handlers)

La cosmétique

Les greffons

Les greffons officiels

Écrire son propre greffon

Configuration d'un agent nrpe

Principe de fonctionnement

Déploiement

Interface et utilisation

Revue de détail des menus

Que faire quand un problème est remonté ?

Reporting

Nagios redondant

Le principe

Configuration du maître

Configuration de l'esclave

Les limites

L'avenir

Conclusion

URLographie

Ours

Jérôme Fenal

Camille Barette

Configuration d'un agent `nrpe`