Product SiteDocumentation Site

12.4. Supervision

La supervision couvre plusieurs aspects et répond à plusieurs problématiques. D'une part, il s'agit de suivre dans le temps l'évolution de l'usage des ressources offertes par une machine donnée, afin d'anticiper la saturation et les besoins de mises à jour. D'autre part, il s'agit d'être alerté en cas d'indisponibilité ou de dysfonctionnement d'un service afin d'y remédier dans les plus brefs délais.
Munin répond très bien à la première problématique en proposant sous forme graphique des historiques de nombreux paramètres (usage mémoire vive, usage disque, charge processeur, trafic réseau, charge de Apache/MySQL, etc.). Nagios répond à la seconde en vérifiant très régulièrement que les services sont fonctionnels et disponibles et en remontant les alertes par les canaux appropriés (souvent par le courrier électronique, parfois avec des SMS, etc.). Les deux logiciels sont conçus de manière modulaire : il est relativement aisé de créer de nouveaux greffons (plug-ins) pour surveiller des services ou paramètres spécifiques.

ALTERNATIVE Zabbix, un système de supervision intégré

Bien que Munin et Nagios soient très répandus, ils ne sont pas les seuls logiciels permettant la supervision et ils ne traitent qu'une partie de la problématique (graphage ou alerte). On citera notamment Zabbix. Il intègre les deux activités en un seul logiciel et est pour partie configuré via une interface web. Il s'est grandement amélioré dans les dernières années et peut être considéré comme une alternative viable. Sur le serveur de supervision, il faut installer zabbix-server-pgsql (ou zabbix-server-mysql), la plupart du temps avec zabbix-frontend-php pour disposer d'une interface web. Sur les hôtes à superviser, il faut installer zabbix-agent afin qu'ils puissent remonter les informations pertinentes au serveur.
→ http://www.zabbix.org/

ALTERNATIVE Icinga, un fork de Nagios

Suite à des divergences d'opinion concernant le développement de Nagios (qui est contrôlé par une entreprise), un certain nombre de développeurs ont créé Icinga en repartant de Nagios. Le logiciel reste compatible — pour le moment — avec les configurations et greffons Nagios, mais ajoute des fonctionnalités supplémentaires.
→ http://www.icinga.org/

12.4.1. Mise en œuvre de Munin

Ce logiciel permet de superviser de nombreuses machines ; il emploie donc fort logiquement une architecture client/serveur. Une machine centrale — le grapheur — va collecter les données exportées par tous les hôtes à superviser, pour en faire des graphiques historiques.

12.4.1.1. Configuration des hôtes à superviser

