Nagios : configuration

Un premier article a rapidement expliqué l’installation de base de l’outil de surveillance Nagios sur une machine CentOS. La portée de cette surveillance reste locale à la machine où tourne Nagios après son installation. Cette partie va aller un peu plus loin en décortiquant un peu le mode de configuration de celui-ci.

Ce qui suit va rester assez bref pour permettre une mise en pratique rapide, pour un approfondissement du fonctionnement et de la configuration de Nagios, se reporter à la documentation officielle sur le site de l’éditeur et/ou de son miroir français.

Sous CentOS, la configuration se trouve sous /etc/nagios et les objets sous /etc/nagios/objects, répertoire qui regroupe un certain nombre de fichiers à l’extension .cfg. Le fichier principal étant nagios.cfg.

Objets

Tout est objet dans la configuration de Nagios. Cette notion parle certainement un peu plus aux programmeurs. Un objet peut-être une machine, un service (SSH, IMAP), un contact (qui va recevoir les alertes), une commande (check_ssh, check_ping), etc. On définit des objets un peu comme bon nous semble, même si certaines règles doivent être respectées. Un objet peut hériter des propriétés d’un autre, cela simplifie et organise la configuration du serveur et permet de le faire évoluer plus simplement et intelligemment. Par exemple, certains types d’objets ont des propriétés obligatoires – parfois beaucoup – il serait fastidieux et rébarbatif de devoir les ré-écrire pour tous les équipements de même type de notre réseau. On va donc pouvoir créer un objet gabarit regroupant les caractéristiques générales puis pour l’ajout de nouveaux hôtes, équipements ou services, on ne renseignera que le minimum, en s’affranchissant même des propriétés obligatoires, car on va dire que notre hôte ou équipement ou service va hériter de notre objet modèle qui lui possède les propriétés obligatoires.

Par exemple, voici les directives obligatoires (il y en a beaucoup d’autres, voir ici la liste complète) d’un objet host :

{
	host_name               host_name
	alias                   alias
	address                 address
	max_check_attempts      #
	check_period            timeperiod_name
	contacts                contacts
	contact_groups          contact_groups
	notification_interval   #
	notification_period     timeperiod_name
	}

Et voici un exemple d’un de mes hôtes :

define host{
	use                             linux-server
	host_name                       pelargir
	alias                           Mac Mini
	address                         192.168.10.3
	check_command                   check-host-alive        
	}

On voit qu’il manque pas mal de choses normalement obligatoires. Mais cette définition utilise un gabarit linux-server appelé par use en début de définition et tout ce qui est générique (et obligatoire) est dedans. Je n’ai pas à les répéter pour tous les hôtes.

Ajout d’hôtes

Cet exemple m’amène à montrer comment on ajoute un hôte distant dans Nagios. Pour ce faire, j’ai crée un fichier hosts.cfg sous /etc/nagios/objects/, et je mets mes machines dedans ainsi que leurs services associés. C’est une méthode qui reste gérable sur un parc avec peu de machines, ensuite d’autres stratégies peuvent être déployées, par exemple séparer dans des fichiers distincts les hôtes des services, les serveurs des stations ou des routeurs. Rien n’est figé.

Il faut maintenant que Nagios sache lire le nouveau fichier des hôtes, pour cela il suffit d’ajouter une directive cfg_file dans le fichier principal nagios.cfg pointant vers le fichier :

cfg_file=/etc/nagios/objects/hosts.cfg

Voici le contenu du fichier hosts.cfg avec une machine distante ajoutée, un Mac Mini qui est ma station de travail :

define host{
	use                             linux-server
	host_name                       pelargir
	alias                           Mac Mini
	address                         192.168.10.3
	check_command                   check-host-alive        
	}

define service{
	use                             generic-service
	host_name                       pelargir
	service_description             PING
	check_command                   check_ping!100.0,20%!500.0,60%
	}

define service{
	use                             generic-service
	host_name                       pelargir
	service_description             SSH
	check_command                   check_ssh
	}

Deux choses sont vérifiés pour cet hôte, d’abord qu’elle est présente sur le réseau en répondant aux ping et on vérifie que le service SSH est fonctionnel. On peut voir que la définition des objets service reste courte car ceux-ci héritent du gabarit generic-service qui définit tout ce qui sera standard pour les services.
A noter la différence entre check-host-alive et le service check_ping, Nagios dans sa surveillance va vérifier les services d’un hôte et s’il y a un problème, alors il va vérifier que l’hôte est alive. Il n’y a donc pas vraiment redondance dans la vérification (car check-host-alive est un ping également).

Autre exemple qui reprend le même principe, l’ajout d’un routeur (Neufbox) dans le fichier hosts.cfg :

define host{
	use                             generic-switch
	host_name                       gateway
	alias                           neufbox
	address                         192.168.10.1
	check_command                   check-host-alive
	}

define service{
	use                             generic-service
	host_name                       gateway
	service_description             PING
	check_command                   check_ping!100.0,20%!500.0,60%
	}

La seule vérification que le routeur existe sur le réseau par un ping est faîte. Avec ces deux ajouts, voici à quoi ressemble la page services sur Nagios :

Ce tableau parle de lui-même. La première colonne représente l’hôte en question, puis le service vérifié. Le statut de ce service est bien visible, d’autres états peuvent être en jaune pour un warning, orange pour un état inconnu ou rouge pour un état critique. Ensuite la date de la dernière vérification est affichée, puis la durée de fonctionnement de ce service depuis qu’il est vérifié par Nagios. Un objet surveillé peut (et doit) être vérifié plusieurs fois, ce paramètre est d’ailleurs définit, s’il ne répond pas au bout de ce nombre d’essais, alors son statut change. C’est ce que la colonne Attempt renseigne, ici on voit que tous les services ont été vérifiés une seule fois car tout fonctionne. Et la dernière colonne donne un peu plus d’informations relatives au service vérifié.


Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *