Nagios est un outil flexible et totalement paramétrable. De manière générale, il est pénalisant dans un projet d’être limité par les caractéristiques d’un élément. Bien délimiter un besoin permet d’orienter les recherches et de proposer une solution adéquate.

Nagios est un moniteur de supervision réseau Open Source. Anciennement nommé NetSaint, logiciel libre reconnu dans le monde de la supervision, il permet une supervision active et passive de serveurs, d'équipements réseaux, et surtout de services divers et variés.

Bien que Nagios utilise des principes simples, il est complexe à mettre en place (configuration des intervalles de notifications, des commandes de vérification, des services et des hôtes à surveiller, des contacts pour les notifications, etc.). De l'aveu même du concepteur (Ethan Galstad) : « Si vous ne voulez pas passer du temps à apprendre comment ça fonctionne et pensez voir les choses tourner facilement, ne prenez pas la peine d'utiliser ce logiciel. »

Cependant, Nagios n'est en soi qu'un moteur d'ordonnancement. Il repose entièrement sur un système de plugins.

Icinga est un fork de Nagios rétro-compatible. Ainsi, les configurations, plugins et addons de Nagios peuvent tous être utilisés avec Icinga. Bien qu'Icinga conserve toutes les caractéristiques existantes de son prédécesseur, il s'appuie sur celles-ci pour ajouter de nombreux correctifs et fonctionnalités longtemps attendues et demandées par la communauté des utilisateurs.

Vous ne trouverez pas ici une documentation complète du produit, car la documentation officielle est déjà très fournie. Je vous propose de lire le ebook de Nicolargo concernant Nagios qui est très bien écrit et commenté.

Comme nous l’avons dit précédemment Nagios est un ordonnanceur qui s’appui sur les fichiers textes suivants :

• Nagios.cfg : est le fichier principal de configuration, il contient la liste des autres fichiers de configuration.
• Resource.cfg : permet de définir des variables globales réutilisables dans les autres fichiers. Il n’est pas accessible par les scripts CGI qui génèrent l’interface graphique de Nagios. Ce fichier peut contenir des données sensibles comme les identifiants de connexion à la base de données.
• Checkcommands.cfg : contient les alias des commandes définis par l’utilisateur. Le fichier peut utiliser les variables globales. Les alias seront ensuite utilisés pour définir les commandes complètes dans les fichiers hosts.cfg et services.cfg.
• Hosts.cfg : contient l’ensemble des hôtes à tester. Il associe a chaque hôtes une structure composée de son nom, adresse ip…
• Services.cfg : permet d’associer à chaque hôte les services à vérifier. Le plus simple étant de créer des services dit « générique » qui pourront être appliqué au plus grand nombre d’hôtes. Ensuite créer des services spécifiques pour un besoin particulier.
• Hostsgroups.cfg : permet de regrouper des hosts selon des caractéristiques communes avec la possibilité d’associer un alias à un groupe. Il est obligatoire qu’un hôte appartienne à un groupe.
• Contacts.cfg : contient les contacts à prévenir en cas d’incident. Il permet de configurer le moyen d’alerter (mail, sms…), la fréquence et la plage horaire des notifications.
• Contactgroups.cfg : rassemble les contacts en un groupe pour simplifier l’administration.
• Cgi.cfg : définit les paramètres de configuration pour les scripts CGI.
• Timeperiods.cfg : définit les tranches horaires applicables aux vérifications de services et aux notifications.
• Dependencies.cfg : définit les dépendances entre services (sur le même hôte ou sur des hôtes différents). Pour cela il se base sur l’état des autres services pour déclencher l’exécution d’un test ou une notification. Cela permet ainsi de supprimer les notifications d’un hôte basé sur le statut d’un ou plusieurs hôtes.
• Escalations.cfg : définit l’escalade des avertissements et alertes pour un hôte ou un service donné. Il répartit ces notifications entre les différents groupes d’intervenants.
• Hostextinfo.cfg et Serviceextinfo.cfg : sont des fichiers optionnels permettant l’affichage d’icônes et d’informations sur les machines. Dans notre cas, ils seront utilisés pour le « status_map ».

L’ensemble de ces fichiers, correctement écris, permettent une véritable IHM à travers une interface web. Cette dernière permettra d’afficher les résultats des différentes sondes par l’intermédiaire de scripts CGI.

Les plugins sont des scripts ou programmes qui sont indépendants de Nagios. Ils sont chargés de réaliser des vérifications et de fournir un code retour de la manière suivante :

• 0 = tout va bien (OK)
• 1 = avertissement (WARNING)
• 2 = alerte (CRITICAL)
• 3 = inconnu (UNKNOWN)