La première étape consiste à installer le paquet munin-node. Ce dernier contient un démon qui écoute sur le port 4949 et qui renvoie toutes les valeurs collectées par l'ensemble des greffons actifs. Chaque greffon est un simple programme qui peut renvoyer une description des informations qu'il collecte ainsi que la dernière valeur constatée. Ils sont placés dans /usr/share/munin/plugins/ mais seuls ceux qui sont liés dans /etc/munin/plugins/ sont réellement employés.
L'installation initiale du paquet préconfigure une liste de greffons actifs en fonction des logiciels disponibles et de la configuration actuelle de la machine. Ce paramétrage automatique dépend d'une fonctionnalité intégrée à chaque greffon et il n'est pas toujours judicieux d'en rester là. Il est intéressant de naviguer sur la galerie des greffons, même si tous les greffons ne disposent pas d'une documentation complète. Cela dit, tous les greffons sont des scripts, souvent relativement simples et contenant quelques commentaires explicatifs. Il ne faut donc pas hésiter à faire le tour de /etc/munin/plugins/ pour supprimer les greffons inutiles. De même, on peut activer un greffon intéressant repéré dans /usr/share/munin/plugins/ avec une commande ln -sf /usr/share/munin/plugins/greffon /etc/munin/plugins/. Attention, les greffons dont le nom se termine par un tiret souligné (_) sont particuliers, ils ont besoin d'un paramètre. Celui-ci doit être intégré dans le nom du lien symbolique créé (par exemple le greffon if_ sera installé avec un lien symbolique if_eth0 pour surveiller le trafic sur l'interface réseau eth0).
Une fois tous les greffons correctement mis en place, il faut paramétrer le démon pour indiquer qui a le droit de récupérer ces valeurs. Cela s'effectue dans le fichier /etc/munin/munin-node.conf avec une directive allow. Par défaut, on trouve allow ^127\.0\.0\.1$ qui n'autorise l'accès qu'à l'hôte local. Il convient d'ajouter une ligne similaire contenant l'adresse IP de la machine qui va assumer le rôle de grapheur puis de relancer le démon avec service munin-node restart.

POUR ALLER PLUS LOIN Créer ses propres greffons

Munin dispose d'une documentation conséquente sur le fonctionnement théorique de ces greffons et sur la manière d'en développer de nouveaux.
→ http://munin-monitoring.org/wiki/plugins
Pour tester le greffon, il convient de le lancer dans les mêmes conditions que munin-node le ferait en exécutant munin-run greffon en tant qu'utilisateur root. Le deuxième paramètre éventuel (comme config) est réemployé comme paramètre lors de l'exécution du greffon.
Lorsque le greffon est appelé avec le paramètre config, il doit renvoyer un ensemble de champs le décrivant, par exemple : 
$ sudo munin-run load config
graph_title Load average
graph_args --base 1000 -l 0
graph_vlabel load
graph_scale no
graph_category system
load.label load
graph_info The load average of the machine describes how many processes are in the run-queue (scheduled to run "immediately").
load.info 5 minute load average
Les différents champs qu'il est possible de renvoyer sont décrits sur une page web décrivant le « protocole de configuration ».
→ http://munin.readthedocs.org/en/latest/reference/plugin.html
Lorsque le greffon est appelé sans paramètre, il renvoie simplement les dernières valeurs associées ; ainsi l'exécution de sudo munin-run load retourne par exemple load.value 0.12.
Enfin, lorsque le greffon est appelé avec autoconf comme paramètre, il renvoie « yes » (avec un code retour à 0) ou « no » (avec un code de retour à 1) pour signifier si oui ou non le greffon devrait être activé sur cette machine.

12.4.1.2. Configuration du grapheur

Par grapheur, on entend simplement la machine qui va collecter les données et générer les graphiques correspondants. Le paquet correspondant à installer est munin. La configuration initiale du paquet lance munin-cron toutes les 5 minutes. Ce dernier collecte les données depuis toutes les machines listées dans /etc/munin/munin.conf (uniquement l'hôte local par défaut), stocke les historiques sous forme de fichiers RRD (Round Robin Database est un format de fichier adapté au stockage de données variant dans le temps) dans /var/lib/munin/ et régénère une page HTML avec des graphiques dans /var/cache/munin/www/.
Il faut donc éditer /etc/munin/munin.conf pour y ajouter toutes les machines à surveiller. Chaque machine se présente sous la forme d'une section complète portant son nom et contenant une entrée address qui indique l'adresse IP de la machine à superviser. 
[ftp.falcot.com]
    address 192.168.0.12
    use_node_name yes
Les sections peuvent être plus élaborées et décrire des graphiques supplémentaires à créer à partir de la combinaison de données provenant de plusieurs machines. On peut s'inspirer des exemples fournis dans le fichier de configuration.
Enfin, la dernière étape consiste à publier les pages générées. Il faut configurer votre serveur web pour que l'on puisse accéder au contenu de /var/cache/munin/www/ par l'intermédiaire d'un site web. On choisira généralement de restreindre l'accès soit à l'aide d'un système d'authentification, soit en fournissant une liste d'adresses IP autorisées à consulter ces informations. La Section 11.2, « Serveur web (HTTP) » fournit les explications nécessaires.

12.4.2. Mise en œuvre de Nagios

Contrairement à Munin, Nagios ne nécessite pas forcément d'installer quoi que ce soit sur les machines à superviser. En effet, il est fréquemment employé simplement pour vérifier la disponibilité de certains services réseau. Par exemple, Nagios peut se connecter à un serveur web et vérifier qu'il peut récupérer une page web donnée dans un certain délai.

12.4.2.1. Installation

La première étape est donc d'installer les paquets nagios3, nagios-plugins et nagios3-doc. Une fois cela effectué, l'interface web de Nagios est d'ores et déjà configurée et un premier utilisateur nagiosadmin (dont le mot de passe vient d'être saisi) peut y accéder. Il est possible d'ajouter d'autres utilisateurs en les insérant dans le fichier /etc/nagios3/htpasswd.users à l'aide de la commande htpasswd de Apache. Si aucune question debconf n'est apparue au cours de l'installation, il est possible d'exécuter dpkg-reconfigure nagios3-cgi pour définir le mot de passe de l'utilisateur nagiosadmin.
En se connectant sur http://serveur/nagios3/, on découvre l'interface web et l'on peut constater que Nagios surveille déjà certains paramètres de la machine sur laquelle il fonctionne. Cependant, en essayant d'utiliser certaines fonctionnalités interactives comme l'ajout de commentaires concernant un hôte, on constate qu'elles ne fonctionnent pas. Par défaut, Nagios est effectivement configuré de manière très restrictive (pour plus de sécurité) et ces fonctionnalités sont désactivées.
En consultant /usr/share/doc/nagios3/README.Debian on comprend qu'il faut éditer /etc/nagios3/nagios.cfg et positionner le paramètre check_external_commands à « 1 ». Puis il faut changer les permissions d'écriture sur un répertoire employé par Nagios avec ces quelques commandes : 
# service nagios3 stop
[...]
# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
# service nagios3 start
[...]

12.4.2.2. Configuration

L'interface web de Nagios est relativement plaisante, mais elle ne permet pas de le configurer. Il n'est pas possible d'ajouter des hôtes et des services à surveiller. Toute la configuration de ce logiciel s'effectue par un ensemble de fichiers référencés par le fichier de configuration central /etc/nagios3/nagios.cfg.
Avant de plonger dans ces fichiers, il faut se familiariser avec les concepts de Nagios. La configuration liste un ensemble d'objets de différents types :
  • Un hôte (host) est une machine du réseau que l'on souhaite surveiller;
  • Un hostgroup est un ensemble d'hôtes que l'on souhaite regrouper pour un affichage plus clair ou pour factoriser des éléments de configuration;
  • Un service est un élément à tester qui concerne un hôte ou un groupe d'hôtes. En général, il s'agit effectivement de vérifier le fonctionnement de « services » réseau, mais il peut s'agir de vérifier que des paramètres soient dans un intervalle acceptable (comme l'espace disque ou la charge CPU);
  • Un servicegroup est un ensemble de services que l'on souhaite regrouper dans l'affichage;
  • Un contact est une personne qui peut recevoir des alertes;
  • Un contactgroup est un ensemble de contacts à avertir;
  • Une timeperiod est une plage horaire pendant laquelle certains services doivent être vérifiés;
  • Une commande (command) est une ligne de commande à exécuter pour tester un service donné.
