Nagios intègre l'ensemble des modules dérivés de la supervision

On y retrouve :

• La supervision réseau
• La supervision des ressources systèmes
• La supervision applicative
• La notification par différents moyens de communication
• L'exécution de commandes manuelles ou automatiques
• La représentation des états des ressources supervisées, par coloration
• La cartographie du système d'informations supervisé
• Le reporting

Architecture de Nagios                                                                            

Nagios repose sur un serveur web et des CGI. Il peut intégrer une base de données de type MySQL ou PostgreSQL pour y stocker des informations de supervision. Bien que conseillée, la base de donnée n'est pas essentielle dans le fontionnement de Nagios et peut être remplacée par de simples fichiers tournants, mais cette architecture doit être limitée à de petites installations avec un nombre de machines supervisées restreint.

L'architecture standard de Nagios peut donc être représentée de la manière suivante :

Le choix de mettre en place une base de données dépend de l'utilisation qui sera faite de Nagios et des données collectées.
Il faut cependant noter que 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ées par l'event broker.
Voir ./configure -help | grep -E "mysql|pgsql" pour plus d'informations.

Les plugins

Les plugin sont des programmes exécutables ou des scripts (perl, shell, etc..) qui peuvent être lancés depuis une ligne de commande pour tester un hôte ou un service.
Le résultat de l'exécution d'un plugin est utilisé par Nagios pour déterminer le statut des hôtes ou des services sur le réseau.

Le développement des plugins pour Nagios est fait sur SourceForge. La page du projet de développement de plugins pour Nagios (où vous trouverez toujours la dernière version des plugins) se trouve à http://sourceforge.net/projects/nagiosplug/

Les plugins développés pour Nagios doivent respecter un certain format d'affichage de retour afin de garantir leur intégration. Tous les plugins qui respectent les consignes minimales de développement pour ce projet contiennent une documentation interne. Cette documentation peut être affichée en exécutant le plugin avec le paramétre "-h" ("--help" si les paramétres longs sont activés).

Par exemple, si vous voulez savoir comment fonctionne le plugin check_http ou quels paramétres il accepte, vous devez saisir :

./check_httpd --help
ou
./check_httpd --h

Créer vos propres plugin pour les adpater à des services ou hôtes particuliers est possible. Vous pouvez trouver des informations à ce sujet sur http://sourceforge.net/projects/nagiosplug/

Les agents

Il est possible d'utiliser des agents de supervision permettant de récupérer des informations à distances. Ils offrent la possibilité de profiter de la puissance offerte par les plugins. Il existe 2 types d'agents :

• Les agents NRPE
• Les agents NCSA

Le principe de fonctionnement des agents nrpe (pour Nagios Remote Plugin Executor) est simple : les plugins sont installés sur l'équipement à superviser, compilés en fonction de son architecture car c'est elle qui va les exécuter, ainsi que le démon nrpe faisant office de serveur. Sur la plateforme de supervision Nagios, le plugin check_nrpe fera alors office de client nrpe, récupérant les informations en interrogeant le démon nrpe sur l'équipement concerné.

Le plugin check_nrpe sur le serveur Nagios initiera une connexion vers l'agent nrpe de la machine cible et lui demandera alors l'exécution d'une vérification. L'agent nrpe lancera alors le plugin configuré en local pour obtenir l'information et retournera le code retour de l'exécution ainsi que sa sortie standard.

Les agents ncsa (pour Nagios Service Check Acceptor) diffèrent des agents nrpe car la vérification est plannifiée en local sur l'équipement supervisé, exécutée, puis le résultat est envoyé au serveur Nagios. De même que pour nrpe, l'architecture ncsa demande la présence du plugin check_ncsa sur la plateforme Nagios.

Installation de Nagios                                                                              

L'installation et la configuration de Nagios ne sont pas aisées et peuvent nécessiter plusieurs jours avant d'être réalisées comme souhaité.
Il faut avoir une certaine expérience dans l'exploitation du système Linux et de ses composants ainsi que dans le fonctionnement de Nagios en général.
Ne pas hésiter à se référer à la documentation officielle

Pré-requis

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

Les pré-requis à l'installation sont les suivants :

• Un serveur web (ex: Apache)
• Une base de données (si utilisée)
• Les librairies graphiques suivantes : libgd 1.6.3 ou plus, libjpeg, libpng

Création d'un utilisateur nagios

Avant même d'installer 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

L'utilisateur nagios fait également partie du groupe apache pour des raisons pratiques .

Compilation et installation

Une fois les prérequis installés, et les sources récupérées sur le site officiel, la phase d'installation suit les étapes suivantes

Il faut commencer par la phase de compilation, avec les options choisies

# ./configure --options
# make all

Quand la compilation est terminée sans erreur, on peut passer à l'installation

# make install

Pour rendre Nagios complètement opérationnel, il reste quelques commandes à passer :

Installer le script de démarrage de Nagios /etc/init.d/nagios

# make install-init

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-commandmode