Il est aussi possible d’inclure un court message pour aider au diagnostique. Les plugins peuvent être écrits dans plusieurs langage (C, Perl, Bash…). Il existe deux grandes familles de plugins, celle qui fonctionne avec des agents dédiés (NRPE, NSCA) et celle qui fonctionne grâce au protocole SNMP. Les deux méthodes intègrent la notion de surveillance active et passive. Il est possible de récupérer l’information directement sur la machine controllée ou d’attendre qu’elle nous envoie l’information. L’agent Nagios actif est NRPE (Nagios Remote Plugin Executor) et l’agent passif est NSCA (Nagios Service Check Acceptor). Les plugins se reposant sur le protocole SNMP sont dit « actifs », mais il est possible d’utiliser le SNMP TRAP (information envoyée par le client) pour les afficher dans Nagios.

La notion d’ « état » concerne la situation d’un service ou d’un hôte. En effet, en plus du statut (OK, WARNING, UP, DOWN…) il faut prendre en compte l’état « SOFT » ou « HARD ». Cette notion d’état est indispensable à la logique de la supervision de Nagios car elle détermine quand les notification sont émises, tout en évitant les fausse alertes.

• L’état SOFT : est un état qui retourne un résultat différent de 0 mais qui n’a pas pour autant atteint le nombre maximum d’essai défini dans « max_check_attempts ». Cependant, Nagios ne renvoie pas de notification car le problème ne s’est pas encore avéré sérieux. A ce moment là, il est possible d’appeler le gestionnaire d’événements (processus de correction de l’alerte).

• L’état HARD : d’un service ou d’un hôte correspond à une vérification qui retourne toujours un résultat différent de 0 mais qui a dépassé la limite fixée dans « max_check_attempts ». A partir de ce moment, la notification est déclenchée.

Cette notion d’état est applicable à tous les changements de statuts imposés par les codes erreur des plugins. C’est un état dit « HARD » qui appelle la notification des contacts. De plus, si cet état perdure, Nagios continu les notifications, il faut donc bien paramétrer les espacements pour ne pas polluer la boîte mail.

La notion de dépendance a pour but de rendre une alerte pertinente. Il existe deux types de dépendances :

• entre services : Un service peut dépendre d’un ou plusieurs services de manière non héritée. Lorsque la dépendance est présente entre un service A et B, si B venait à passer en état « CRITICAL » la dépendance serait en erreur et les notifications ne seraient pas envoyées pour A. Ce principe de dépendance entre services est limité car elle est verticale. Nous verrons le procédé pour réaliser une dépendance horizontale.

• entre hôtes : Le principe est le même que celui des services. Les dépendances entre hôtes permettent seulement de désactiver les notifications mais pas les contrôles actifs. Dans le cas où nous supervisons un ensemble de machines situées derrière un routeur, si ce dernier venait à être défaillant, nous ne voulons pas générer des notifications pour les serveurs se trouvant derrière.

Afin de rendre possible la supervision en haute disponibilité, nous allons configurer des outils libres largement utilisés :

• ICINGA : Un des fork politique, stable et performant
• DRBD : Pour la synchronisation des données :
  • synchronisation de la configuration d'Icinga
  • synchronisation de Icinga-web
  • synchronisation de Icinga-reporting
  • synchronisation de la base de données
  • synchronisation du générateur de configuration pour Icinga : Icingen
• HEARTBEAT : Pour la gestion des bascules

Je vous propose de vous inspirer des ces articles afin de préparer votre machine :

• installation d'une CentOS : Comment installer une CentOs 6 ?
• RAID + LVM : Comment installer un système linux fiable et flexible avec mdadm, lvm et reiserfs ?
• synchronisation ntp : Comment installer/configurer un serveur de temps avec ntp ?

• Après avoir activer vos dépôts, vous pouvez installer DRBD :

yum install kmod-drbd83.x86_64 drbd83-utils.x86_64