Chaque objet a un certain nombre de propriétés (selon son type) qu'il est possible de personnaliser. Une liste exhaustive serait trop longue, mais les relations entre ces objets sont les propriétés les plus importantes.
Un service emploie une commande pour vérifier l'état d'une fonctionnalité sur un hôte ou un groupe d'hôtes dans une plage horaire donnée. En cas de problèmes, Nagios envoie une alerte à tous les membres du contactgroup associé au service défaillant. Chaque membre est alerté selon les modalités précisées dans son objet contact correspondant.
Une fonctionnalité d'héritage entre les objets permet de partager facilement un ensemble de propriétés entre un grand nombre d'objets, tout en évitant une duplication de l'information. Par ailleurs, la configuration initiale comporte un certain nombre d'objets standards et, dans la plupart des cas, il suffit de définir de nouveaux hôtes, services et contacts en héritant des objets génériques prédéfinis. La lecture des fichiers de /etc/nagios3/conf.d/ permet de se familiariser avec ceux-ci.
Voici la configuration employée par les administrateurs de Falcot :

Exemple 12.3. Fichier /etc/nagios3/conf.d/falcot.cfg

define contact{
    name                            generic-contact
    service_notification_period     24x7
    host_notification_period        24x7
    service_notification_options    w,u,c,r
    host_notification_options       d,u,r
    service_notification_commands   notify-service-by-email
    host_notification_commands      notify-host-by-email
    register                        0 ; Template only
}
define contact{
    use             generic-contact
    contact_name    rhertzog
    alias           Raphael Hertzog
    email           hertzog@debian.org
}
define contact{
    use             generic-contact
    contact_name    rmas
    alias           Roland Mas
    email           lolando@debian.org
}