Installer un exemple de configuration de Nagios. Les fichiers de configuration ainsi créés verront leur nom se terminer par -sample, pour éviter ainsi d'écraser la configuration actuelle en cas d'upgrade

# make install-config

L'installation de Nagios est alors terminée. Il faut maintenant passer à la phase de configuration.

Configuration de Nagios                                                                           

Serveur web

L'accès à Nagios doit être restreint car il peut montrer des informations sensibles voire confidentielles concernant le système d'information.

Par ailleurs, des actions peuvent être entreprises via l'interface web, allant de l'acquiescement des alarmes jusqu'au redémarrage de machines.

Pour cette raison, il faut protéger l'accès aux CGI de Nagios, au travers le mécanisme d'authentification de votre serveur web (ex : mécanisme htpasswd pour Apache)

Nagios

La configuration de Nagios demande beaucoup de temps et n'est pas chose aisée. En effet, l'ensemble de la configuration du logiciel se fait dans des fichiers textes d'extension .cfg

L'ensemble des fichiers de configuration sont définis selon le format suivant

define type{
	attribut1	valeurs
	attribut2	valeurs
	...		valeurs
	}

Ce mécanisme de définition implique qu'aucun espace ne pourra être inséré dans les paramètres et leurs valeurs

La cohérence des fichiers de configuration peut être testée en exécutant Nagios avec l'option -v et en lui fournissant le fichier de configuration principal

# /etc/init.d/nagios -v [chemin d'accès au fichier nagios.cfg]

Nagios supervise les équipements à travers le réseau. Ils peuvent être des serveurs, des équipements réseaux, ou tout autre type de machine reliée au réseau.

Ces hosts peuvent être regroupés dans un ou plusieurs groups, permettant ainsi d'agir sur un ensemble de machines plutôt que sur chacune, une par une.

Viennent ensuite les services. Ils correspondent aux services testés par les plugins. Définis dans un fichier de configuration, les services font appel aux plugin via des commands elles-même définies dans un fichier checkcommands.cfg

L'ordonnancement de la vérification des services se fait elle selon des périodes de temps définis par les clauses timeperiod dans le fichier timeperiods.cfg

Le rôle de Nagios est donc de prévenir lorsqu'un problème survient. Les contacts à prévenir sont définis dans le fichier contacts.cfg et peuvent eux aussi être groupés dans le fichier contactgroups.cfg

L'escalade des alertes entre les groupes, en cas de non réponse, peut être définie dans le fichier escalations.cfg

Il reste alors le fichier misccommands.cfg dans lequel sont déclarées les commandes non-destinées au lancement de plugin. On y trouvera par exemple les commandes nécessaires à l'envoi de mail, de SMS, etc..

Enfin, d'autres fichiers peuvent également être utilisés tels que dependencies.cfg pour définir des dépendances entre services, cgi.cfg pour la configuration des CGI, hostextinfo.cfg pour les infos supplémentaires sur les hôtes (icône, coordonnées graphiques sur la statusmap, ...) et serviceextinfo.cfg idem que hostextinfo.cfg mais pour les services.

Les principaux fichiers de configuration sont donc les suivants :

• nagios.cfg
• ressource.cfg
• hosts.cfg
• hostgroups.cfg
• services.cfg
• servicegroups.cfg
• checkcommands.cfg
• misccommands.cfg
• timeperiods.cfg
• contacts.cfg
• contactgroups.cfg
• escalations.cfg
• dependencies.cfg
• cgi.cfg
• hostextinfo.cfg
• serviceextinfo.cfg

nagios.cfg

Il s'agit du fichier principal de configuration de Nagios. Il contient notamment la liste des autres fichiers de configuration utilisés, ainsi que l'ensemble des directives globales de fonctionnement de Nagios, comme le nom et le groupe de l'utilisateur nagios.

ressource.cfg

Il s'agit d'un fichier de déclaration utilisé par les autres fichiers de configuration de Nagios. Il permet de définir des variables globales pour une utilisation simplifiée dans les autres fichiers de configuration (ex : $USER1$=/usr/local/nagios/libexec).

hosts.cfg

Fichier de configuration des équipements supervisés. Une définition d'hôte s'applique à un serveur "physique", une station de travail, un périphérique, un équipement, qui se trouve sur votre réseau. Chaque hôte saisi nécessite une structure particulière, incluant notamment son nom, son adresse IP, le type de test à effectuer pour caractériser l'état de l'hôte (généralement ping)...

Exemple de définition d'un host

define host{
	host_name			bogus-router
	alias				Bogus Router #1
	address				192.168.1.254
	parents				server-backbone
	check_command			check-host-alive
	max_check_attempts		5
	process_perf_data		0
	retain_nonstatus_information	0
	notification_interval		30
	notification_period		24x7
	notification_options		d,u,r
	}

hostgroups.cfg

Il contient les groupes d'hôtes permettant ensuite d'agir sur un ensemble de machines.

define hostgroup{
	hostgroup_name		novell-servers
	alias			Novell Servers
	contact_groups		novell-admins
	members			netware1,netware2,netware3,netware4
	}