• Edition du fichier de configuration : vim /etc/drbd.conf. (j'ai préféré regrouper toute la configuration dans un seul fichier car je n'ai qu'une seule ressource à partager.)

global { usage-count no; }
common {
syncer { rate 10M; }
}

resource data_sync {
  protocol C;
  startup { wfc-timeout 0; degr-wfc-timeout 120; }
  disk { on-io-error detach; }

  on icinga-1 {
    device    /dev/drbd1;
    disk      /dev/mapper/vg_icinga1-data_sync;
    address   192.168.218.101:7789;
    meta-disk internal;
  }
  on icinga-2 {
    device    /dev/drbd1;
    disk      /dev/mapper/vg_icinga2-data_sync;
    address   192.168.218.102:7789;
    meta-disk internal;
  }
}

• Création des matadata :

[root@icinga-1 ~]# drbdadm create-md data_sync
Writing meta data...
initializing activity log
NOT initialized bitmap
New drbd meta data block successfully created.

• Préparation de la synchronisation : (à faire sur les 2 node)

/etc/init.d/drbd stop
modprobe drbd
drbdadm attach data_sync
drbdadm connect data_sync

• Forcer la première synchronisation : (à faire sur le node principal)

drbdsetup /dev/drbd1 primary -o

• Vérifier la synchronisation :

cat /proc/drbd

version: 8.3.11 (api:88/proto:86-96)
GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by dag@Build64R6, 2011-08-08 08:54:05

 1: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
    ns:3094708 nr:0 dw:0 dr:3095704 al:0 bm:188 lo:4 pe:2 ua:7 ap:0 ep:1 wo:b oos:17384808
        [==>.................] sync'ed: 15.2% (16976/19996)M
        finish: 0:28:21 speed: 10,208 (10,244) K/sec

• Formatage de la partition :

mkfs.reiserfs /dev/drbd1

• Validation de la réplication :

1. se connecter à un node
2. prendre la ressource : drbdadm primary data_sync
3. réaliser le montage : mount /dev/drbd1 /opt
4. créer un fichier : touch test.txt
5. démonter le /opt : umount /opt
6. libérer la ressource : drbdadm secondary data_sync
7. se connecter sur l'autre node et réaliser les mêmes commandes afin de valider la présence du fichier test.txt

• Installation de Hearbeat :

yum install heartbeat.x86_64

• Création du fichier principal :

vim /etc/ha.d/ha.cf

debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility     local0
keepalive 2
deadtime 30
warntime 10
initdead 120
udpport 694
bcast   eth0
auto_failback on
node icinga-1
node icinga-2

• Création du fichier authkeys

vim /etc/ha.d/authkeys

auth 3
3 md5 IsJachnoab7

• Déclaration de la ressource à basculer :

vim /etc/ha.d/haresources

icinga-1 192.168.5.100 \
  drbddisk::data_sync \
  Filesystem::/dev/drbd1::/opt::reiserfs \
  mysqld \
  ido2db \
  icinga \
  httpd \

• Validation de la bacule :

/usr/share/heartbeat/hb_takeover all

harc[6509]:	2011/09/06_01:52:20 info: Running /etc/ha.d//rc.d/hb_takeover hb_takeover
Sep 06 01:52:20 icinga-2 heartbeat: [4271]: info: icinga-1 wants to go standby [all]
Sep 06 01:52:21 icinga-2 heartbeat: [4271]: info: standby: acquire [all] resources from icinga-1
Sep 06 01:52:21 icinga-2 heartbeat: [6526]: info: acquire all HA resources (standby).
ResourceManager[6539]:	2011/09/06_01:52:21 info: Acquiring resource group: icinga-1 192.168.5.100 drbddisk::data_sync Filesystem::/dev/drbd1::/opt::reiserfs
IPaddr[6567]:	2011/09/06_01:52:21 INFO:  Resource is stopped
ResourceManager[6539]:	2011/09/06_01:52:21 info: Running /etc/ha.d/resource.d/IPaddr 192.168.5.100 start
IPaddr[6630]:	2011/09/06_01:52:21 INFO: Using calculated nic for 192.168.5.100: eth0
IPaddr[6630]:	2011/09/06_01:52:21 INFO: Using calculated netmask for 192.168.5.100: 255.255.255.0
IPaddr[6630]:	2011/09/06_01:52:21 INFO: eval ifconfig eth0:0 192.168.5.100 netmask 255.255.255.0 broadcast 192.168.5.255
IPaddr[6616]:	2011/09/06_01:52:21 INFO:  Success
ResourceManager[6539]:	2011/09/06_01:52:21 info: Running /etc/ha.d/resource.d/drbddisk data_sync start
Filesystem[6778]:	2011/09/06_01:52:22 INFO:  Resource is stopped
ResourceManager[6539]:	2011/09/06_01:52:22 info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd1 /opt reiserfs start
Filesystem[6861]:	2011/09/06_01:52:22 INFO: Running start for /dev/drbd1 on /opt
Filesystem[6853]:	2011/09/06_01:52:22 INFO:  Success
Sep 06 01:52:22 icinga-2 heartbeat: [6526]: info: all HA resource acquisition completed (standby).
Sep 06 01:52:22 icinga-2 heartbeat: [4271]: info: Standby resource acquisition done [all].
Sep 06 01:52:22 icinga-2 heartbeat: [4271]: info: remote resource transition completed.

Si vous avez suivie la documentation Comment installer/configurer Icinga ?, vous avez compiler Icinga dans /opt/. Pour que la solution soit totalement fonctionnelle il ne faut pas oublier de déplacer la base de données sur le partage synchronisé.

vim my.cnf

datadir=/opt/mysql

Le principe de fonctionnement est relativement simple. Le but est de déclarer les mêmes services sur le “Cluster” que sur les hôtes distants. Cependant, les services déclarés ne sont pas de même type. Côté “R_EXEC” (hôte distant de supervision), les checks seront de type “actif”. Cela signifie que la vérification des services et hôtes sera réalisée en direct. Cependant, coté “Cluster”, les services seront totalement passifs. Cela signifie que le “Cluster” reçoit l'information venant des “R_EXEC”.

Pour faire le lien entre le “Cluster” et les “R_EXEC” j'utilise syslog-ng. Ce dernier centralise l'ensemble des logs de tous les “R_EXEC” et déclenche l'injection des informations à travers les commandes externes d'Icinga.

Ce qui est intéressant ce que l'on peut mixer la supervision distribuée / répartie et la supervision classique.

define host{
        active_checks_enabled   1
        passive_checks_enabled  0
        notifications_enabled   1
        check_freshness         1
        freshness_threshold     0
        }

define service{
        active_checks_enabled   1
        passive_checks_enabled  0
        notifications_enabled   1
        check_freshness         1
        freshness_threshold     0
        }

define host{
        active_checks_enabled   1 
        passive_checks_enabled  0
        notifications_enabled   0
        check_freshness         1
        freshness_threshold     0
        initial_state           d
        }

define service{
        active_checks_enabled   1
        passive_checks_enabled  0
        notifications_enabled   0
        check_freshness         1
        freshness_threshold     0
        initial_state           c
        }

Les commandes externes peuvent être utilisées pour accomplir une variété de choses alors que Nagios est en cours d'execution. Exemple de ce qui peut être fait :

• désactiver temporairement les notifications pour les hôtes et services
• désactiver temporairement les contrôles de services,
• forer les contrôles de services immédiats,
• l'ajout de commentaires aux hôtes et services

Injection de l'état d'un host

echocmd="/bin/echo"
CommandFile="/opt/icinga/var/rw/icinga.cmd"
datetime=`date +%s`
cmdline="[$datetime] PROCESS_HOST_CHECK_RESULT;'nom de la machine';'code l'état (0,1,2)';'message de la commande'"
`$echocmd $cmdline >> $CommandFile`

Injection de l'état d'un service

echocmd="/bin/echo"
CommandFile="/opt/icinga/var/rw/icinga.cmd"
datetime=`date +%s`
cmdline="[$datetime] PROCESS_SERVICE_CHECK_RESULT;'nom de la machine';'nom du service';'code retour (0,1,2 ou 3)';'le message de plugin'"
`$echocmd $cmdline >> $CommandFile`

Afin de correctement détecter l'état d'une machine, il faut activer l'option suivante :

passive_host_checks_are_soft=1

Si l'option est désactivée, chaque injection d'état de la machine sera considéré comme “HARD”, ce qui déclenchera une alerte.

Depuis le client, on exporte tous les logs.

@version:3.2

options {
        flush_lines (0);
        time_reopen (10);
        log_fifo_size (1000);
        long_hostnames (off);
        use_dns (no);
        use_fqdn (no);
        create_dirs (no);
        keep_hostname (yes);
};

source s_sys {
        file ("/proc/kmsg" program_override("kernel: "));
        unix-stream ("/dev/log");
        internal();
        # udp(ip(0.0.0.0) port(514));
        };
destination d_net { tcp("192.168.5.100"); };
log { source(s_sys); destination(d_net); };

Côté serveur, on récupère les informations des “R_EXEC” et on actionne les scripts suivant si l'information concerne une machine ou un hôte.

@version:3.2

options {
        flush_lines (0);
        time_reopen (10);
        log_fifo_size (1000);
        long_hostnames (off);
        use_dns (no);
        use_fqdn (no);
        create_dirs (no);
        keep_hostname (yes);
};

source s_sys {
        tcp(ip(0.0.0.0) port(514));
};

destination d_extcmdsvc {
program("/opt/icingen/external_cmd/external_cmd_service_check_result.sh"
);
};

destination d_extcmdhost {
program("/opt/icingen/external_cmd/external_cmd_host_check_result.sh"
);
};

Vous pouvez utiliser Icingen pour vous aidez à configurer Icinga. Il utilise le mode de fonctionnement décrit dans cette documentation afin de générer une configuration compatible Icinga / Nagios.