define contactgroup{
    contactgroup_name     falcot-admins
    alias                 Falcot Administrators
    members               rhertzog,rmas
}

define host{
    use                   generic-host ; Name of host template to use
    host_name             www-host
    alias                 www.falcot.com
    address               192.168.0.5
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}
define host{
    use                   generic-host ; Name of host template to use
    host_name             ftp-host
    alias                 ftp.falcot.com
    address               192.168.0.6
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}

# commande 'check_ftp' avec paramètres personnalisés
define command{
    command_name          check_ftp2
    command_line          /usr/lib/nagios/plugins/check_ftp -H $HOSTADDRESS$ -w 20 -c 30 -t 35
}

# Service générique à Falcot
define service{
    name                  falcot-service
    use                   generic-service
    contact_groups        falcot-admins
    register              0
}
# Services à vérifier sur www-host
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTP
    check_command         check_http
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTPS
    check_command         check_https
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   SMTP
    check_command         check_smtp
}
# Services à vérifier sur ftp-host
define service{
    use                   falcot-service
    host_name             ftp-host
    service_description   FTP
    check_command         check_ftp2
}
Ce fichier de configuration définit deux hôtes à surveiller. Le premier concerne le serveur web de Falcot ; on y surveille le fonctionnement du serveur web sur le port HTTP (80) et sur le port HTTP sécurisé (443). On vérifie également qu'un serveur SMTP est accessible sur son port 25. Le second concerne le serveur FTP et l'on vérifie qu'on obtient une réponse en moins de 20 secondes. Au-delà de ce délai, une mise en garde (warning) est générée et, au-delà de 30 secondes, une alerte critique. En se rendant sur l'interface web, on peut se rendre compte que le service SSH est également surveillé : cette surveillance est due à l'appartenance des hôtes au groupe ssh-servers. Le service standard correspondant est défini dans /etc/nagios3/conf.d/services_nagios2.cfg.
On peut noter l'usage de l'héritage : pour hériter d'un autre objet, on emploie la propriété use nom-parent. Pour identifier un objet dont on veut hériter, il faut lui attribuer une propriété name identifiant. Si l'objet parent n'est pas un objet réel, mais est uniquement destiné à servir de rôle de parent, on lui ajoute la propriété register 0 qui indique à Nagios de ne pas le considérer et donc d'ignorer l'absence de certains paramètres normalement requis.

DOCUMENTATION Liste des propriétés des objets

Pour avoir une meilleure idée des nombreuses possibilités de paramétrage de Nagios, il faut consulter la documentation fournie par le paquet nagios3-doc. Elle est directement accessible depuis l'interface web via le lien Documentation en haut à gauche. On y trouve notamment une liste exhaustive des différents types d'objets avec toutes les propriétés que l'on peut leur affecter. Il est également expliqué comment créer de nouveaux greffons.

POUR ALLER PLUS LOIN Tests distants avec NRPE

De nombreux greffons de Nagios permettent de vérifier l'état de certains paramètres locaux d'une machine. Si l'on souhaite effectuer ces vérifications sur de nombreuses machines tout en centralisant les résultats sur une seule installation, il faut employer le greffon NRPE (Nagios Remote Plugin Executor). On installe nagios-nrpe-plugin sur le serveur Nagios et nagios-nrpe-server sur les machines sur lesquelles on veut exécuter certains tests locaux. Ce dernier se configure par le biais du fichier /etc/nagios/nrpe.cfg. On y indique les tests que l'on peut démarrer à distance ainsi que les adresses IP des machines qui sont autorisées à les déclencher. Du côté de Nagios, il suffit d'ajouter les services correspondants en faisant appel à la nouvelle commande check_nrpe.