services.cfg

Fichier de configuration des services supervisés. La définition d'un service identifie un service tournant sur un hôte. Le terme "service" est très générique. Il peut s'appliquer à un service ( tel que POP, SMTP, HTTP, etc.) ou bien tout autre type de mesure associée à l'hôte (temps de réponse à un ping, nombre d'utilisateurs connectés, usage des disques).

Exemple de définition d'un service supervisé

define service{
	host_name		linux-server
	service_description	check-disk-sda1
	check_command		check-disk!/dev/sda1
	max_check_attempts	5
	normal_check_interval	5
	retry_check_interval	3
	check_period		24x7
	notification_interval	30
	notification_period	24x7
	notification_options	w,c,r
	contact_groups		linux-admins
	}

servicegroups.cfg

Il contient les groupes de services permettant ensuite d'agir sur des ensembles de services.

checkcommands.cfg

Fichier de configuration des commandes de supervision

define command{
	command_name	check_pop
	command_line	/usr/local/nagios/libexec/check_pop -H $HOSTADDRESS$	
	}

misccommands.cfg

Fichier de configuration des commandes de notification

timeperiods.cfg

Fichier de configuration des calendriers

define timeperiod{
	timeperiod_name		nonworkhours
	alias			Non-Work Hours
	sunday			00:00-24:00
	monday			00:00-09:00,17:00-24:00
	tuesday			00:00-09:00,17:00-24:00
	wednesday		00:00-09:00,17:00-24:00
	thursday		00:00-09:00,17:00-24:00
	friday			00:00-09:00,17:00-24:00
	saturday		00:00-24:00
	}

contacts.cfg

Fichier de définition des contacts à notifier. Une définition de contact s'applique à la personne physique qui doit être contactée en cas de problèmes sur le réseau.

Exemple de définition d'un contact à notifier

define contact{
	contact_name                    jdoe
	alias                           John Doe
	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-by-email
	host_notification_commands      host-notify-by-email
	email				jdoe@localhost.localdomain
	pager				555-5555@pagergateway.localhost.localdomain
	}

contactgroups.cfg

Il contient les groupes de contacts permettant ainsi de regrouper les contacts à notifier en cas d'alerte.

define contactgroup{
	contactgroup_name		novell-admins
	alias			Novell Administrators
	members			jdoe,rtobert,tzach
	}

escalations.cfg

Il défini l'escalade des alertes entre les différents groupes de contacts.

define serviceescalation{
	host_name		nt-3
	service_description	Processor Load
	first_notification	4
	last_notification	0
	notification_interval	30
	contact_groups		all-nt-admins,themanagers
	}

define hostescalation{
	host_name		router-34
	first_notification	5
	last_notification	8
	notification_interval	60
	contact_groups		all-router-admins
	}

define hostgroupescalation{
	hostgroup_name		netware-servers
	first_notification	5
	last_notification	0
	notification_interval	30
	contact_groups		netware-admins,themanagers
	}

dependencies.cfg

Il définit les dépendances entre les différents services, qu'ils soient sur le même serveur ou non. On peut ainsi par exemple faire dépendre le serveur web virtuel de la présence d'un processus Apache.

define hostdependency{
	host_name			WWW1
	dependent_host_name		DBASE1
	notification_failure_criteria	d,u
	}

cgi.cfg

Il définit la configuration des CGI de Nagios utilisés dans l'interface graphique web.

hosttextinfo.cfg

Il permet d'ajouter des propriétés graphiques aux hôtes définis dans hosts.cfg comme par exemple une icône ou des coordonnées à utiliser dans la statusmap de l'interface web.

define hostextinfo{
	host_name	netware1
	notes_url	http://webserver.localhost.localdomain/hostinfo.pl?host=netware1
	icon_image	novell40.png 
	icon_image_alt	IntranetWare 4.11
	vrml_image	novell40.png
	statusmap_image	novell40.gd2
	2d_coords	100,250
	3d_coords	100.0,50.0,75.0
	}

serviceextinfo.cfg

Idem que hostextinfos mais pour les services.

define serviceextinfo{
	host_name		linux2
	service_description	Log Anomalies
	notes_url		http://webserver.localhost.localdomain/serviceinfo.pl?host=linux2&service=Log+Anomalies
	icon_image		security.png 
	icon_image_alt		Security-Related Alerts
	}

L'interface de Nagios                                                                               

L'interface de Nagios est accessible via un simple navigateur web. Elle permet à l'administrateur d'avoir accès à l'ensemble des informations de supervision.
Basée sur des CGI, cette interface peut donc être sécurisée par les mécanismes associés au serveur web et aux CGI afin de restreindre les accès aux informations en fonction des profils utilisateurs.

Elle est composée de deux grands types de vues :

• Monitoring
• Reporting

Il est également possible d'accéder à la configuration du logiciel via cette interface, mais uniquement en lecture :-(

Les vue de Monitoring

Les vues de monitoring permettent de connaître l'état des équipements et des services supervisés, et éventuellement d'effectuer des actions sur ces derniers.