Docs:Centreon1.4/fr

From Wiki Centreon

Contents 1 INTRODUCTION 2 Présentation de la solution 2.1 Présentation de Nagios 2.2 Présentation d’Oreon 2.3 Choix d’Oreon / Nagios 3 Installation 3.1 Récapitulatifs des pré-requis 3.2 Installation des prés requis 3.3 Installation sur un seul serveur 3.3.1 Installation de Nagios 3.3.2 Configuration rapide de Nagios 3.3.3 Installation d’Oreon 3.4 Installation sur plusieurs serveurs 3.4.1 Rôle d’un serveur réparti 3.4.2 Installation des prés requis 3.4.3 Installation d’un serveur réparti 4 Configuration et paramétrage 4.1 Configuration sur un serveur 4.1.1 Configuration d’Oreon 4.1.1.1 Option d’Oreon 4.1.1.2 Option de Nagios 4.1.1.3 Option des couleurs 4.1.1.4 Option SNMP<ref>SNMP : voir le chapitre qu'est-ce que le SNMP.</ref>. 4.1.1.5 Option LDAP 4.1.1.6 Option de RRDTool 4.1.1.7 Option des fichiers de log et de débogage 4.1.1.8 Option de personnalisation de l’interface graphique d’Oreon 4.1.1.9 Option d’OreonDataStorage 4.1.2 Configuration de Nagios 4.1.2.1 Les Utilisateurs 4.1.2.2 Les Hosts 4.1.2.3 Les services 4.1.2.4 Les commandes 4.1.2.5 Les escalades 4.1.2.6 Les dépendances 4.1.2.7 Nagios 4.1.3 Configuration de Nagios et d’Oreon pour l’obtention de graphiques. 4.2 Configuration sur plusieurs serveurs 4.2.1 Compréhension et mise en fonction des commandes externes 4.2.2 Mise en place du démon et du client NSCA 4.2.2.1 Mise en place du démon NSCA pour le serveur central 4.2.2.2 Mise en place du client NSCA pour les serveurs répartis 4.2.3 Configuration du serveur central 4.2.4 Configuration des serveurs répartis 4.2.5 Configuration pour les hôtes. 5 Les plugins 5.1 Fonctionnement des plugins 5.1.1 Plugins de contrôle 5.1.2 Plugins de notification 5.1.3 Plugins d’évènement 5.1.4 Utilisation des plugins 6 Le SNMP, les démons NSCA/NRPE 6.1 Le protocole SNMP 6.1.1 Qu’est-ce que le SNMP 6.1.1.1 En pratique 6.1.1.2 La MIB 6.1.1.3 Le protocole 6.1.1.4 Installation et configuration 6.2 Le NSCA 6.3 Le NRPE 7 Exemple de base 7.1 Démarche à suivre 7.2 Exemple d’utilisateur 7.3 Exemple de groupe d’utilisateurs 7.4 Exemple d’hôte 7.5 Exemple de groupe d’hôtes 7.6 Exemple de service 7.7 Exportation de la configuration et redémarrage de Nagios 8 L’interface d’Oreon 8.1 L’accueil 8.2 Le Monitoring 8.3 Le reporting 8.4 La vue Oreon 8.5 Les fiches d’identités 9 Exemple de monitoring 9.1 Station Windows 9.1.1 Intégration de l’hôte 9.1.2 Intégration de la commande de contrôle CPU 9.1.3 Intégration de la commande de contrôle de l’espace disque 9.1.4 Intégration de la commande de contrôle de la mémoire 9.2 Station Linux 9.2.1 Intégration de l’hôte 9.2.2 Intégration de la commande de contrôle CPU 9.2.3 Intégration de la commande de contrôle de l’espace disque 9.2.4 Intégration de la commande de contrôle de la mémoire 9.3 Switch Nortel 10 Création d’une cartographie 11 Conclusion : 12 Répertoire des illustrations: 13 Bibliographie :

INTRODUCTION

Aujourd’hui, la place des réseaux est devenue prépondérante, voire indispensable. En effet, la majorité des entreprises et des administrations, disposent d’un réseau privé afin de communiquer soit au sein de l’organisation, ou avec des filiales.

On comprend mieux qu’un dysfonctionnement aura de graves répercutions financières, car il pénalise toute l’activité.

D’où la nécessité d’avoir :

• Une vue d’ensemble sur le réseau
• Vérifier la continuité de service
• Contrôler la présence de panne.

Par conséquent, il faut des indicateurs afin de répondre à tous ces besoins. Il existe des solutions propriétaires coûteuses, mais aussi des logiciels libres qui nécessitent un paramétrage et du temps. Toutes ces solutions reposent sur le protocole SNMP.

Une de ses solutions libres est l’intégration des logiciels Nagios et Oreon.

Tout d’abord, il y a une brève présentation du produit sélectionné. Ensuite, il est défini comment installer le produit de façon à ce qu’il soit entièrement opérationnel avec toutes ses sous-fonctions. La configuration et le paramétrage du produit avec les différents plugins et protocoles y sont détaillés avec des exemples de monitoring.

Enfin, il y a une description de création d’une cartographie du réseau.

Présentation de la solution

Présentation de Nagios

Nagios est un logiciel libre de surveillance réseau. Il a été conçu pour informer les utilisateurs de la présence de problèmes sur les hôtes et les services spécifiés. Cela se nomme la notification.

Pour recevoir des notifications, les utilisateurs doivent au préalable configurer le logiciel, pour lui indiquer quand les envoyer et où les envoyer. En effet, Nagios est capable d’informer l’administrateur par mail, SMS, messagerie instantanée.

Fonctionnalités :

• Une Surveillance des services réseau (SMTP, POP3, HTTP, NNTP, PING, etc.)
• Une Surveillance des ressources des hôtes (charge processeur, utilisation des disques, etc.)
• Un Système simple de plugins permettant aux utilisateurs de développer facilement leurs propres vérifications de services.
• Une Parallélisations de la vérification des services. Pour limiter la charge CPU.
• Une Possibilité de définir la hiérarchie du réseau en utilisant des hôtes "parents", ce qui permet la détection et la distinction entre les hôtes qui sont à l’arrêt et ceux qui sont injoignables.
• Des Notifications quand un hôte ou un service a un problème et est résolu (par email, pager, ou par méthode définie par l’utilisateur)
• La Possibilité de définir des gestionnaires d’évènements qui s’exécutent pour des évènements sur des hôtes ou des services, pour une résolution proactive des problèmes.
• Une Rotation automatique des fichiers log.
• Un Support pour l’implémentation de la surveillance des hôtes de manière redondante et distribuée.

Les plus :

• Logiciel libre.
• Très complet.
• Possibilité de créer ses propres plugins.
• Communauté active.

Les moins :

• Interface pas très intuitive
• Configuration fastidieuse

Nagios est donc un logiciel très performant, mais difficile à prendre en main pour un utilisateur lambda.

Présentation d’Oreon

Oreon est un logiciel libre permettant d’ajouter une couche applicative au logiciel Nagios. Oreon lui offre une nouvelle interface et lui apporte de nouvelles fonctionnalités.

Il va permettre de rendre la configuration de Nagios plus facile et d’avoir une interface graphique améliorée. Les techniciens de leurs côtés auront toujours accès aux informations techniques de Nagios.

Fonctionnalités :

• Une interface multi-utilisateur intuitive et personnalisable.
• Une interface de configuration évoluée pour configurer le périmètre à superviser.
• Des aides à la configuration.
• Une gestion de tous les fichiers de configuration de Nagios (nagios.cfg...).
• Un module de chargement de configuration de Nagios.
• Une compatibilité Nagios 1.x, Nagios 2.x.
• Un test de validité des configurations avec le debugger de Nagios.
• Des fiches d’identités serveurs/équipements réseau regroupant les informations de base sur ces types de ressource.
• Des représentations graphiques élaborées et personnalisables.
• Une gestion des accès très fine, comprenant les ressources comme les pages de l’interface.

Les plus :

• Intégration complète des différents systèmes de Nagios
• Ajout d’une interface graphique améliorée et intuitive
• Configuration de Nagios facilitée
• Ajoute d’autres fonctionnalités à Nagios
• Communauté active

Les moins :

• Installation de plusieurs logiciels
• Bugs supplémentaires

Finalement, Oreon ne va pas juste améliorer l’interface graphique et faciliter la configuration de Nagios, mais il va aussi le compléter.

Choix d’Oreon / Nagios

Comme il a pu être vu, Nagios et Oreon sont tous deux des logiciels libres. L’un propose une gestion de la supervision réseau poussée avec une interface graphique et une configuration relativement difficiles à prendre en main.

L’autre propose une interface graphique et une configuration beaucoup plus intuitive. Il va en plus ajouter des fonctionnalités graphiques utiles pour pouvoir voir d’un simple coup d’œil l’historique de fonctionnement d’un hôte ou d’un service.

Voici les critères de sélection de ce choix Oreon/Nagios :

• L’installation d’Oreon supprime-t-elle des fonctionnalités à Nagios ?
• Y a-t-il un intérêt à intégrer Oreon dans la solution ?
• Peut-on accéder à Nagios après l’intégration d’Oreon ?

Après étude, il a été décidé d’intégrer Oreon, car tous les critères sont respectés avec une prise en main du logiciel relativement simple.

Grâce à cette solution, on combine le fait d’avoir un logiciel de supervision réseau complet avec une interface et une configuration intuitives.

Installation

Récapitulatifs des pré-requis

Pour une installation complète et stable de l’ensemble, les deux logiciels requièrent des logiciels, librairies et fonctionnalités, détaillés ci-dessous.

D’abord, il faut une plate-forme que l’on nomme LAMP (Linux, Apache, MySQL, PHP) avec les logiciels indispensables au lancement de l’application, soit du pré-requis standard, et des librairies.

Plate-forme LAMP :

Apache / Httpd 2.x	Apache est le serveur web qui va permettre d’accéder au site web d’Oreon
MySQL 4.1.x / 5.x	MySQL est un serveur de base de données permettant le stockage et l’accès aux données.
PHP 5.x	PHP va permettre l’affichage graphique des pages web.
GD GD-devel	GD est le nom d’une bibliothèque pour PHP servant à manipuler des images dynamiquement.
RRDTool 1.2.x	RRDTool va créer et stocker les données permettant l’affichage de graphe (création de graphe)
Net-SNMP	Net-SNMP quant à lui permet de faire des requêtes SNMP aux différents agents que l’on veut superviser.
Make Gcc sudo	Va permettre la compilation et l’installation des programmes.

---

Les librairies :

• php-mysql
• php-pear
• php-snmp
• php-ldap
• php-gd
• libgd2
• gd-devel
• libpng
• libpng-devel
• perl-config-IniFiles
• perl-Crypt-DES
• perl-Digest-HMAC
• perl-Digest-SHA1
• perl-GD
• perl-IO-Socket-INET6
• perl-Net-SNMP
• perl-rrdtool
• perl-Socket6

Les package Pear :

• Auth_SASL
• Date
• DB
• DB_DataObject
• DB_DataObject_FormBuilder
• HTML_Common
• HTML_QuickForm
• HTML_QuickForm_advmultiselect
• HTML_Table
• Image_Canvas
• Image_Color
• Image_Graph
• Image_GraphViz
• Mail_Mime
• MDB2
• Net_Ping
• Net_Traceroute
• Numbers_Roman
• Numbers_Words
• Validate
• XML_RPC

Installation des prés requis

Pour commencer, nous allons voir ce qu’est la commande « yum ».

La commande « yum » est un outil très puissant qui permet l’installation et la mise à jour des composants (packages) qui permettent l’ajout de nouvelles fonctionnalités à la plateforme.

Pour pouvoir utiliser la commande « yum » il faut lui indiquer si elle passe par un proxy<ref>Proxy : Un proxy a pour fonction de relayer des requêtes entre un poste client et un serveur. L'utilité du proxy est importante, notamment dans le cadre de la sécurisation des systèmes d'information.</ref>. Si oui :

> export http_proxy="http://@ip:n°port"

Il faut maintenant mettre à jour les composants déjà présents sur l’ordinateur :

> yum update

Passons à l’installation des prés requis. Une commande très utile existe pour rechercher uniquement les composants que vous souhaitez installer :

:> yum list | grep –i (le nom ou une partie du nom du composant souhaité)

La commande pour installer le package trouvé s’écrit comme ceci :

> yum install (le nom du package à installer)

Il est possible de ne pas trouver les packages souhaités. Dans ce cas, la solution est d’aller sur un site de recherche de package RPM et de télécharger le package qui correspond à votre version de plateforme Linux.

Pour installer un package RPM, il faut utiliser la commande suivante :

> rpm –ivh (package1) (package2) …

---

Passons à l’installation des packages pear.

Tout d’abord, il faut savoir que les packages pear ne peuvent être installés grâce à la commande yum. Ce sont des packages créés pour le pear et donc utilisables par pear seulement.

Premièrement, vérifier que la version utilisable de pear est une 1.5.2 minimum.

> pear help version

Si elle est inférieure à la version 1.3.6 alors, il faut faire comme suit :

> pear upgrade -a PEAR-1.3.6

> pear upgrade PEAR

Sinon il suffit juste de faire ceci :

> pear upgrade PEAR

Attention toutefois, il risque d’y avoir des problèmes de dépendances. Pour résoudre ces problèmes, il suffit juste d’installer les dépendances requises comme suit :

> pear install -o -f --alldeps (nom du package)

Une fois le problème de version résolu, il suffit d’appliquer cette commande pour installer tous les packages pear :

> pear install -o -f --alldeps Mail Mail_Mime Net_SMTP Net_Socket Net_Traceroute Net_Ping Validate Image_Graph Image_GraphViz HTML_Table HTML_QuickForm_advmultiselect Auth_SASL HTTP Numbers_Roman Numbers_Words MDB2 DB_DataObject_FormBuilder DB_DataObject DB Date

Normalement à cette étape toutes les dépendances ont été installées correctement. Le chapitre suivant concerne l’installation de Nagios.

Installation sur un seul serveur

Installation de Nagios

Pour installer Nagios, vous devez d’abord le télécharger sur le site officiel (www.nagios.org). Il est fortement conseillé d’utiliser des versions stables. Pour cette documentation, les versions sélectionnées sont Nagios-2.9 et Nagios-plugins-1.4.8. Tout ce qui suit implique d’avoir les droits root<ref>Root : l’utilisateur root est considéré comme l’administrateur de l’ordinateur. Il détient ainsi tous les droits. Pour devenir un utilisateur root il suffit d’utiliser la commande « su ».</ref> sur votre compte.

Pour commencer, il faut extraire l’archive (distribution) téléchargée :

> tar xvzf nagios-2.9.tar.gz

Une fois la commande exécutée, un répertoire du même nom a dû être créé. Pour vérifier sa présence, tapez la commande suivante dans le répertoire courant :

> ls -l

Image:DOC OREON 02.gif

Figure 1 : Vérification de la présence du répertoire "nagios-2.9"

Pour entrer dans ce répertoire, tapez la commande suivante :

> cd nagios-2.9

Avant d’aller plus loin, il faut créer un répertoire qui sera accessible par un utilisateur et un groupe standard :

> adduser nagios > mkdir /usr/local/nagios > chown nagios.nagios /usr/local/nagios

En faisant un ls -l de /usr/local on obtient ceci :

Figure 2 : Résultat de ls -l /usr/local

On remarque bien que l’utilisateur et le groupe propriétaire sont « nagios ».

Pour utiliser des commandes externes via l’interface web, il faut créer un groupe ou les utilisateurs « web » et les utilisateurs « nagios » auront le droit d’envoyer des requêtes au serveur Nagios (c’est-à-dire écrire dans un fichier que nagios ira lire) :

> /usr/sbin/groupadd nagcmd > /usr/sbin/usermod -G nagcmd apache > /usr/sbin/usermod -G nagcmd nagios

Passons à la configuration de l’installation de Nagios. Pour cette étape, il faut être dans le répertoire de « nagios-2.9 » :

>./configure --prefix=prefix --with-cgiurl=cgiurl --with-htmurl=htmurl --with-nagios-user=someuser --with-nagios-group=somegroup --with-command-group=cmdgroup

• Remplacer prefix, par le répertoire d’installation qui a été créé plus haut (par défaut /usr/local/nagios).

• Remplacer cgiurl, par l’URL qui va être utilisée pour accéder aux scripts CGIs (par défaut /nagios/cgi-bin). Ne pas ajouter de slash (/) à la fin de l’URL.

• Remplacer htmurl, par l’URL qui va être utilisée pour accéder à l’interface principale de Nagios et la documentation (par défaut /nagios).

• Remplacer someuser, par le nom de l’utilisateur qui va posséder les fichiers installés (par défaut nagios).

• Remplacer somegroup, par le nom du groupe qui va posséder les fichiers installés (par défaut nagios).

• Remplacer cmdgroup, par le nom du groupe qui fait tourner le serveur Web (par défaut nagios).

Exemple de commande pour la compilation et l’installation :

> make all > make install > make install-init > make install-config

La commande « make install-init » va permettre d’ajouter un fichier « init » dans le répertoire /etc/rc.d/init.d/ nommé « nagios ».

Il va ainsi être possible de lancer Nagios grâce à la commande :

> service nagios start

La commande « make install-config » quant à elle ne fait qu’installer des fichiers d’exemple de configuration dans le répertoire « path/nagios/libexec ».

L’installation des plugins de Nagios se fait comme suit :

> tar xvzf nagios-plugins-1.4.8.tar.gz > cd nagios-plugins-1.4.8 > ./configure --prefix=/usr/local/nagios --with-cgiurl=/nagios/cgi-bin > make > make install

Enfin, pour finir l’installation de Nagios, il faut éditer le fichier de configuration web pour pouvoir utiliser le web comme interface Nagios.

Pour ce faire, il faut aller dans le fichier de configuration apache :

> cd /etc/httpd/conf/

Ensuite, il suffit d’ajouter les lignes suivantes dans le fichier httpd.conf :

ScriptAlias /nagios/cgi-bin /usr/local/nagios/sbin <Directory "/usr/local/nagios/sbin"> Options ExecCGI AllowOverride None Order allow,deny Allow from all AuthName "Nagios Access" AuthType Basic AuthUserFile /usr/local/nagios/etc/htpasswd.users Require valid-user </Directory> Alias /nagios /usr/local/nagios/share <Directory "/usr/local/nagios/share"> Options None AllowOverride None Order allow,deny Allow from all AuthName "Nagios Access" AuthType Basic AuthUserFile /usr/local/nagios/etc/htpasswd.users Require valid-user </Directory>

Il faut autoriser un utilisateur à accéder à l’interface web, ici c’est l’utilisateur « admin » :

> htpasswd -c /usr/local/nagios/etc/htpasswd.users admin

Enfin, il faut redémarrer le serveur web.

> service httpd restart

Maintenant que l’installation de Nagios est terminée, configurons-le très rapidement pour voir s’il fonctionne correctement et ainsi pouvoir commencer l’installation d’Oreon.

Configuration rapide de Nagios

Pour pouvoir lancer Nagios rapidement il faut juste enlever le «-sample » des fichiers d’exemple de configuration créés dans le répertoire « path/nagios/etc/ ».

Pour cela, il suffit de faire :

> mv cgi.cfg-sample cgi.cfg

Il renomerra le fichier « cgi.cfg-sample » en « cgi.cfg ».

Ensuite dans le fichier « cgi.cfg ». Il faut le modifier de façon à ce que l’utilisateur « admin » puisse accéder aux différentes sections du site web. Il faut ajouter l’utilisateur « admin » à toute les lignes comportant « authorized ».

Il faut vérifier que dans le fichier « nagios.cfg », « check_external_command » soit à 0 sinon il y aura des problèmes pour lancer le service « nagios ».

Pour vérifier le bon fonctionnement de l’ensemble des fichiers de configuration, il faut taper la commande suivante :

> /usr/local/nagios/bin/nagios –v /usr/local/nagios/etc/nagios.cfg

Quand tout fonctionne correctement, il n’y a plus qu’à relancer Nagios.

> /etc/init.d/nagios start

Maintenant, l’accès à l’interface Nagios est disponible sur le site web du serveur, avec toutes ses pages web, via l’adresse " http://@ipserveur/nagios/".

Pour avoir un accès plus aisé aux informations ainsi qu’une configuration simplifiée, installons Oreon.

Installation d’Oreon

L’installation d’Oreon est très simple à effectuer. En effet, les développeurs du projet ont intégré un système d’installation semi-automatique qui facilite énormément les choses.

Tout d’abord comme pour Nagios, il faut décompresser le fichier téléchargé sur le site officiel (http://www.oreon-project.org/download.html).

Décompresser l’archive récupérée par la commande suivante :

> tar xvzf oreon-1.X.tar.gz

Ensuite, il suffit d’aller dans le répertoire créé et de lancer la commande suivante :

> ./install.sh

Il faut suivre ce qui est demandé et lui donner les bons chemins pour avoir une installation correcte.

Pour finir l’installation d’Oreon, il va falloir aller sur l’interface web http://@ipserveur/oreon/ (ne pas oublier le / après oreon)

Figure 3 : Finition de l’installation d’Oreon étape trois

Normalement dans la Figure 3 tout doit être rempli selon les chemins qui ont été spécifiés lors de l’installation. Attention toutefois à l’option « Nagios Version » qui est à la valeur « 1.x » par défaut. Il faut lui indiquer la bonne version de Nagios.

---

Figure 4 : Finition de l’installation d’Oreon étape quatre

Figure 5 : Finition de l’installation 'd’Oreon 'étape cinq

Pour les étapes quatre et cinq de la finition de l’installation (Figure 7 & Figure 8) tout doit être à la valeur « OK », si ce n’est pas le cas alors il faut revoir le chapitre « Installations des prés requis »

---

Figure 6 : Finition de l’installation d’Oreon étape six

Pour l’étape 6 (Figure 6), il faut préciser le nom de la base de données Oreon et le nom de la base de données de stockage Oreon. Enfin le mot de passe et le type de version MySQL utilisé. À noter : par défaut, le compte root n’est pas protégé par un mot de passe. Laissez la case « Root password for MySQL » vide, sauf si vous avez spécifié un mot de passe root MySQL.

Pour l’étape qui suit, il ne faut pas oublier de lancer le service MySQL sous votre serveur pour qu’Oreon puisse par la suite créer les bases de données nécessaires au fonctionnement de l’ensemble du serveur d’analyse du réseau.

> service mysqld start

Figure 7 : Finition de l’installation d’Oreon étape huit

Ici, il faut juste indiquer quel utilisateur aura accès à l’interface Oreon au premier lancement du serveur. En indiquant l’adresse mail de l’administrateur, Oreon saura où envoyer les notifications en cas de problème.

Une fois toutes les étapes passées, on peut aller à la page d’accueil d’Oreon (Figure 8). On remarque que les hosts et les services sont vides, c’est tout à fait normal, car le serveur n’a pas été configuré.

Figure 8 : Page d’accueil d’Oreon

Une fois l’installation d’un serveur « central » terminé, il est possible d’opter pour l’installation de serveurs repartis utilisés pour les sites distants ou décharger le CPU du serveur « central ».

Installation sur plusieurs serveurs

L’installation de plusieurs serveurs de supervision réseau va permettre au serveur central une répartition de la tâche de travail conséquente. Cette solution est surtout utilisée pour les réseaux qui comprennent plusieurs centaines d’hosts et donc plusieurs fois cette valeur en termes de services. Elle est aussi utilisée pour les réseaux qui comprennent des sites distants et réduire la charge CPU du serveur central.

Rôle d’un serveur réparti

Un serveur réparti va permettre de contrôler tous les services définis pour un groupe d’hôtes. Il ne va pas faire de contrôle de notification et il ne gérera pas les événements, sauf, bien sûr, si vous le désirez.

Il ne fera qu’envoyer au serveur central les données qu’il récupère grâce à un client NSCA<ref>NSCA : pour plus d’information, voir le chapitre 5.2 Le NSCA</ref>. Par conséquent, les différences par rapport à un serveur central se trouveront principalement dans la partie configuration.

Installation des prés requis

Les prés requis utilisés par le serveur réparti sont différents selon le type de serveur désiré. En effet, pour un serveur complet il est préférable d’utiliser l’interface d’Oreon, alors il faut suivre le chapitre « Installation des prés requis » avec tous les prés requis. Pour un serveur qui ne fait qu’envoyer des données, alors il faut suivre le chapitre « Installation des prés requis » avec les prés requis standards sans RRDTool.

Installation d’un serveur réparti

Pour tout ce qui concerne l’installation, reportez-vous au chapitre Installation de Nagios.

Il ne faut pas oublier que les serveurs répartis vont devoirs communiquer avec le serveur central. Pour cela, le module complémentaire NSCA doit être installé. Il va permettre la communication en mode passif vers le serveur central (pour plus de détails, voir le chapitre « Le NSCA »).

D’abord, télécharger le module sur le site officiel de Nagios. Puis, extraire l’archive :

> tar xvzf nsca-2.7.1.tar.gz

Ensuite, configurer le module et le compiler.

> ./configure > make all

Une fois compilé le démon doit se trouver dans le répertoire /src/ du dossier décompressé. Le fichier de configuration quant a lui doit être dans le répertoire /sample-config/.

Ces deux fichiers peuvent être placés n’importe où dans votre serveur central, toutefois, pour cet exemple le fichier binaire « nsca » est placé dans le répertoire /usr/local/nagios/bin/ et le fichier de configuration « nsca.cfg » dans le répertoire /usr/local/nagios/etc/.

Pour les serveurs répartis, il faut procéder de la même façon et il est préférable de placer les fichiers binaires et de configuration aux mêmes endroits. Le fichier binaire se nomme « send_nsca » et le fichier de configuration « send_nsca.cfg ».

La configuration est un point très important pour que Nagios et Oreon puissent fonctionner. La description des différents fichiers est exposée ci-dessous.

Configuration et paramétrage

Après avoir installé tous les composants et vérifié qu’ils fonctionnent correctement, il faut passer au point le plus délicat, la configuration du serveur. Premièrement, la configuration d’un seul serveur, enfin la configuration des serveurs répartis.

Configuration sur un serveur

Toute la configuration se fait à travers l’interface d’Oreon. Normalement, il n’y a pas besoin de passer par les fichiers de configurations avec un éditeur de texte. Néanmoins, les emplacements de tous les fichiers de configuration de Nagios et d’Oreon sont indiqués ci-dessous.

Emplacement des fichiers de configuration Nagios :

/YourPath/nagios/etc/

Emplacement des fichiers de configuration Nagios générés par Oreon :

/YourPath/oreon/filesGeneration/nagiosCFG/

Emplacement des fichiers de configuration Nagios importé par Oreon :

/YourPath/oreon/filesUpload/nagiosCFG/

Emplacement des fichiers de configuration Oreon :

/YourPath/oreon/www/include

Configuration d’Oreon

Cette partie a pour but d’expliquer toutes les différentes options de configuration d’Oreon de manière simple et compréhensible pour tous, pour obtenir au final une configuration adaptée aux besoins de chacun.

Comment aller dans le menu des options générales.

Figure 9 : Accès aux options générales

Ici (Figure 9) on peut voir un menu grâce auquel on peut accéder aux différentes pages du site web d’Oreon. Pour accéder aux options générales, il faut aller sur l’onglet Options ici représenté en bleu.

Les options générales d’Oreon se décomposent en neuf parties.

Figure 10 : Menu des options générales

Dans ce menu (Figure 10) se trouvent les liens vers toutes les configurations qui concernent Oreon. Chaque point va être étudié l’un après l’autre dans l’ordre affiché dans la Figure 10.

Option d’Oreon

Figure 11 : Options d’Oreon

Cette page (Figure 11) va permettre en grande partie de modifier l’affichage de l’interface graphique.

1. Le « Répertoire » est l’emplacement où se trouve le dossier d’installation d’Oreon

2. Le « Répertoire Web » indique l’emplacement du répertoire web.

3. Le « Répertoire des bases rrd » va permettre à rrdtool de stocker ses données graphiques dans le répertoire spécifié.

4. Cette option permet de sélectionner à quelle fréquence la page va se rafraichir.

5. Le champ « Expiration des Sessions » indique à partir de combien de temps l’utilisateur inactif est déconnecté du site.

6. Via cette option, il est possible d’indiquer combien d’hôtes maximums à afficher par pages.

7. Cette option est identique à la précédente, mais est valable pour toutes les autres pages du site web. C’est une valeur par défaut.

8. & 9. Ces deux options vont permettre d’obtenir un rafraichissement spécifique pour les pages citées (statistique, monitoring).

10. & 11. Va définir au bout de combien de temps le premier rafraichissement se fera lors de l’accès à la page citée (statistique, monitoring).

12. Indique le type de Template<ref>Template : Cette Template définit le thème graphique d'Oreon. Une Template est en général un exemple de fichier pour aider à la configuration ou à l’édition.</ref>. (Pour le moment, cette option n’est pas modifiable).

13. Cette option permet de trier les problèmes par critères lors de l’accès à la page « monitoring ». En tout, six critères sont proposés. (Durée, Hosts, Services, Status, Last check, Output).

14. Ici il faut indiquer dans quel ordre afficher les problèmes dans la page « monitoring ». Deux choix vous sont possibles. (Ascendant, Descendant).

15. Ce champ est présent pour modifier l’heure d’Oreon.

Option de Nagios

Figure 12 : Informations relatives à Nagios

Cette page indique tous les emplacements des répertoires de Nagios pour qu’Oreon puisse utiliser ce qui est nécessaire à l’affichage des données, au lancement de Nagios et aux plugins présents dans le répertoire spécifié.

Pour cette page on ne va pas détailler toutes les parties, il suffit juste de donner les bons emplacements des répertoires. Il ne faut tout de même pas oublier de vérifier que la version de Nagios est correcte.

Pour l’option « Utilisation de Perfparse<ref>Perparse : Perfparse est un logiciel créé spécifiquement pour Nagios pour pouvoir afficher des graphiques via les plugins de Nagios.</ref> » si Perfparse est utilisé alors cochez oui, sinon il est important, pour ceux qui ne l’utilisent pas, de mettre cette option à non.

Alors à quoi sert-elle?

Cette option va permettre à Oreon de savoir quel logiciel utiliser pour obtenir vos graphiques. En mettant cette option à « oui » alors que Perfparse n’est pas utilisé, Oreon ne va afficher aucun graphique.

Option des couleurs

Figure 13 : Option des couleurs

Tout ce qui concerne la modification des couleurs des Hosts et des services se trouve dans l’option des couleurs (Figure 13). En cliquant sur le bouton « Modifier » une autre page s’affiche (Figure 14) ou il est possible de sélectionner exactement la couleur souhaitée.

Figure 14 : Sélection d’une couleur pour un host ou un service

Option SNMP<ref>SNMP : voir le chapitre qu'est-ce que le SNMP.</ref>.

Figure 15 : Option SNMP

1. La « Communauté Globale » est le nom de la communauté qui est utilisée en général dans le réseau par le protocole SNMP.

2. La « Version » est celle utilisée par le protocole SNMP pour faire ses requêtes aux agents. Trois choix sont disponibles (1, 2, 2c).

3. Cette option détermine si oui ou non le contrôle passif des traps SNMP<ref>Trap SNMP : Les traps SNMP n’envoient aucune requête. Cela permet d’écouter sur le port 162 si un agent envoie une donnée d’alerte ou pas. C’est une sorte de SNMP passif du contrôle d’alerte.</ref> est activé.

4. Cette partie indique dans quel répertoire se trouve le fichier SNMPtrapd.conf.

5. Indique à Oreon où se trouve le fichier SNMPtrapd soit le démon<ref>Démon : Processus qui se lance en arrière-plan, permet de ne pas bloquer la station de travail.</ref> du service SNMPtrapd.

Option LDAP

L’option LDAP va permettre à l’utilisateur de préciser si oui ou non le service est actif sur le réseau.

D’abord qu’est-ce que le LDAP ?

LDAP est un protocole permettant l’interrogation et la modification des services d’annuaire.

Dans la Figure 16, on peut voir un annuaire qui peut être interrogé ou modifié par le protocole LDAP. L’utilisateur toto peut détenir des informations relatives à son numéro de téléphone ou son adresse mail.

Figure 16 : Annuaire LDAP

Pour l’explication de la Figure 27 (ci-dessous) on ne va pas tout détailler, juste les points importants pour le bon fonctionnement du LDAP et qui ne paraissent pas évidents.

1. Pour ce champ il faut mettre l’adresse IP du serveur LDAP.

2. Normalement le port utilisé par le protocole LDAP est le 389.

3. La base DN LDAP est la base de l’annuaire (arbre) du réseau.

4. Le login attribut est le nom de l’utilisateur ayant le droit de parcourir l’arbre.

5. Le fait d’activer l’option SSL implique que le transfert de donnée va se faire de façon plus sécurisée. SSL est un protocole d’authentification et de chiffrement des données.

Figure 17 : Option LDAP

Pour plus de renseignements sur la configuration LDAP, voir :

http://wiki.oreon-project.org/index.php/Use_LDAP/Active_Directory_for_import_users

Option de RRDTool

Figure 18 : Option RRDTool

Le premier champ indique où se trouve le binaire de rrdtool. Il faut donc indiquer à Oreon où se trouve l’exécutable de rrdtool.

Dans le deuxième champ doit figurer la version installée actuellement sur l’ordinateur.

Le troisième champ permet de sélectionner soit « Sondes Graphiques », qui vont créer le graphe directement grâce aux plugins, et « Graphs Simples » qui vont créer le graphe en utilisant ODS ou Perfparse.

Option des fichiers de log et de débogage

Figure 19 : Option de fichier de débogage

Pour le moment, les logs peuvent être activés pour corriger des problèmes particuliers. La rotation des logs n’étant pas pris en compte il risque de devenir volumineux avec le temps.

Option de personnalisation de l’interface graphique d’Oreon

Elle va permettre de modifier les couleurs de l’interface. (Voir Figure 20)

Figure 20 : Option de personnalisation de l’interface

Option d’OreonDataStorage

Figure 21 : Option d’OreonDataStorage

1. Indique s’il faut supprimer les bases RRDTool créées dans le répertoire « /oreon/rrd/ » une fois utilisées.

2. Le Sleep Time est le temps entre deux vérifications du fichier service-perfdata par ODS. En gros ODS va déterminer si le fichier existe et si oui il va remonter les données en base pour pouvoir les utiliser.

3. pas encore déterminer

4. Pour ce champ, deux possibilités. Soit RRDTool ou RRDTool & MySQL. Il est plutôt conseillé d’utiliser la deuxième option.

5. Ici se trouve le chemin pour accéder au fichier de performance de Nagios. Pour savoir comment l’installer, voir le chapitre « Configuration de Nagios et d’Oreon pour l’obtention de graphique ».

6. Le fait de déplacer les données de performance après lecture va permettre à une autre application d’utiliser ces données.

7. C’est l’emplacement et le nom du fichier qui va être utilisé pour stocker les données de performance.

8. La lecture rapide des statuts a été créée spécifiquement pour les cas où il y a plusieurs centaines d’hosts et de services pour rendre plus rapide l’affichage des données sur Oreon. Le problème majeur de cette solution est que le monitoring ne se met à jour que toutes les minutes. Des problèmes avec les graphiques ont aussi été détectés.

La configuration d’Oreon étant vue, on peut passer à la configuration de Nagios.

Configuration de Nagios

Toute la configuration de Nagios se fait via l’interface d’Oreon. Le principe est le suivant. D’abord, créer une configuration propre au réseau. Ensuite, générer les fichiers de configuration. En générant ces fichiers, un système de débogage indique si la configuration est bonne ou pas. Une fois la vérification effectuée il est possible d’exporter les fichiers vers l’emplacement prévu dans le répertoire de Nagios.

Accès aux différents fichiers de configuration de Nagios.

Figure 22 : Accès aux fichiers de configuration de Nagios

Dans la Figure 22, on remarque qu’il y a sept sous-parties en dessous de l’onglet configuration en bleu. On va d’abord commencer par étudier l’onglet Utilisateurs.

Les Utilisateurs

Figure 23 : Sous-menu de l’Utilisateur

Dans la Figure 23, on peut voir quatre sections. On va commencer par voir la section « utilisateurs » ensuite les « groupes utilisateurs » après les « plages horaires » enfin les « commandes de notifications ».

L’utilisateur est la personne qui doit être contactée en cas de problème sur le réseau. Les différentes options concernant la création et le type de notification sont détaillées ci-dessous.

---

Figure 24 : Configuration de l’utilisateur

---

Information générale :

1. Le nom complet désigne le nom court de l’utilisateur. Ce nom sera utilisé par les groupes d’utilisateurs.

2. L’alias définit un nom long ou une description de l’utilisateur.

3. L’email indique à Oreon l’adresse mail de l’utilisateur pour lui envoyer les notifications.

4. Le pager indique à Oreon le numéro qui va pouvoir joindre le pager<ref>Pager : Le pager est un appareil qui reçoit un bip et un court message par ondes radio. Le numéro de l’appelant est aussi affiché.</ref> de l’utilisateur.

5. Le contact groups parent(s) permet d’identifier le groupe auquel est rattaché l’utilisateur. Il peut être attaché à plusieurs groupes différents.

Oreon :

6. Cette option indique si l’utilisateur peut avoir accès à l’interface d’Oreon. Un utilisateur peut ainsi être inscrit uniquement pour être notifié d’un problème.

7. & 8. Champs indiquant le mot de passe de l’utilisateur, s’il a accès à l’interface d’Oreon.

9. grâce à cette option il est possible d’indiquer dans quelle langue l’utilisateur va voir l’interface d’Oreon.

10. Le format du mail propose trois choix différents. Envoyer le mail en TXT, HTML ou PDF.

11. Le champ Administrateur permet de sélectionner ceux qui auront les droits d’administrateur.

12. Cette option définit le type d’authentification de l’utilisateur (Local, LDAP). Le choix LDAP n’est disponible que si l’authentification LDAP est activée (options générales >> LDAP).

Host :

13. Le choix de notification pour les hosts désigne pour quel état de l’host Oreon va envoyer une notification.

14. La période de notification est utile pour prévenir Oreon quand il peut envoyer des notifications suivant le jour ou l’heure de la journée. (Voir le service plage horaire dans ce chapitre)

15. La commande de notification indique le type de notification par lequel l’utilisateur va être averti. Avec email-ng1, Oreon va envoyer un mail qui va avertir l’utilisateur d’un état d’alerte (supporté par Nagios v1 & v2). Avec email-ng2 Oreon va envoyer le même mail, mais avec des détails sur le problème en plus (supporté uniquement par Nagios v2 mais pas Nagios v1).

Service :

Cette section indique quel type de notification l’utilisateur peut recevoir et quand il peut les recevoir.

Informations complémentaires :

Le premier champ indique si les commentaires sont actifs.

Le deuxième champ permet d’insérer un commentaire lié à l’utilisateur.

---

Passons maintenant au groupe d’utilisateurs.

Le groupe d’utilisateurs regroupe un ou plusieurs utilisateurs pour leur envoyer des notifications.

Figure 25 : Groupe d’utilisateurs

Informations générales :

1. Le nom du contact group désigne le nom court du groupe.

2. L’alias indique la description du groupe.

Notifications :

3. Le Contacts rattachés ajoute les utilisateurs qui seront notifiés par Oreon lors d’une alerte.

Informations complémentaires :

4. Le premier champ indique si les commentaires sont actifs.

5. Le deuxième champ insère un commentaire lié au groupe d’utilisateurs.

---

La création de plage horaire est importante pour Nagios pour savoir quand il peut envoyer une notification à l’utilisateur ou au groupe d’utilisateurs.

Figure 26 : Plage horaire

Informations générales :

1. Le nom de la plage horaire est celui qui figure lors de la sélection de la plage horaire des utilisateurs ou des groupes d’utilisateurs.

2. L’alias contient en général des précisions sur ce service.

Tranche horaire de notification :

3. Indique dans quelle plage horaire Nagios peut envoyer les notifications.

Les commandes de notification ont été créées pour indiquer à Nagios de quelle façon il doit joindre l’utilisateur. Dans cette partie, il est possible de créer ses propres commandes de notification. Pour plus de détails, voir la section commande dans ce chapitre.

Les Hosts

Dans cette section va se trouver tout ce qui permet de créer et d’éditer les hôtes et les groupes d’utilisateurs. Comme on peut le remarquer sur la Figure 27 il y a trois parties différentes, étudions d’abord les Hôtes.

Figure 27 : Menu du service d’hôte

Figure 28 : Configuration d’un hôte

Informations générales :

1. Le nom d’hôte est le terme utilisé par le groupe d’utilisateurs pour désigner l’hôte.

2. L’alias détermine un nom long ou une définition de l’hôte.

3. L’adresse pointe sur l’adresse IP de l’hôte à surveiller.

4. Le champ SNMP indique le domaine utilisé en général dans le réseau ainsi que la version utilisée.

5. L’utilisation de « Template » accélère la configuration d’un hôte en insérant des valeurs prédéfinies dans les champs désirés grâce au « modèle d’host ».

6. Cocher « oui » la case crée les services liés au Template, indique que les services prédéfinis vont être créés pour cet hôte.

Statuts de l’host :

7. La période de contrôle indique à Nagios quand celui-ci va pouvoir contrôler l’hôte.

8. La commande de check permet de vérifier l’état de l’hôte (OK ou DOWN). En général, c’est une simple requête ping qui est envoyée pour ce contrôle, toutefois, il est possible de lui demander de vérifier ce que vous désirez. Si ce champ est vide alors Nagios considérera que l’hôte est en état OK.

9. Le champ Argument contient des informations précises pour que le plugin puisse envoyer une requête adaptée à l’hôte. Il n’est utilisé en général que pour les services.

10. Le nombre maximum d’essais définit le nombre de fois que Nagios va tester l’hôte avant d’envoyer une notification.

11. L’ordonnancement régulier a été créé pour lancer les vérifications de façon échelonnée de manière à ne pas surcharger le serveur. Il est exprimé en minutes.

12. Si le gestionnaire d’évènement est activé alors Nagios va pouvoir gérer les évènements tels que redémarrer un service.

13. Le champ « commande associée » indique à Nagios quel évènement il va effectuer grâce à des plugins.

14. Ce champ peut contenir des informations précises pour que le plugin puisse envoyer une requête adaptée à l’hôte

15. Cette directive définit si les contrôles actifs (les contrôles planifiés ou ceux à la demande) sont activés pour cet hôte.

16. Cette directive définit si les contrôles passifs (ceux qui sont envoyés par un agent) sont activés pour cet hôte.

Notification :

17. Cette option active ou désactive la notification de l’hôte.

18. Le contact groupe rattaché désigne le groupe qui sera notifié en cas de problème sur cet hôte.

19. L’intervalle de notification indique à quelle fréquence Nagios va envoyer une notification au groupe d’utilisateurs. Il est exprimé en minutes.

20. La période de notification définit une période durant laquelle Nagios va pouvoir envoyer des notifications aux groupes désignés.

21. Le type de notification est très important, car il indique à Nagios pour quel évènement il doit envoyer une notification. Le Flapping désigne un hôte qui oscille.

22. L’état de suivi précis est là pour avoir un historique de fonctionnement de l’hôte pour les options qui seront cochées.

---

Passons à l’onglet relation. Voir Figure 29 ci-dessous.

Relations :

1. L’host group parent désigne le groupe d’hôtes auquel il est attaché.

2. L’host parent indique l’hôte qui se trouve au-dessus de l’hôte configuré. Permet à Nagios de ne pas notifier un évènement « DOWN » si son parent est aussi « DOWN ».

3. L’Host enfant indique quel hôte est l’enfant de l’hôte configuré.

Figure 29 : Relations de l’host

Le troisième onglet concerne le traitement des données. Voir Figure 30.

Figure 30 : Traitement des données de l’host

4. La détection des oscillations permet à Nagios de ne pas envoyer de notification si l’hôte est oscillant. Il ne va pas y avoir de notification tant que l’oscillation ne va pas dépasser les seuils haut et bas.

5. Cette option permet de donner le seuil bas de détections de l’oscillation.

6. Cette option permet de donner le seuil haut de détection de l’oscillation.

7. Le traitement des données de performance va renvoyer des données, dans le fichier perfdata, qui vont être représentées graphiquement par Oreon.

8. & 9. La mémorisation des informations permet d’avoir un suivi de l’état de fonctionnement d’un hôte dans le temps.

La partie suivante concerne l’onglet des informations complémentaire.

Cette partie de la configuration d’un hôte n’a aucun effet sur la surveillance réseau. Elle ne sert qu’à avoir des rendus graphiques améliorés sur l’interface pour les cartographies d’états.

Figure 31 : Information optionnelle d’un hôte

Oreon :

1. Précise le pays dans lequel se trouve l’équipement. Pour la cartographie du monde (cette option est désactivée dans la version non commerciale).

2. Précise le nom de la ville où se trouve l’équipement (cette option est désactivée dans la version non commerciale).

Nagios :

3. Cette variable définit une URL optionnelle qui peut être utilisée pour fournir plus d’informations sur l’hôte.

4. Cette directive est utilisée pour définir une note appartenant à l’hôte.

5. Cette directive est utilisée pour définir une URL optionnelle qui peut être utilisée pour fournir plus d’actions à exécuter sur l’hôte.

6. Cette variable définit le nom d’une image GIF qui va être associée avec cet hôte.

7. Affiche le texte indiqué au cas où l’image ne s’afficherait pas.

8. Cette variable définit le nom d’une image GIF qui va être associée à cet hôte. Elle est utilisée par la page « status world » dans l’interface de Nagios.

9. Cette variable définit le nom d’une image au format GD2 qui sera associée à cet hôte. Elle est utilisée par la page « status map » dans l’interface de Nagios.

10. Cette variable définit les coordonnées de l’hôte dans l’affichage de la status map

11. Cette variable définit les coordonnées de l’hôte dans l’affichage de la status world

Maintenant que la configuration de l’hôte est terminée, il est nécessaire de créer un groupe d’hôtes.

---

Figure 32 : Configuration d’un groupe d’hôtes

Les groupes d’hôtes classifient les hôtes pour mieux appréhender les problèmes qui peuvent survenir.

Pour cette partie, il est nécessaire d’entrer les hôtes qui vont être attachés à ce groupe dans le champ « Hosts rattachés ».

La troisième partie concerne le modèle d’host Figure 27. Le modèle d’host a été créé pour faciliter l’intégration d’hôte dans votre service. Dans cette configuration il n’y a pas de contrainte il faut indiquer obligatoirement un nom d’hôte et un alias.

Les services

Un service peut s’appliquer à plusieurs types de service (POP, SMTP, HTTP, etc.) ou bien tout autre type de mesure associé à l’hôte (mesure CPU, usage des disques, etc.).

Les services fonctionnent avec les plugins. Le plugin est le service qui va être lancé pour recevoir les états et les mesures des hôtes contrôlés.

Figure 33 : Menu de l’onglet services

Dans l’onglet services, il y aussi quatre sous-parties qui intègrent les services par hôte, par groupe d’hôtes et par des groupes de service.

Figure 34 : Création d’un service

---

Informations générales :

1. La description du service se fait dans le premier champ.

2. Dans le champ Template de service, il est possible d’ajouter un modèle qui insère automatiquement les valeurs créées dans le modèle de service.

Statuts de service :

3. Cette directive définit si le service est volatil<ref>Service volatile : Un état d’alerte provoqué par un logiciel tiers est considéré comme un service volatil.</ref>.

4. La période de contrôle indique à Nagios quand celui-ci pourra contrôler le service.

5. La commande de check d’un service indique à Nagios avec quel plugin il va contrôler le service ou mesurer une partie précise d’un hôte.

6. Le champ Argument contient des informations précises pour que le plugin puisse envoyer une requête adaptée à l’hôte.

7. Le nombre maximum d’essais définit le nombre de fois que Nagios va tester le service de l’hôte avant d’envoyer une notification.

8. L’ordonnancement régulier définit une période de temps avant d’ordonnancer le prochain contrôle régulier du service. Les contrôles réguliers sont ceux qui se font lorsque le service est en état « OK » ou lorsque le service n’est pas en état OK, mais que le nombre d’essais défini par la variable nombre maximum d’essais est atteint.

9. L’ordonnancement non-régulier définit une période de temps avant d’ordonnancer le prochain contrôle du service. Les services sont réordonnancés à cet intervalle quand ils sont passés dans un état différent de « OK ». On revient en ordonnancement régulier lorsque le nombre maximum d’essais est atteint.

10. Si le gestionnaire d’évènement est activé alors Nagios va pouvoir gérer les évènements tels que redémarrer un service.

11. C’est dans le champ « commande associée » qu’il faut indiquer à Nagios quel évènement il va effectuer grâce à des plugins.

12. Le champ Argument contient des informations précises pour que le plugin puisse envoyer une requête adaptée à l’hôte.

13. Cette directive définit si les contrôles actifs (les contrôles planifiés ou ceux à la demande) sont activés pour cet hôte.

14. Cette directive définit si les contrôles passifs sont appliqués pour cet hôte.

Notification :

15. Cette option détermine si la notification est activée pour ce service.

16. Le contact groupe rattaché désigne le groupe qui va être notifié en cas de problème sur ce service.

17. L’intervalle de notification indique à quelle fréquence Nagios va envoyer une notification au groupe d’utilisateurs.

18. La période de notification définit une période durant laquelle Nagios va pouvoir envoyer des notifications aux groupes désignés.

19. Le type de notification est très important, car il indique à Nagios pour quel évènement il doit envoyer une notification. Le Flapping désigne un service qui oscille.

20. L’état de suivi précis est là pour avoir un historique de fonctionnement du service pour les options cochées.

Le second point dans la configuration d’un service concerne les relations qu’il a avec les hôtes et les services.

---

Figure 35 : Création d’un service, onglet relation

Les relations pour le service sont très importantes, car elles définissent à quels hôtes les contrôles vont s’appliquer.

Ainsi, un service peut être lié à un ou plusieurs hôtes (1.). De même pour les groupes d’hôtes (2.). Il peut être aussi défini un groupe de service (3.) qui sera parents au service de configuration.

Service Trap relation à définir

---

La troisième partie dans la configuration d’un service est le traitement des données.

Figure 36 : Création d’un service, onglet traitement des données

Traitement des données :

1. Le contrôle parallèle définit si le contrôle de service peut être effectué en parallèle. Par défaut, tous les contrôles de service sont parallélisés. Le désactiver peut causer de graves problèmes de performance.

2. À définir

3. À définir

4. À définir

5. La détection des oscillations permet à Nagios de ne pas envoyer de notification si le service est oscillant. Il ne va pas y avoir de notification tant que l’oscillation ne va pas dépasser les seuils haut et bas.

6. Indique le seuil d’oscillation bas si la détection des oscillations est activée.

7. Indique le seuil d’oscillation haut si la détection des oscillations est activée.

8. Le traitement des données de performance va renvoyer des données, dans le fichier perfdata, qui vont être représentées graphiquement par Oreon.

9. & 10. La mémorisation des informations permet d’avoir un suivi de l’état de fonctionnement d’un service dans le temps.

La deuxième partie (voir Figure 36) concerne le service par groupe d’hosts qui va permettre très facilement d’ajouter un service à plusieurs hôtes en même temps.

Cette partie ne sera pas détaillée, car elle est strictement identique à la création d’un service. La différence se trouve dans l’affichage sur l’interface graphique.

La troisième partie (voir Figure 36) concerne le groupe de service qui va permettre d’avoir un affichage groupé des services sur l’interface graphique. On peut ainsi avoir un affichage de tous les services qui tournent sur un hôte particulier, ou bien encore de tous les services similaires sur tous les hôtes.

---

Figure 37 : Création d’un groupe de service

Informations générales :

1. Le nom du serviceGroup définit le nom court utilisé pour reconnaitre le groupe.

2. L’alias est la description ou un nom long du groupe de service.

3. N’est pas utilisé.

4. N’est pas utilisé.

Relations :

5. Les hosts Service rattachés font référence à tous les services d’hôtes qui peuvent être en relation avec le groupe de service.

6. Les host group rattachés font référence à tous les services de groupes d’hôtes qui peuvent être en relation avec le groupe de service.

---

La quatrième partie (voir Figure 41) concerne la création de modèle qui va faciliter la conception des services. La conception d’un modèle de service est identique à celle d’un service donc cette partie ne va pas être détaillée. La seule différence se trouve dans les relations.

Figure 38 : Création d’un modèle de service, les relations

Relation :

1. Le premier champ vous permet d’insérer les hôtes qui sont concernés par le service.

Traps SNMP :

2. À définir

La cinquième et dernière partie (Figure 42) concerne les traps SNMP.

Figure 39 : Création d’une Trap SNMP

1. Précise le nom de la trap SNMP que vous souhaitez.

2. L’oid est une série de chiffres qui va permettre de naviguer dans les MIB SNMP pour trouver la donnée souhaitée. (voir chapitre 5.1 SNMP)

3. À définir

4. À définir

5. Ajout de commentaire sur la trap SNMP entrée.

Les commandes

Pour une bonne compréhension de l’utilisation des commandes, il faut d’abord avoir bien compris comment fonctionnent les plugins. Voir chapitre « Les plugins ».

Figure 40 : Les commandes

1. Ce champ précise le nom qui va apparaitre dans l’interface d’Oreon

2. Cette directive définit ce qu’exécute Nagios lorsque la commande est utilisée pour un contrôle de service ou d’hôte, pour une notification, ou pour un gestionnaire d’événement. Avant que la ligne de commande ne soit exécutée, toutes les macros valides sont remplacées par leur valeur.

3. Cette zone permet d’insérer un exemple d’argument pour faciliter la compréhension de la commande.

4. Précise sous quel type de commande elle va être définie.

Les escalades

L’escalade de notification est un outil très pratique, il va entre autres servir à notifier les groupes d’utilisateurs plus ou moins tôt suivant leurs degrés d’importances dans la hiérarchie des groupes d’utilisateurs.

En effet, le groupe d’administrateurs peut vouloir être informé le premier du problème, ensuite, il peut être judicieux de prévenir le groupe des techniciens si les Administrateurs ne sont pas disponibles.

Figure 41 : Menu des escalades

Dans ce menu sont présentes quatre sous-parties. Il ne va être vu ici qu’une seule de ces quatre sous-parties, car elles sont toutes reliées entre elles.

Figure 42 : Création d’une escalade de notification

---

1. Donne un nom à l’escalade.

2. Précision sur l’escalade.

3. La première notification désigne à partir de quelle notification cette escalade sera effective. En mettant cette valeur à 3, cette escalade ne va être lancée que lorsque l’hôte sera dans un état différent de « UP » depuis trois notifications.

4. La dernière notification désigne à partir de quelle notification cette escalade ne sera plus effective. En mettant une valeur de 5, cette escalade ne va pas être utilisée si plus de cinq notifications ont été envoyées pour le service spécifié. Donner une valeur de 0 revient à utiliser éternellement cette escalade.

5. Cette directive définit l’Intervalle auquel les notifications doivent être faites quand cette escalade s’applique. Donner une valeur de 0 à Nagios ne va envoyer qu’une seule notification jusqu’à ce qu’il revienne en état « UP ».

6. La période d’escalade définit à partir de quel moment dans la journée les escalades de notifications sont effectives.

7. Les options d’escalades effectuent une escalade que pour certains types de problèmes concernant les hôtes.

8. Les options d’escalades effectuent une escalade que pour certains types de problèmes concernant les services.

9. Indique les groupes d’utilisateurs concernés par cette escalade.

Pour les fenêtres suivantes, escalade d’hosts, escalade de service, escalades d’hostgroup ou escalade de meta services, il suffit d’intégrer l’hôte ou le service pour lequel une escalade de notification est désirée.

Exemple :

Figure 43 : Exemple d’escalade

Dans cet exemple il y quatre escalades de notification. Dans ces quatre escalades, la partie notification indique le contenu des champs : première notification et dernière notification. La partie groupe concerne les groupes contactés par l’escalade.

Dans la première notification, on remarque que l’intervalle de notification est de trente. L’escalade commence à partir de la deuxième notification et s’arrête à la quatrième notification. Elle concerne le groupe Admin seulement.

Donc de la deuxième à la quatrième notification toutes les trente minutes le groupe Admin va recevoir une notification.

Dans la deuxième escalade, ce vont être les groupes Admin et Technicien qui seront avertis avec un intervalle de temps de vingt-cinq minutes.

La troisième escalade avertit toujours les mêmes groupes, mais il ne va y avoir qu’une seule notification pour cette escalade, car le champ intercale de notification est à zéro. Les autres escalades ne vont pas être prises en compte pour l’hôte ou le service concerné.

Les dépendances

Les dépendances ont été créées pour ne pas surcharger un utilisateur de notification.

En effet si un routeur (hôte1) n’est plus en état de marche et que Nagios essaye de contacter un ordinateur (hôte2) qui est relié à l’hôte1, alors il enverra des notifications. Or en précisant à Nagios que l’hôte2 est dépendant de l’hôte1 alors, il n’enverra plus de notification.

Ce système fonctionne également pour les services.

Figure 44 : Menu des dépendances

Pour toutes les sous-parties, le système fonctionne de la même façon. On ne va voir ici que le menu de création d’un host.

Figure 45 : Création d’une dépendance pour un host

Information :

3. La liaison parente détermine si oui ou non l’hôte « parent » est « fils » d’un autre hôte (maitre). Si la dépendance de l’hôte maitre échoue alors, cette dépendance échouera aussi.

4. Dans les options de dépendance d’exécution se détermine quand le contrôle actif ne va pas être activé. Si l’hôte maître est dans un des états d’erreur spécifiés, l’hôte dépendant ne sera pas contrôlé activement.

5. Dans les options de dépendance de notification se détermine quand les notifications ne sont pas envoyées. Spécifier DOWN dans ce champ, indique que les notifications pour cet hôte ne seront pas envoyées si l’hôte maitre est dans un état DOWN.

6. Les « hosts dont nous dépendons » définissent les hôtes « maitres ».

7. Les « hosts dépendants » définissent les hôtes qui sont dépendants.

Nagios

Une fois la configuration des différents éléments qui font réagir Nagios complétée, il est aussi nécessaire de bien configurer les fichiers qui concernent le fonctionnement de Nagios.

Dans cet onglet, il y a aussi un sous-menu (Figure 46) qui comporte sept sous-parties.

Figure 46 : Sous-menu de l’onglet Nagios

La première sous-partie concerne la génération et l’exportation de tous les fichiers de configuration, ainsi que le rechargement et redémarrage de Nagios.

Figure 47 : Exportation des fichiers de configuration de Nagios.

Serveurs concernés :

1. C’est dans ce champ qu’il faut indiquer à Oreon où se trouvent le ou les serveurs concernés par la configuration créée grâce à l’interface d’Oreon.

---

Options génération :

2. Définit si Oreon va générer les fichiers de configurations ou non.

3. À définir

4. Inclure les commentaires détermine si les commentaires rentrés au préalable dans l’interface d’Oreon vont apparaitre.

5. Génère les fichiers de configuration en format XML.

Résultat :

6. En lançant le debug de Nagios, Oreon va déterminer si les fichiers configurés ne contiennent pas d’erreurs.

7. Pour que Nagios puisse prendre en compte les configurations créées grâce à l’interface d’Oreon, il faut activer l’option « Déplacer les fichiers ». Ainsi, les fichiers de configurations sont déplacés vers le répertoire de configuration de Nagios.

8. Le dernier champ comporte deux options. La première écrase les fichiers existants et la deuxième concerne la méthode pour relancer Nagios. La plus rapide et la plus pratique reste celle qui consiste à redémarrer Nagios.

La troisième sous-partie concerne la configuration du fichier de Nagios. La configuration qui est présentée (Figure 49) ne sera sans doute pas adaptée pour votre situation il est indispensable de modifier ce fichier en fonction de vos besoins pour que tout fonctionne normalement.

La description de ce fichier va se faire en trois étapes.

---

Première étape de configuration du fichier Nagios.cfg :

1. Permets de renommer le fichier. Il faut savoir qu’une fois sauvegardé ce fichier ne rentre pas en compte pour Nagios. Pour qu’il rentre en compte, il faut l’exporter (voir partie précédente).

2. Il est aussi possible de rajouter des commentaires pour par exemple indiquer à quel serveur il appartient.

3. Si l’option État est activée alors, le fichier de configuration est utilisé lors d’un export.

4. Indique où se trouve le fichier qui rapporte tout l’état de fonctionnement de Nagios.

5. Désigne le chemin d’accès à tous les fichiers de configurations qui permettent le fonctionnement de l’ensemble du logiciel.

6. Désigne le chemin d’accès au fichier temporaire contenant des commentaires de données, de données d’état, etc. Il est supprimé quand il n’est plus nécessaire.

8. Cette variable est utilisée pour indiquer l’emplacement d’un fichier qui contient une copie en cache des définitions des objets. Ce fichier cache est (re)créé à chaque (re)démarrage de Nagios et est utilisé par les CGI<ref>CGI : Désigne les pages web de l’interface de nagios.</ref>. Il permet d’accélérer le cache des fichiers de configuration pour les CGI, et modifie les fichiers de configuration des objets, pendant que Nagios tourne, sans que l’affichage des CGI soit modifié.

9. C’est le fichier utilisé par Nagios, pour stocker l’état courant de tous les services supervisés. L’état de tous les hôtes associés avec ses services, est également enregistré dans ce fichier. Il est supprimé à l’arrêt de Nagios, et recréé au démarrage.

10. Cette option détermine, si Nagios doit mettre à jour les données de changement d’état des hôtes, services, et programmes. Par défaut, les données d’état sont immédiatement mises à jour à chaque contrôle d’un service ou d’un hôte. Ceci peut causer une charge CPU importante, et de nombreuses entrées/sorties disque, si vous contrôlez de nombreux services. En activant cette option, la mise à jour ne se fait que sur une période de temps donné par le champ numéro onze.

11. Cette variable, détermine la fréquence (en secondes), à laquelle Nagios met à jour les données d’état dans le journal des états (Status file). L’intervalle minimal est de cinq secondes.

12. & 13. Ces deux variables indiquent quels sont l’utilisateur et le groupe de Nagios. Après le démarrage du programme, et avant toute supervision, Nagios va abandonner ses privilèges effectifs, et se lancer sous cet utilisateur et groupe.

14. Cette option détermine si Nagios envoie ou non une notification quand il (re)démarre. Si cette option est désactivée, Nagios ne va envoyer aucune notification, quel que soit l’hôte ou le service.

15. Cette option détermine si Nagios va effectuer les contrôles des services lorsqu’il (re)démarre. Si cette option est désactivée, Nagios n’effectue aucun contrôle de service, et reste dans un mode "de sommeil" (il peut quand même recevoir les contrôles passifs à moins qu’ils ne soient désactivés). Cette option est surtout utile pour définir des serveurs de supervision de secours, ou pour mettre en place un environnement de supervision répartie. (Voir chapitre 3.1 configurations des serveurs répartis)

16. Cette option détermine si Nagios accepte les contrôles passifs de service quand il (re)démarre. Si cette option est désactivée, Nagios n’accepte aucun contrôle passif de service.

17. Cette option détermine si Nagios active les gestionnaires d’événement quand il (re)démarre. Si cette option est désactivée, Nagios ne lance aucun gestionnaire d’événement lié aux hôtes ou aux services.

Figure 48 : Première partie du fichier Nagios.cfg

---

18. Cette option détermine si Nagios effectue les contrôles des hôtes à la demande ou de manière régulière lorsqu’il (re)démarre. Si cette option est désactivée, Nagios n’effectue aucun contrôle sur les hôtes et reste dans un mode "de sommeil" (il peut quand même recevoir les contrôles passifs d’hôtes à moins qu’ils ne soient désactivés). (Voir chapitre 3.1 configurations des serveurs répartis)

19. Cette option détermine si Nagios accepte les contrôles passifs d’hôte quand il (re)démarre. Si cette option est désactivée, Nagios n’accepte aucun contrôle passif d’hôte.

20. C’est la méthode de rotation que Nagios utilise pour le fichier journal. ([n] pas de rotation, [h] rotation par heure, [d] par jour, [w] par semaine, [m] par mois)

21. définit le chemin d’accès aux fichiers journaux ayant fait l’objet d’une rotation.

22. Cette option détermine si Nagios vérifie le contenu du fichier des commandes à la recherche de commandes à exécuter. Cette option doit être activée pour utiliser le CGI de commande, pour envoyer des commandes via l’interface web. Des programmes tiers peuvent également envoyer des commandes à Nagios en écrivant dans le fichier de commande, sous réserve que les droits nécessaires à l’accès au fichier aient été donnés.

23. Spécifier un nombre suivi d’un "s" (par exemple 30s), indique le nombre de secondes qui séparent deux contrôles de commandes externes. En mettant -1 Nagios vérifie aussi souvent que possible le fichier de commande externe.

24. Ce champ détermine le chemin d’accès au fichier des commandes externes.

25. C’est le fichier que Nagios utilise pour enregistrer les informations d’indisponibilité programmée des hôtes et services.

26. C’est le fichier utilisé par Nagios pour enregistrer les commentaires sur les services et les hôtes.

27. C’est l’emplacement du fichier verrou qu’utilise Nagios quand il est lancé en tant que démon (c.-à-d. démarré avec l’argument -d). Ce fichier contient l’identifiant du processus (PID) de Nagios. Pour stopper un processus, il est possible d’appliquer la commande suivante : kill PID -9.

28. Cette option détermine si Nagios doit mémoriser l’état des hôtes et des services entre deux démarrages. Une fois l’option activée, Nagios enregistre toutes les informations concernant l’état des hôtes et des services avant de s’arrêter (ou de redémarrer) et il relit les informations d’état préalablement enregistrées quand il redémarre.

29. C’est le fichier utilisé par Nagios pour mémoriser l’état des hôtes et des services entre les redémarrages. Au démarrage, Nagios positionne l’état initial des services et des hôtes à partir des informations contenues dans ce fichier, puis commence la supervision. Ce fichier est supprimé dès sa lecture effectuée.

30. Cette variable détermine la fréquence (en minutes) à laquelle Nagios va automatiquement sauvegarder les données de mémorisation en situation normale. Si la valeur est à 0, Nagios ne sauvegarde pas les données mémorisées à intervalles réguliers, mais avant de s’arrêter ou de redémarrer.

31. Cette option détermine si Nagios positionne diverses variables d’état du programme à partir des valeurs enregistrées dans le fichier de mémorisation. Parmi ces variables d’état du programme, normalement sauvegardées par delà les redémarrages du programme si la mémorisation d’état est activée, on trouve les notifications, la détection d’oscillation, l’activation des gestionnaires d’évènements, l’exécution des contrôles de services, ou l’acceptation des contrôles de service passifs.

32. Cette option détermine si Nagios va garder les informations d’ordonnancement (prochain lancement de vérification pour chaque service), lorsqu’il redémarre. En ajoutant un grand nombre (ou pourcentage) de services ou d’hôtes, il est recommandé de désactiver cette option lors du redémarrage de Nagios, car ceci peut biaiser la répartition initiale des services.

---

Deuxième étape de configuration du fichier Nagios.cfg :

Figure 49 : Deuxième partie du fichier Nagios.cfg

---

1. Cette option détermine si les messages doivent être journalisés via l’utilitaire système Syslog.

2. Cette variable détermine si les messages de notification sont journalisés ou non.

3. Cette option détermine si les tentatives répétées de contrôle d’un service sont journalisées. Ces tentatives ont lieu lorsqu’un service retourne un état différent de OK, mais que Nagios a été configuré pour essayer plus d’une fois avant de considérer cela comme une erreur.

4. Cette option détermine si les tentatives répétées de contrôle d’un hôte sont journalisées.

5. Cette option détermine si les gestions d’événements liés aux hôtes ou aux services sont journalisées. Les gestionnaires d’événements sont des commandes optionnelles qu’on peut lancer lors du changement d’état d’un hôte ou d’un service.

6. Cette variable détermine si Nagios force la journalisation de tous les états initiaux des hôtes et des services, même si leur état est OK. Les états initiaux ne sont normalement journalisés que s’il y a un problème lors du premier contrôle. Cette option peut se révéler utile pour une application tierce qui lit le journal pour en tirer des statistiques à long terme pour les hôtes et services.

7. Cette variable détermine si Nagios journalise les commandes externes reçues via le fichier des commandes externes.

8. Cette variable détermine si Nagios journalise les contrôles passifs d’hôte ou de service reçus via le fichier de commandes externes. Si vous mettez en place un environnement de supervision réparti ou si vous souhaitez utiliser fréquemment un grand nombre de contrôles passifs, vous pouvez désactiver cette option pour éviter au journal de trop grossir.

9. Cette option détermine un gestionnaire d’événement appelé à chaque changement d’état d’un hôte. Il s’exécute juste avant le gestionnaire d’événement particulier à l’hôte que vous avez précisé de manière optionnelle dans la définition de l’hôte.

10. Cette option détermine un gestionnaire d’événement appelé à chaque changement d’état d’un service. Il s’exécute juste avant le gestionnaire d’événement particulier à l’hôte que vous avez précisé de manière optionnelle dans la définition du service.

11. C’est le nombre de secondes pendant lequel Nagios va sommeiller avant de vérifier si le prochain contrôle de service ou d’hôte en file d’attente doit être exécuté. Nagios ne s’endort qu’après avoir « liquidé » les contrôles de services en retard dans la file.

12. Cette option détermine comment les contrôles de service sont initialement répartis dans la file d’attente. L’option de calcul [s] du délai (par défaut), demande à Nagios de calculer un intervalle moyen entre les contrôles, et d’ordonnancer les contrôles initiaux de tous les services à cet intervalle, ce qui permet d’éviter les pics d’utilisation du processeur. Il y a quatre choix possibles. ([n] ne pas utiliser de délais, ordonnance le lancement de tous les contrôles en même temps. [d] utiliser un délai d’une seconde entre les contrôles de service. [s] Utiliser un calcul de délai pour répartir également les contrôles de service (par défaut). [x.xx] Utiliser le délai fourni de x.xx secondes.)

13. Cette option détermine le temps maximum (en minutes) entre le démarrage de Nagios et la vérification de tous les services qui sont ordonnancés régulièrement.

14. Cette variable détermine comment les contrôles de service sont entrelacés. L’entrelacement permet une distribution plus égale des contrôles de service, une charge réduite sur les hôtes distants, et une détection globalement plus rapide des problèmes liés aux hôtes. Mettre une valeur de « 1 » est équivalent à ne pas entrelacer les contrôles de service. Mettre une valeur de « s » implique un calcul du facteur d’entrelacement automatique.

15. Cette option détermine le nombre maximal de contrôles de service pouvant tourner en parallèle à un instant donné. Une valeur de « 1 » empêche la parallélisation. Une valeur de « 0 » (par défaut) n’impose aucune restriction sur le nombre de contrôles simultanés. Il est possible d’ajuster cette valeur en fonction des capacités de la machine sur laquelle tourne Nagios, car elle a un impact direct sur la charge du système (processeur, mémoire, etc.).

16. Cette option détermine la fréquence d’exécution en secondes des événements de "consolidation" des services. Une fois le contrôle d’un service terminé, les données sont stockées dans un journal qui sera traité par Nagios lors de l’événement « consolidation », pour savoir quand (re)contrôler le service.

17. Cette option détermine comment les contrôles d’hôtes (pour les hôtes qui sont régulièrement contrôlés) sont initialement répartis dans la file d’attente. Il y a quatre choix possibles. ([n] ne pas utiliser de délais, ordonnance le lancement de tous les contrôles en même temps. [d] utiliser un délai d’une seconde entre les contrôles d’hôtes. [s] Utiliser un calcul de délai pour répartir également les contrôles d’hôtes (par défaut). [x.xx] Utiliser le délai fourni de x.xx secondes.)

18. Cette option détermine le temps maximum (en minutes) entre le démarrage de Nagios et la vérification de tous les hôtes qui sont contrôlés régulièrement.

19. C’est le nombre de secondes que contient une "unité de temps " utilisé dans la file d’ordonnancement, les re-notifications, etc.

20. Cette option détermine si Nagios va essayer de réordonnancer automatiquement les services de vérification actifs des hôtes et services pour les lisser dans le temps. Ceci peut aider à distribuer la charge sur le serveur de surveillance, car il va essayer de conserver un delta de temps cohérent entre deux vérifications.

21. Cette option détermine la fréquence (en secondes) de réordonnancement automatique.

22. Cette option détermine la fenêtre de temps (en seconde) sur laquelle Nagios va porter le réordonnancement automatique. Seules les vérifications d’hôtes et de services qui doivent avoir lieu durant les prochaines N secondes seront affectées par le réordonnancement.

23. Activer cette option revient à ralentir le contrôle des hôtes, mais peut améliorer la sûreté de fonctionnement. Il est recommandé de ne pas activer cette option.

24. Cette option détermine si Nagios essaie de détecter les hôtes et les services qui oscillent. L’oscillation apparaît lorsqu’un hôte ou un service change d’état trop fréquemment, causant l’émission d’une montagne de notifications. Quand Nagios détecte qu’un hôte ou un service oscille, il supprime temporairement les notifications pour cet hôte/service jusqu’à ce qu’il arrête d’osciller. À utiliser avec prudence.

25. Cette option permet de donner le seuil inférieur pour la détection de l’oscillation d’un service.

26. Cette option permet de donner le seuil supérieur pour la détection de l’oscillation d’un service.

27. Cette option permet de donner le seuil inférieur pour la détection de l’oscillation d’un hôte.

28. Cette option permet de donner le seuil supérieur pour la détection de l’oscillation d’un hôte.

29. Cette option détermine si Nagios utilise les informations d’état « soft » des services lors du contrôle des dépendances de service. En temps normal, Nagios n’utilise que le dernier état « hard » du service lors du contrôle des dépendances.

30. C’est le nombre maximal de secondes pendant lequel Nagios laisse tourner un contrôle de service. Si le contrôle dépasse cette limite, il est tué et un état CRITICAL est retourné. Cette option sert principalement à stopper un plugin ayant des problèmes.

31. C’est le nombre maximal de secondes pendant lesquelles Nagios laisse tourner un contrôle d’hôte. Si le contrôle dépasse cette limite, il est tué et un état CRITICAL est retourné, et l’hôte sera supposé être dans l’état DOWN. Cette option sert principalement à stopper un plugin ayant des problèmes.

32. C’est le nombre maximal de secondes pendant lequel Nagios laisse tourner un gestionnaire d’événement. Si un gestionnaire d’événement dépasse cette limite, il sera tué et une alerte sera journalisée. Cette option sert principalement à stopper un plugin ayant des problèmes.

33. C’est le nombre maximal de secondes pendant lequel Nagios laisse tourner une commande de notification. Si une commande de notification dépasse cette limite, elle sera tuée et une alerte sera journalisée. Cette option sert principalement à stopper un plugin ayant des problèmes.

34. C’est le nombre maximal de secondes pendant lequel Nagios laisse tourner une commande de traitement des données lié aux performances d’un hôte ou de traitement des données liées aux performances d’un service.

35. & 36. Ce sont les nombres maximaux de secondes pendant lesquels Nagios laisse tourner une commande de remontée de contrôle de service et d’hôte.

---

Troisième étape de configuration du fichier Nagios.cfg :

Figure 50 : Troisième partie du fichier Nagios.cfg

---

1. Cette variable détermine si Nagios remonte les résultats de contrôles de service et lance la commande de remontée de contrôle de service qui a été définie. (Voir chapitre 3.1 configurations des serveurs répartis)

2. Cette option définit la commande à lancer après chaque contrôle de service, ce qui peut être utile dans une supervision répartie. (Voir chapitre 3.1 configurations des serveurs répartis)

3. Cette variable détermine si Nagios remonte les résultats de contrôles d’hôtes et lance la commande de remontée de contrôle d’hôte qui a été définie. (Voir chapitre 3.1 configurations des serveurs répartis)

4. Cette option définit la commande à lancer après chaque contrôle d’hôte, ce qui peut être utile dans une supervision répartie. (Voir chapitre 3.1 configurations des serveurs répartis)

5. Cette valeur détermine si Nagios traite les données liées aux performances des contrôles d’hôtes et de services. Cette option est nécessaire pour la création de graphique.

6. Cette option spécifie une commande qui est lancée après chaque vérification d’hôte pour traiter les données de performance qui peuvent être retournées après la vérification.

7. Cette option spécifie une commande qui est lancée après chaque vérification de service pour traiter les données de performance qui peuvent être retournées après la vérification.

8. Cette option spécifie un fichier dans lequel les données de performance vont être écrites après chaque vérification d’hôte.

9. Cette option spécifie un fichier dans lequel les données de performance vont être écrites après chaque vérification de service.

10. Cette option détermine ce qui va être écrit (et comment) dans le fichier de performance des hôtes.

11. Cette option détermine ce qui va être écrit (et comment) dans le fichier de performance des services.

12. Cette option détermine si le fichier de performance des hôtes est ouvert en mode écrasement ou ajout. Deux options possibles. [a] ajout des données, [w] écrasement des données.

13. Cette option détermine si le fichier de performance des services est ouvert en mode écrasement ou ajout. Deux options possibles. [a] ajout des données, [w] écrasement des données.

14. Cette option spécifie l’intervalle (en secondes) entre deux traitements du fichier de performance des hôtes.

15. Cette option spécifie l’intervalle (en secondes) entre deux traitements du fichier de performance des services.

16. Cette option définit la commande qui sera exécutée pour le traitement du fichier de performance des hôtes.

17. Cette option définit la commande qui sera exécutée pour le traitement du fichier de performance des services.

18. Cette option active ou désactive la vérification des contrôles de service orphelins. Les contrôles de service orphelins sont des contrôles ayant été exécutés et supprimés de la file des évènements, mais dont les résultats n’ont pas été remontés depuis longtemps. Si certains contrôles de service semblent n’être jamais réordonnancés, activez cette option et cherchez dans les journaux, des messages concernant des services orphelins.

19. Cette option détermine si Nagios contrôle ou non périodiquement la validité des données d’un service.

20. Cette option détermine l’intervalle de temps (en secondes) entre deux contrôles de validité des données d’un service.

21. Cette option détermine si Nagios contrôle ou non périodiquement la validité des données d’un hôte.

22. Cette option détermine l’intervalle de temps (en secondes) entre deux contrôles de validité des données d’un hôte.

23. Cette option spécifie le format de date que Nagios utilise dans l’interface web.

24. Cette option spécifie quels sont les caractères illégaux dans les noms d’objets, tels qu’hôtes, services et autres.

25. Cette option spécifie les caractères illégaux qui sont filtrés dans les macros, avant qu’elles ne soient utilisées dans les notifications, les gestionnaires d’évènements et autres commandes. Ceci n’affecte pas les macros utilisées dans les contrôles des services ou des hôtes.

26. Cette option détermine si les directives dans vos définitions d’objet sont traitées comme des expressions rationnelles.

27. Cette option détermine quand les directives vont être traitées comme des expressions rationnelles

28. C’est l’adresse mail de l’administrateur local de la machine.

29. C’est le numéro du pager de l’administrateur de la machine locale.

---

La quatrième sous-partie concerne le fichier ressource.cfg. (Voir Figure 54)

Il est fortement conseillé de ne pas toucher à ce dossier étant donné qu’il est nécessaire pour tout le fonctionnement des autres fichiers de configuration qui ont besoin des plugins.

Pour modifier ce fichier, il est nécessaire d’avoir bien compris le fonctionnement des plugins. Voir le chapitre « Les plugins ».

Figure 51 : Configuration du fichier ressource.cfg

1. Cette variable définit le nom de la macro qui va déterminer le chemin d’accès aux plugins.

2. C’est dans ce champ qu’il faut indiquer le chemin des plugins.

La cinquième sous-partie concerne le fichier CGI.cfg. (Voir Figure 52).

Ce fichier est essentiellement destiné à Nagios. Il permet d’attribuer les droits d’accès aux différentes pages web de Nagios pour les utilisateurs spécifiés. Il va aussi permettre de configurer les statusmap de Nagios.

1. Permets de renommer le fichier. Il faut savoir qu’une fois sauvé ce fichier ne rentre pas en compte pour Nagios. Pour qu’il rentre en compte, il faut l’exporter.

2. Il est aussi possible de rajouter des commentaires pour par exemple indiquer à quel serveur il appartient.

3. Si l’option État est activée alors, le fichier de configuration est utilisé lors d’un export.

4. Cette option détermine le chemin d’accès à votre fichier de configuration principal. Les CGI doivent savoir où trouver ce fichier pour récupérer les informations de configuration, l’état courant des hôtes et des services, etc.

5. C’est le chemin du répertoire physique de votre serveur où sont stockés les fichiers HTML de Nagios. Nagios suppose que la documentation et les images (utilisées par les CGI) sont stockées dans des sous-répertoires nommés respectivement docs/ et images/.

Figure 52 : Configuration du fichier cgi.cfg

6. Si, lors de l’accès à Nagios via un navigateur web, il pointe sur une URL du type http://www.monserveur.com/nagios, cette variable doit avoir pour valeur /nagios. En fait, il s’agit de la partie contenant le chemin d’accès aux pages HTML de Nagios.

7. Cette option détermine si les CGI utilisent l’authentification et les autorisations pour déterminer les informations et les commandes auxquelles les utilisateurs auront accès.

8. Cette variable définit un nom d’utilisateur par défaut pour accéder aux CGI. Ainsi, les utilisateurs d’un domaine sécurisé (c.-à-d., derrière un firewall) peuvent accéder aux CGI sans avoir à s’authentifier auprès du serveur web.

9. C’est une liste de noms d’utilisateurs authentifiés, séparés par des virgules, qui peuvent voir les informations sur le système et le processus dans les CGI d’informations complémentaires. Les utilisateurs de cette liste ne sont pas automatiquement autorisés à passer des commandes système/processus.

10. C’est une liste de nom d’utilisateurs authentifiés, qui peuvent passer des commandes système/processus via le CGI de commande.

11. C’est une liste de noms d’utilisateurs authentifiés, qui peuvent voir les informations liées à la configuration via le CGI de configuration.

12. C’est une liste de noms d’utilisateurs authentifiés, qui peuvent voir l’état et la configuration de tous les hôtes.

13. C’est une liste de noms d’utilisateurs authentifiés, qui peuvent envoyer des commandes à tous les hôtes via le CGI de commande.

14. C’est une liste de noms d’utilisateurs authentifiés, séparés par des virgules, qui peuvent voir l’état et la configuration de tous les services.

15. C’est une liste de noms d’utilisateurs authentifiés, qui peuvent envoyer des commandes à tous les services via le CGI de commande.

16. Cette option permet de spécifier une image qui sera utilisée comme fond d’image dans le CGI de cartographie des états.

17. Cette option définit la méthode de dessin utilisée par défaut par le CGI de cartographie des états.

18. Cette option permet d’inclure ses propres objets dans le monde VRML généré.

19. Cette option définit la méthode utilisée par défaut pour dessiner le monde VRML avec le CGI concerné (Statusvrml).

20. Cette option spécifie le délai en secondes entre deux rafraîchissements de page dans les CGI d’état, de cartographie des états, et d’informations complémentaires.

21. 22. 23. 24. 25. Ces options permettent de spécifier un fichier audio à jouer dans le navigateur lorsqu’il y a des problèmes dans le CGI d’état. En cas de problèmes multiples, le fichier audio joué est celui du problème le plus critique (les sons sont joué à chaque rafraîchissement de la page, à cause de cela cette option n’est pas utilisée).

26. Cette option définit quelle syntaxe doit être utilisée quand on veut tester un hôte avec un « ping » à travers l’interface WAP en utilisant le CGI statuswml.

Maintenant que les fichiers de configurations sont détaillés, il est possible de créer ses propres configurations adaptées au besoin.

Configuration de Nagios et d’Oreon pour l’obtention de graphiques.

Pour avoir des graphiques qui permettent un historique des services faciles à voir, il est possible de suivre les informations suivantes. Toutefois, ce n’est qu’une option et il n’est pas obligatoire de le faire. Pour bien comprendre l’ajout des graphiques, il faut avoir bien saisi le fonctionnement des plugins (Voir chapitre « Les plugins »).

D’abord, il faut ajouter un plugin nommé « process-service-perfdata » dans le fichier des plugins de Nagios.

> cd /usr/local/nagios/libexec/ > vi process-service-perfdata

Ensuite, il faut lui ajouter les commandes suivantes :

#!/bin/bash # some parameters passed on command line TIMET=$1 HOSTNAME=$2 SERVICEDESC=$3 OUTPUT=$4 SERVICESTATE=$5 PERFDATA=$6 PERFFILE="/usr/local/nagios/var/service-perfdata" /usr/bin/printf "%b" "$TIMET\t$HOSTNAME\t$SERVICEDESC\t$OUTPUT\t$SERVICESTATE\t$PERFDATA\n" >> $PERFFILE

Il ne faut pas oublier de lui attribuer les bons droits :

> chmod +rx /usr/local/nagios/libexec/process-service-perfdata

En gros, ce fichier va permettre de créer un fichier nommé « service-prefdata » dans le répertoire usr/local/nagios/var/ qui va comporter toutes les données de performance de tous les plugins utilisés.

Pour qu’Oreon prenne en compte le nouveau plugin il faut lui indiquer où il se trouve et comment le lancer. Pour se faire, il faut aller dans le sous-menu commande de l’onglet configuration et ajouter une commande dans les commandes diverses.

(Voir Figure 56 ci-dessous)

Figure 53 : Ajout d’une commande pour les graphiques

1. Le nom indiqué est celui du fichier créé précédemment.

2. Il faut bien remplir ce champ pour qu’Oreon puisse donner les bonnes informations à Nagios pour la création du fichier service-perfdata.

3. Il est possible de créer cette commande dans une des trois options proposées.

Maintenant, il faut indiquer à Nagios de créer ce fichier service-perfadata. (Voir Figure 57)

Figure 54 : Activation du traitement des données de performance

1. Ne pas oublier d’activer le traitement des données de performance.

2. Il est possible de faire la même chose pour un hôte. Il faut bien sûr modifier le plugin pour qu’il s’adapte aux hôtes.

3. Ici est indiquée la commande à exécuter lors de la récupération des données de performance.

Une fois que tout est mis en place il faut configurer Oreon pour qu’il prenne bien en compte le fichier créé par Nagios soit service-perfdata (voir chapitre configuration d’Oreon). Ne pas oublier de rajouter dans les commandes, les options qui renvoient les données de performances. (En général les options -f ou -g -S)

Ce plugin est adapté pour le traitement des données de performance des services. Pour avoir la même chose pour les hôtes, il faut remplacer tous les endroits nommés « SERVICE » par « HOST ».

Enfin pour que les graphiques puissent être créés et apparaitre dans l’interface d’Oreon il faut lancer le service ODS.

> /etc/init.d/ods start

A cette étape le répertoire /usr/local/oreon/OreonDataStorage/ doit ce remplir de fichier *.rrd ce qui indique que les graphiques se créent bien.

Configuration sur plusieurs serveurs

La configuration de plusieurs serveurs nécessite quatre parties. D’abord la compréhension et la mise en fonction des commandes externes. Ensuite la mise en place du démon et du client NSCA. La configuration du serveur central et enfin la configuration des serveurs répartis.

Compréhension et mise en fonction des commandes externes

Nagios peut traiter des commandes d’applications externes et modifier de nombreux aspects de ses fonctions de supervision suivant les commandes qu’il reçoit.

Les commandes externes servent par exemple à stopper le contrôle d’un hôte ou d’un service. À obliger le contrôle d’un hôte ou d’un service. À stopper les notifications venant d’un hôte ou d’un service. Elles servent encore à l’ajout de commentaires pour les hôtes ou les services souhaités. Toutes ces modifications se font via l’interface web.

Dans ce cas, les commandes externes vont servir au démon NSCA du serveur central à écrire les données reçu dans le fichier des commandes externes pour ensuite être traitées par Nagios. Une fois les données traitées, Nagios et Oreon pourront afficher sur l’interface web les données reçues.

Par défaut, le traitement des données externes n’est pas utilisé. Pour traiter les données externes, il faut suivre les étapes suivantes.

Dans le fichier de configuration nagios.cfg :

Figure 55 : Activation des commandes externes

1. Activer les commandes externes

2. Régler la fréquence des contrôles des commandes externes par Nagios.

3. Indiquer l’emplacement du fichier des commandes externes.

Le dossier « rw » n’est pas créé par défaut, il faut donc le créer.

> mkdir /usr/local/nagios/var/rw/

Ensuite, il faut lui donner les droits nécessaires pour que Nagios puisse écrire et lire le contenu du fichier.

> chmod 770 rw > chmod g+s rw

Pour finir, il faut attribuer ce fichier à l’utilisateur « nagios » et au groupe « nagcmd » pour qu’ils puissent avoir les droits configurés au-dessus.

> chown nagios:nagcmd rw

Mise en place du démon et du client NSCA

Le module complémentaire NSCA va permettre d’envoyer des données en mode passif vers le serveur central (pour plus de détails sur le module NSCA, voir le chapitre les plugins).

Mise en place du démon NSCA pour le serveur central

Dans le serveur central, il est possible de lancer le démon NSCA avec le xinetd<ref>Xinetd : C’est grâce à ce système que l’on peut lancer les différents services grâce à la commande « service (nomduservice) start, stop, restart, status »</ref> en faisant les manipulations suivantes.

Normalement après la compilation du module (voir chapitre installation d’un serveur réparti) un fichier de configuration pour le xinetd a été intégré.

Il se nomme « nsca.xinetd ». Il contient les lignes suivantes :

service nsca { flags = REUSE socket_type = stream wait = no user = nagios group= nagios server = /usr/local/nagios/bin/nsca server_args = -c /usr/local/nagios/etc/nsca.cfg --inetd log_on_failure += USERID disable = no only_from = 127.0.0.1 }

Le champ « only_from » pointe sur tous les hôtes qui peuvent se connecter au démon NSCA du serveur central.

Renommez ce fichier sous « nsca » et placez-le dans le répertoire /etc/xinetd.d/. Ensuite, il faut redémarrer le service xinetd :

>service xinetd restart

Maintenant, il faut vérifier que le fichier de configuration « nsca.cfg » qui se trouve dans /usr/local/nagios/etc/ est bien configuré.

Pour plus de sécurité, il est possible d’ajouter un mot de passe pour décrypter les informations reçues. À ce moment, il faut bien configurer les droits du fichier de configuration pour que seuls les utilisateurs souhaités puissent accéder au mot de passe. Il ne faut pas non plus oublier de mettre le même mot de passe dans le fichier de configuration des serveurs répartis.

Enfin, ne pas oublier de sélectionner la méthode d’encryption, il y a plusieurs choix possibles. Plus la méthode d’encryption est sécurisée, plus les ressources processeur seront utilisées, il faut donc bien choisir entre performance et sécurité selon le cas. Bien sûr, la méthode d’encryptions utilisée doit être la même entre le serveur central et les serveurs répartis.

Mise en place du client NSCA pour les serveurs répartis

Le client NSCA ne va servir qu’à informer le client quel mot de passe et quel mode d’encryption utiliser. Il faut donc indiquer les mêmes informations pour les serveurs répartis que pour le serveur central.

Configuration du serveur central

Dans cette partie, il y a des points obligatoires pour que le serveur prenne en compte les données des serveurs répartis et d’autres points optionnels.

Dans le fichier nagios.cfg :

Pour que le serveur prenne en compte les données, il faut absolument activer les commandes externes (voir chapitre « Compréhension et mise en fonction des commandes externes »).

Il faut également que les contrôles de service passif soient activés.

Il est aussi possible d’activer les notifications (recommandé).

Si le serveur central est utilisé pour contrôler des services actifs, alors il faut laisser activer le contrôle actif des services. Sinon il est recommandé de le désactiver.

Dans les fichiers de services :

Tous les services qui sont supervisés par les serveurs répartis doivent comporter des définitions sur le serveur central. Nagios ignorera les résultats des contrôles de service passifs s’ils ne correspondent pas à un service qui a été défini.

Pour chaque service il est fortement recommandé de définir quel est son type de service (actif ou passif). (Pour les services vérifiés par les serveurs répartis, désactiver les vérifications actives !)

Pour Nagios 2.X, les vérifications passives pour les « Hosts » ne sont pas possibles, il suffit de supprimer la ligne « check_command ». Cependant, vous n’aurez plus les vérifications liées à l’équipement. Seules les vérifications des services seront présentes.

Configuration des serveurs répartis

Pour cette partie il va falloir ajouter un plugin (voir le chapitre « les plugins »).

Création d’un plugin pour retourner les données des services :

Créer un fichier nommé « service_submit_check_result » dans le répertoire « /usr/local/ nagios/libexec/ »

Dans ce fichier, placez les données suivantes :

Bien vérifier que les chemins spécifiés sont corrects et remplacer « @ip'''serveur-centrale'''' » par l’adresse IP du serveur centrale :

#!/bin/sh :# Arguments: :# $1 = host_name (Short name of host that the service is :# associated with) :# $2 = svc_description (Description of the service) :# $3 = state_string (A string representing the status of :# the given service - "OK", "WARNING", "CRITICAL" :# or "UNKNOWN") :# $4 = plugin_output (A text string that should be used :# as the plugin output for the service checks) :# :# Convert the state string to the corresponding return code :return_code=-1 :case "$3" in OK) return_code=0  ;; WARNING) return_code=1  ;; CRITICAL) return_code=2  ;; UNKNOWN) return_code=-1  ;; esac pipe the service check info into the send_nsca program, which in turn transmits the data to the nsca daemon on the central monitoring server /bin/echo -e "$1\t$2\t$return_code\t$4\n" | /usr/local/nagios/etc/send_nsca @ipserveur-centrale -c /usr/local/nagios/var/send_nsca.cfg

---

Dans l’interface d’Oreon :

Figure 56 : Création du plugin service_submit_check_result

Dans « 'Configuration>>commande>>commande divers'e » ne pas oublier d’ajouter le nom de la commande (de préférence identique au plugin) et la ligne de commande comme suit :

Nom : service_submit_check_result Ligne : $USER1$/service_submit_check_result "$HOSTNAME$" "$SERVICEDESC$" "$SERVICESTATEID$" "$SERVICEOUTPUT$"

Le fichier nagios.cfg :

La notification doit être désactivée pour ne pas recevoir de notification en doublon.

La remontée des contrôles de service doit être activée pour qu’il puisse envoyer les données au serveur central (Obsess Over Services Option).

Il y a également une commande ocsp à définir (Obsessive Compulsive Service Processor Command). Dans ce champ, il faut lui indiquer la commande créée au-dessus soit « service_submit_check_result ».

La configuration donnée ci-dessus est adaptée pour les services.

Configuration pour les hôtes.

Création d’un plugin pour retourner les données des services :

Créer un fichier nommé « host_submit_check_result » dans le répertoire « /usr/local/ nagios/libexec/ »

Dans ce fichier, placez les données suivantes :

Bien vérifier que les chemins spécifiés sont corrects et remplacer « @ip'''serveur-centrale'''' » par l’adresse IP du serveur centrale.

#!/bin/sh :# Arguments: :# $1 = host_name (Short name of host that the service is :# associated with) :# $2 = last_host_check :# $3 = state_string (A string representing the status of :# the given service - "UP", "DOWN", "UNREACHABLE" :# or "PENDING") :# $4 = plugin_output (A text string that should be used :# as the plugin output for the service checks) :# :# Convert the state string to the corresponding return code :return_code=-1 :case "$3" in UP) return_code=0  ;; UNREACHABLE) return_code=1  ;; DOWN) return_code=2  ;; PENDING) return_code=-1  ;; esac # pipe the service check info into the send_nsca program, which # in turn transmits the data to the nsca daemon on the central # monitoring server /bin/echo -e "$1\t$2\t$return_code\t$4\n" | /usr/local/nagios/etc/send_nsca @ipserveur-centrale -c /usr/local/nagios/var/send_nsca.cfg

Dans l’interface d’Oreon :

Figure 57 : Création du plugin host_submit_check_result

Dans « 'Configuration>>commande>>commande divers'e » ne pas oublier d’ajouter le nom de la commande (de préférence identique au plugin) et la ligne de commande comme suit :

Nom : host_submit_check_result Ligne : $USER1$/host_submit_check_result "$HOSTNAME$" "$LASTHOSTCHECK$" "$HOSTSTATEID$" "$HOSTOUTPUT$"

Le fichier nagios.cfg :

La notification doit être désactivée pour ne pas recevoir de notification en doublon.

La remonter des contrôles d’hôte doit être activée pour qu’il puisse envoyer les données au serveur central (Obsess Over Hosts Option).

Il y à également une commande ochp à définir (Obsessive Compulsive Host Processor Command). Dans ce champ, il faut lui indiquer la commande créée au-dessus soit « host_submit_check_result ».

À cette étape, la configuration pour l’envoi de donnée est terminée. Il ne faut pas oublier non plus de définir les mêmes services et hôtes dans le serveur central et les serveurs répartis.

Les plugins

Les plugins sont des programmes compilés ou des scripts (Perl, Shell, etc..) qui peuvent être exécutés en ligne de commande pour tester l’état d’un hôte ou d’un service . Nagios utilise le résultat des plugins pour déterminer le statut des hôtes ou des services sur le réseau.

Fonctionnement des plugins

Il faut savoir qu’il est possible de créer plusieurs types de plugins. Des plugins qui servent essentiellement au contrôle des hôtes et des services. Des plugins qui permettent de notifier un utilisateur sur le mauvais fonctionnement d’un hôte ou d’un service. Pour finir, des plugins qui permettent d’ajouter des événements à Nagios.

Suivant ces trois types de plugins le codage standard est différent.

Plugins de contrôle

Pour créer un plugin de contrôle, il faut respecter les points suivants :

Le plugin doit renvoyer quatre types de données différentes :

- L’état « OK », le plugin a pu contrôler le service et tout semble fonctionner.

- L’état « WARNING », soit le plugin a pu contrôler le service, mais il parait être au-dessus de la limite fixée, ou le service ne fonctionne pas correctement.

- L’état « CRITICAL », soit le plugin a pu contrôler le service, mais il parait être au-dessus de la limite fixée, ou le service ne fonctionne pas.

- L’état « UNKNOWN », le service n’a pu être contrôlé pour des raisons qui peuvent être diverses. (Argument invalide, impossibilité d’ouvrir la communication TCP, etc.)

Les options suivantes peuvent être présentes (elles ne sont pas obligatoires, mais représentent le standard des plugins de Nagios) :

« -H » cette option détermine l’adresse IP de l’hôte à contacter

« -p » cette option peut déterminer 2 types d’informations. Le numéro de port de l’hôte que l’on veut contacter ou le mot de passe de la communauté SNMP.

« -w » cette option détermine le seuil à ne pas dépasser pour lequel le plugin enverra une information de type « WARNING ».

« -c » cette option détermine le seuil à ne pas dépasser pour lequel le plugin enverra une information de type « CRITICAL ».

« -h » cette option affiche une aide des différentes options disponible et utilisable pas ce plugin.

« -C » cette option permet à l’utilisateur d’indiquer quelle communauté SNMP utiliser pour le contrôle de l’hôte.

Plugins de notification

Les plugins de notification n’ont pas besoin de fichier dans le répertoire /libexec/ de Nagios. Il est possible de définir directement quel type de notification vous désirez par l’interface d’Oreon.

L’exemple qui suit va permettre de mieux comprendre le fonctionnement de ce type de plugin.

Commande entrée dans l’interface d’Oreon :

Figure 58 : Notification par email

Pour une bonne compréhension, le champ « commande » (voir Figure 58) va être expliqué étape par étape en relation avec la Figure 59.

« /usr/bin/printf "%b" » cette partie va permettre d’afficher l’email à l’utilisateur avec les options qui suivent.

« "exemple" » tout ce qui se trouve entre les doubles cotes est pris en compte dans l’email.

« ***** Oreon Notification ***** » on peut voir que dès maintenant ce qui est écrit dans le champ « commande » est affiché dans l’email.

« /n » représente un retour à la ligne.

« Notification Type: $NOTIFICATIONTYPE$ » la notification type est bien prise en compte, mais le reste ne s’affiche pas. En effet, « $NOTIFICATIONTYPE$ » est remplacé par « PROBLEM » dans l’email. Comme « $NOTIFICATIONTYPE$ » est une macro, alors elle est remplacée par la valeur que Nagios lui donne donc « PROBLEM ». Il y a cinq valeurs possibles "PROBLEM", "RECOVERY", "ACKNOWLEDGEMENT", "FLAPPINGSTART" ou "FLAPPINGSTOP".

Les commandes suivantes fonctionnent exactement de la même façon jusqu’à la fermeture de la double cote.

« | » C’est à partir de cette barre que l’entête de l’email est complété.

« @MAILER@ » ceci indique le chemin d’accès du client mail « /bin/mail ».

« -s » cette option indique que la suite de la commande concerne le champ « objet » de l’entête.

« $CONTACTEMAIL$ » cette macro va être remplacée par l’adresse email de l’utilisateur.

---

Email reçut dans la boite mail de l’utilisateur notifié :

Figure 59 : Email reçu grâce à la notification

Plugins d’évènement

Les plugins d’évènements vont essentiellement servir à faire une action sur l’hôte pour régler le problème automatiquement. Ainsi, il est possible, par exemple, de faire redémarrer un service ou même un hôte via ssh<ref>Ssh : C’est un protocole qui permet d’accéder à une machine à distance au travers d’un canal crypté.</ref> pour le remettre en état de marche.

Les commandes d’évènement ne sont lancées que dans les cas de figure suivants (concerne aussi bien les services que les hôtes) :

• État d’erreur « soft »
• État d’erreur « hard »
• Rétablissement après un état d’erreur « soft » ou « hard »

Les commandes d’évènement doivent être écrites de façon à accepter les macros suivantes :

Macros de gestionnaire d’événement de service :

• $SERVICESTATE$
• $SERVICESTATETYPE$
• $SERVICEATTEMPT$

Macros de gestionnaire d’événement d’hôte :

• $HOSTSTATE$
• $HOSTSTATETYPE$
• $HOSTATTEMPT$

Les scripts doivent examiner les valeurs des arguments qui leurs sont passées et exécuter les actions nécessaires en fonction de ces valeurs.

Exemple d’évènement :

Dans l’interface d’Oreon « Configuration >> commande >> commandes diverses », ajouter une nouvelle commande du nom de « restart_httpd », ajouter dans le champ « ligne de commande » le chemin d’accès au plugin et les macros vues précédemment.

/usr/local/nagios/libexec/restart-httpd $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$

Dans le répertoire de /libexec/ de Nagios créer le nouveau plugin sous le nom de « restart_httpd » et ajouter ce qui suit :

#!/bin/sh # # # Note: Ce script ne va essayer de redémarrer le service httpd que si Nagios l’a déjà contrôlé # trois fois (en état soft) ou si le service est dans un état hard. # Dans quel état se trouve le service http ? case "$1" in OK) :# le service n’a plus de problème donc ne rien faire… :;; WARNING) :# cet état n’est pas un problème grave puisque que le service continu de tourné... :;; UNKNOWN) :# Le problème n’est pas défini et ne vient pas forcément du service, donc on ne fait rien... :;; CRITICAL) :# Le service à un problème il va peut-être falloir le redémarrer... :# État soft ou hard ? :case "$2" in :# Dans l’état soft, Nagios vérifie si le service est vraiment hors service :# en le (re)contrôlant jusqu’à ce qu’il se mette en état hard et envoie une notification... :SOFT) Ici le plugin vérifie le nombre de fois que le service a été contrôlé. case "$3" in Le plugin attend que la valeur qu’il reçoit par Nagios atteigne trois. Au bout du troisième contrôle, le plugin va redémarrer le service. Si cette variable atteint la valeur « quatre » cela voudra dire que le redémarrage du service n’a pas fonctionné. On passe donc en état « hard ». Si le redémarrage du service à réglé le problème alors personne ne sera notifier. 3) echo -n /etc/rc.d/init.d/httpd restart ;; esac ;; :# Si le redémarrage n’a pas fonctionné, alors on rentre dans l’état « hard ». :# Une notification a dû être envoyée si vous l’avez défini ainsi. :# Mais on peut toujours faire un dernier essai au cas où… :HARD) echo -n /etc/rc.d/init.d/httpd restart ;; esac ;; esac exit 0

Il ne faut pas oublier d’ajouter cette commande au service défini grâce à l’interface d’Oreon dans le champ « Commande associée ». Il est ainsi possible de créer un grand nombre d’évènements suivant le problème à résoudre et comment le résoudre.

Utilisation des plugins

Pour bien utiliser un plugin il est préférable de connaitre les options requises pour qu'il fonctionne. En règle générale, tous les plugins officiels comportent une aide qui indique exactement de quoi a besoin le plugin.

Pour l’exemple qui suit, le SNMP doit être installé (voir le chapitre SNMP).

Cet exemple va mettre en œuvre le test de la RAM<ref>RAM : Pour que l’ordinateur puisse fonctionner, il a besoin d’une mémoire à court terme pour par exemple maintenir un programme lancé et en état de marche.</ref> d’un hôte qui tourne sur Linux. Il va être possible de savoir la quantité de mémoire utilisé en pourcentage, ainsi que l’intégration de seuil « WARNING » et « CRITICAL » pour la notification.

Pour commencer il faut aller dans le répertoire /libexec/ de Nagios. Ensuite, afficher l’aide du plugin qui va permettre le test de la RAM.

> ./check_snmp_storage.pl -h

Il est préférable de tester le plugin en ligne de commande avant de l’intégrer dans la configuration du service.

>./check_snmp_storage.pl -H 192.168.1.2 -C public -m Real memory -w 70 -c 85 –v

Cette commande va renvoyer les données de la RAM de l’hôte « 192.168.1.2 » à l’initiateur de la commande. Les options « -w » et « -c » indiquent les seuils de « WARNING » et « CRITICAL ». L’option « -v » affiche tout ce qui peut être contrôlé par ce plugin.

On obtient la réponse suivante :

OID : 1.3.6.1.2.1.25.2.3.1.3.3, Desc : Swap Space OID : 1.3.6.1.2.1.25.2.3.1.3.8, Desc : /var/lib/nfs/rpc_pipefs OID : 1.3.6.1.2.1.25.2.3.1.3.5, Desc : /sys OID : 1.3.6.1.2.1.25.2.3.1.3.2, Desc : Real Memory Name : Real Memory, Index : 2 OID : 1.3.6.1.2.1.25.2.3.1.3.4, Desc : / OID : 1.3.6.1.2.1.25.2.3.1.3.6, Desc : /boot OID : 1.3.6.1.2.1.25.2.3.1.3.1, Desc : Memory Buffers OID : 1.3.6.1.2.1.25.2.3.1.3.7, Desc : /proc/sys/fs/binfmt_misc storages selected : 1 Descr : Real Memory Size : 515524 Used : 331732 Alloc : 1024 Perf data : ’Real Memory’=324MB;352;428;0;503 Real Memory: 64%used(324MB/503MB) (<70%) : OK

Il faut maintenant ajouter le plugin dans Oreon pour que Nagios puisse faire le contrôle de lui-même. Pour ajouter un plugin dans Oreon, il faut aller dans le menu configuration puis commande.

Il est possible que la commande « check_snmp_storage » n’existe pas. Il est important de l’ajouter sinon il ne va pas être possible de faire le contrôle de la RAM de l’hôte.

Figure 60 : Ajout d’une commande

La ligne de commande sert à ajouter les options que l’on souhaite avoir en faisant le contrôle de l’hôte. Dans ce cas il ne va y avoir que le strict minimum soit la communauté, la mémoire à tester, les seuils « WARNING » et « CRITICAL » et enfin « -f » qui permet de renvoyer des données de performances pour en faire des graphiques.

Les macros $ARG$ sont remplacées par les valeurs qui sont mises dans le champ argument du service.

Pour que le plugin soit pris en compte, il ne faut pas oublier de créer un service qui va contenir la commande à appliquer.

Une fois le service créé il faut lui indiquer quoi contrôler :

Figure 61 : Ajout d’une commande dans un service

Dans le champ argument il y a les données qui correspondent aux options définies plus haut dans la création de la commande. Les données grisées sont un exemple des valeurs qui peuvent être inséré dans le champ argument. Ne pas oublier le point d’exclamation, c’est lui qui sépare les différentes données entre elles.

Comme il a pu être vu, l’ajout de plugin se fait de manière relativement simple à condition de bien respecter les différentes contraintes que Nagios impose. Il est aussi préférable de connaitre un peu la programmation pour créer ses plugins. A l’inverse l’utilisation des plugins ce fait de manière réellement simple pour tout le monde il n’y a pas besoin de connaitre la programmation pour en ajouter dans l’interface d’Oreon.

Le SNMP, les démons NSCA/NRPE

Ce chapitre est décomposé en trois parties. D’abord il va être vu ce qu’est exactement le SNMP, ensuite à quoi sert le NSCA et enfin à quoi sert le NRPE.

Le protocole SNMP

Qu’est-ce que le SNMP

Le sigle SNMP signifie Simple Network Management Protocol (protocole simple de gestion de réseau). Il s’agit d’un protocole de communication supportant TCP/IP qui permet aux administrateurs réseau de gérer les équipements du réseau et de diagnostiquer les problèmes à distance.

Il permet principalement de :

• Disposer d’une cartographie du réseau.
• Fournir un inventaire précis de chaque machine.
• Mesurer la consommation d’une application.
• Signaler les dysfonctionnements.

Avantages :

• Protocole très simple, facile d’utilisation.
• Permet une gestion à distance des différentes machines.
• Indépendant de l’architecture des machines administrées.

Grâce à ce protocole, l’administrateur est capable de gérer une grande partie du réseau depuis sa machine.

En pratique

Le système de gestion de réseau est basé sur deux éléments principaux : un superviseur et des agents. Le superviseur est la console qui permet à l’administrateur réseau d’exécuter des requêtes de management.

Les agents sont des entités qui se trouvent au niveau de chaque interface connectant l’équipement managé au réseau et permettant de récupérer des informations sur différents objets.

Switchs, hubs, routeurs et serveurs sont des exemples d’équipements contenant des objets manageables. Ces objets manageables peuvent être des informations matérielles, des paramètres de configuration, des statistiques de performance et autres objets qui sont directement liés au comportement en cours de l’équipement en question.

Ces objets sont classés dans une base de données appelée MIB (Management Information Base). SNMP permet le dialogue entre le superviseur et les agents afin de recueillir les objets souhaités dans la MIB.

Il existe plusieurs versions de SNMP plus ou moins sécurisées :

SNMP v1		Mots de passe en clair…
SNMP v2		Sécurisée mais trop lourde
SNMP v2c		Support des communautés
SNMP v3		Dernière version (support des communautés et est sécurisée)

Il existe des communautés pour séparer les droits d’utilisation. Une communauté SNMP est une relation entre un agent et les stations d’administration qui définit l’authentification et le contrôle d’accès.

La MIB

Une MIB (Base d’information de gestion) est un ensemble d’informations structuré sur une entité réseau, par exemple un switch ou un onduleur. Ces informations peuvent être récupérées, ou parfois modifiées, par le protocole SNMP.

La structure de la MIB est hiérarchique : les informations sont regroupées en arbre. Chaque information est repérée par un OID (Object IDentifier), une suite de chiffres séparés par des points, qui l’identifie de façon unique. Elle est aussi repérée par un nom, indiqué dans le document qui décrit la MIB.

Par exemple, 1.3.6.1.2.1.2.2.1.2 est OID ifDescr qui est la chaîne de caractères décrivant une interface réseau.

La MIB est représenté en arbre :

Figure 62 : Représentation d’une MIB

Le protocole

Pour pointer sur un élément de la MIB le SNMP utilise une commande nommée OID, mais comment fait-il pour communiquer sur le réseau avec l’agent (l’équipement) ?

Voici un tableau récapitulatif de toutes les commandes possibles par le SNMP version1 :

Commande	Action
get-request	Le Manager SNMP demande une information à un agent SNMP
get-next-request	Le Manager SNMP demande l’information suivante à l’agent SNMP
set-request	Le Manager SNMP met à jour une information sur un agent SNMP
get-reponse	L’agent SNMP répond à un get-request ou a un set-request
Trap	L’agent SNMP envoie une alarme au Manager

Tableau 63 : Récapitulatif des commandes SNMP

Voici comment cela se passe sur le réseau :

Figure 64 : Dialogue SNMP entre le manager et l’agent

Les commandes get-request, get-next-request et set-request sont toutes émises par le manager à destination d’un agent et attendent toutes une réponse get-response de la part de l’agent.

La commande Trap est une alerte. Elle est toujours émise par l’agent à destination du manager, et n’attend pas de réponse.

Installation et configuration

Il faut installer les packages Net-SNMP et Net-SNMP utils.

> yum install net-snmp > yum install net-snmp-utils

Pour la configuration c’est un peu plus compliqué. L’exemple qui suit va permettre de mieux comprendre comment configurer le SNMP, mais n’est pas forcement une configuration adaptée pour un réseau réel.

Le fichier de configuration ce trouve dans /etc/snmp/snmpd.conf

Ce fichier est relativement bien documenté donc il ne faut pas le supprimer il peut servir à comprendre comment fonctionne le SNMP.

Exemple de configuration :

syscontact adresse mail # 1° créer des relations entre les communautés et des noms de sécurité #nom.secusourcecommunaute com2secLocal localhostprive com2sec LocalNet 192.168.0.0/24 public # 2° créer des relations entre des noms de groupes et les noms de sécurité #nom.groupeversionnom.secu group RWGroup v1 Local group ROGroup v1 LocalNet #3° Créer les diverses vues qui seront autorisées aux groupes # view tout included .1 #4° Indiquee les accès aux vues suivants les groupes #nom.groupecontextemodele.secuniveau.secu prefixe lecture ecriture notification access ROGroup"" v1 noauth exact tout none none access RWGroup "" v1 noauth exact tout tout none

La communauté « public » pourra lire la totalité de la MIB depuis n’importe quelle machine du réseau, la communauté « prive » pourra lire et écrire partout où ce sera possible dans la MIB, uniquement depuis le poste local (localhost).

Une fois la configuration adaptée au besoin du réseau il ne faut oublier de relancer le service SNMP.

Le NSCA

Le NSCA permet d’envoyer des résultats de contrôles passifs de services à un autre serveur sur le réseau sur lequel tourne Nagios. Les contrôles sont actifs sur les serveurs répartis, passifs sur le serveur central.

Le NSCA est composé de quatre fichiers :

nsca	- Démon qui tourne sur le serveur central de Nagios et qui traite les résultats des contrôles faits sur les services passifs soumis par les clients.
nsca.cfg	- Fichier de Configuration pour le démon nsca
send_nsca	- Programme client exécuté sur les serveurs répartis qui envoie les résultats des services au démon nsca sur le serveur principal Nagios.
send_nsca.cfg	- Fichier de configuration pour le client send_nsca

Tableau 65 : Fichiers NSCA

Cet ajout vous permet d’envoyer des résultats de contrôles de services passifs à partir de machines distantes à une machine centrale sur laquelle Nagios tourne.

Le client peut être utilisé comme un programme séparé, ou peut être intégré dans des serveurs NAGIOS distants qui exécutent la commande ocsp pour créer un environnement de contrôles distribués.

La communication entre le client et le démon peut être cryptée par différents algorithmes (DES, 3DES, CAST, xTEA, Twofish, LOKI97, RJINDAEL, SERPENT, GOST, SAFER/SAFER+, etc.) si les bibliothèques mcrypt sont installées sur vos systèmes.

---

Exemple de configuration d’un fichier « Nsca.cfg » :

#fichier dans lequel sera inscrit le PID de nsca pid_file=/var/run/nsca.pid # indique quel est le port que le serveur NSCA doit écouter server_port=5667 #indique sous quel utilisateur/groupe soit être exécuté le serveur NSCA nsca_user=nagios nsca_group=nagios #indique dans quel fichier le serveur NSCA doit écrire les résultats reçus des clients NSCA. command_file=/usr/local/nagios/var/rw/nagios.cmd # max_packet_age=30 #renseigner le mot de passe utilisé pour décrypter les communications reçues des clients #NSCA password=mdp_nsca #Types utilisés pour décrypter les communications entre les clients et le serveur NSCA # Values: 0 = None (Do NOT use this option) 1 = Simple XOR (No security, just obfuscation, but very fast) 2 = DES 3 = 3DES (Triple DES) 4 = CAST-128 5 = CAST-256 6 = xTEA 7 = 3WAY 8 = BLOWFISH 9 = TWOFISH 10 = LOKI97 11 = RC2 12 = ARCFOUR 14 = RIJNDAEL-128 15 = RIJNDAEL-192 16 = RIJNDAEL-256 19 = WAKE 20 = SERPENT 22 = ENIGMA (Unix crypt) 23 = GOST 24 = SAFER64 25 = SAFER128 26 = SAFER+ #définition du type de décryptage utilisé decryption_method=1

Il ne reste plus qu’à lancer le démon NSCA par la commande :

> /usr/local/nagios/bin/nsca –c /usr/local/nagios/etc/nsca.cfg

Le NRPE

Le NRPE permet d’exécuter des plugins sur des machines distantes de manière transparente et relativement aisée.

Le NRPE est composé de trois fichiers :

check_nrpe	- Plugin utilisé pour envoyer des requêtes sur l’agent nrpe de la machine distante
nrpe	- Agent qui tourne sur la machine distante et exécute les requêtes du plugin
nrpe.cfg	- Fichier de configuration pour les agents des machines distantes

Tableau 66 : Fichiers NRPE

Cet ajout est conçu pour permettre l’exécution de plugins sur une machine distante. Le plugin check_nrpe tourne sur la machine Nagios et est utilisé pour envoyer les requêtes d’exécution du plugin à l’agent NRPE de la machine distante.

L’agent NRPE exécutera le plugin approprié sur la machine distante, et retournera les données de sortie et le code de retour au plugin check_nrpe de la machine Nagios.

Le plugin check_nrpe envoie la sortie du plugin distant et le code de retour à Nagios comme si c’était le sien. Cela permet d’exécuter les plugins de manière transparente sur les machines distantes. (Voir Figure 67).

Figure 67 : Le NRPE

Il est possible de combiner le SNMP, le NSCA et le NRPE pour contrôler totalement le réseau par l’intermédiaire d’un serveur de supervision réseau centrale.

En effet grâce au NSCA les serveurs répartis vont pouvoir transmettre des informations périodiquement au serveur central. Le serveur central peut agir sur les serveurs répartis grâce au NRPE.

Exemple de base

Ce n’est pas le tout de détailler tous les fichiers de configuration, mais il faut aussi comprendre comment faire pour que ça marche. Les exemples qui suivent sont juste des exemples de base et ne vont peut-être pas s’adapter à des configurations complexes. Mais des bonnes bases permettent toujours d’aller dans le complexe.

Démarche à suivre

Pour que l’ensemble des services proposés par Nagios et Oreon soient pris en compte, il est d’abord requis d’ajouter un utilisateur et un groupe d’utilisateurs. Ensuite, il est possible d’ajouter un hôte et un groupe d’hôtes et enfin, on peut ajouter des services.

Il faut bien comprendre que pour remplir un hôte ou quoi que se soit, Nagios a besoin de certaines données qui sont obligatoires. Toute donnée obligatoire est marquée avec une petite étoile rouge *.

Les exemples qui suivent ne font que remplir ces champs marqués de ces étoiles rouges *.

Exemple d’utilisateur

L’utilisateur est la personne qui se connecte à l’interface, mais surtout, c’est la personne qui va recevoir les notifications. Voici un exemple de configuration d’un utilisateur.

Figure 68 : Exemple d’utilisateur

Exemple de groupe d’utilisateurs

Le groupe d’utilisateurs est essentiel pour avoir un classement des utilisateurs. Quand Nagios envoie une notification, il l’envoie à un groupe d’utilisateurs et non à un seul d’entre eux.

Il est conseillé de créer ces groupes par degré d’importance.

Exemple de configuration d’un groupe d’utilisateurs :

Figure 69 : Exemple de groupe d’utilisateurs

Exemple d’hôte

Un hôte est essentiel pour la création des services, sans hôtes, pas de services. L’hôte présenté ci-dessous est un Switch Nortel, ou l’on va contrôler son état avec la commande check-host-alive.

Figure 70 : Exemple d’hôte

Exemple de groupe d’hôtes

Il n’est pas nécessaire de créer un groupe d’hôtes pour utiliser des services. Mais le concept de groupe est une chose importante dans Nagios, c’est pourquoi il est important d’en créer. Un groupe d’hôtes va entre autres servir à contrôler avec un seul service tous les hôtes du groupe en même temps.

Figure 71 : Exemple de groupe d’hôtes

Exemple de service

Le service est ce qui va contrôler l’état d’une application particulière d’un hôte. Grâce à ce système, Nagios va pouvoir déterminer si un service (du type HTTP) est en état critique et ainsi agir dessus (comme redémarrer le service HTTP). Ici il est présenté comment contrôler le trafic d’une interface particulière du Switch Nortel.

Figure 72 : Exemple de service onglet configuration

Figure 73 : Exemple de service onglet relation

Exportation de la configuration et redémarrage de Nagios

Pour être sur que la configuration est bonne avant de l’exporter et de redémarrer Nagios, il est conseillé de ne pas mettre sur « OUI » les options « déplacer les fichiers » et « recharger Nagios » qui se trouvent dans « Configuration >> Nagios >> Exporter ». Il ne faut pas non plus oublier de cocher « OUI » l’option « Lancer le debug de Nagios (-v) ». Une fois ces options bien réglées il faut générer les fichiers. Il donne ainsi les résultats suivants :

Figure 74 : Résultat obtenu sans redémarrage de Nagios

Une fois que tout semble normal, il faut déplacer les fichiers de configurations dans le répertoire de Nagios et le relancer.

Figure 75 : Exportation des fichiers de configurations

L’interface d’Oreon

Pour bien prendre en main le logiciel, il est aussi important de comprendre l’interface graphique de celui-ci. Ce chapitre va détailler les points les plus importants de l’interface d’Oreon. Il va se diviser en cinq parties.

L’accueil

Figure 76 : Accueil d’Oreon

La page d’accueil a été conçue de façon à voir tout de suite s’il y a un problème avec un hôte ou un service ou si tout fonctionne correctement.

1. & 2. Ce système permet à l’utilisateur d’aller directement sur l’hôte ou le service qui pose problème. Ces deux barres s’affichent en permanence sur l’interface.

3. & 4. Ces deux diagrammes affichent un pourcentage d’hôtes et de services suivant l’état de ceci.

Le Monitoring

Le monitoring va permettre entre autres de savoir quels sont les hôtes ou les services qui posent problème, mais aussi de stopper ou de redémarrer le contrôle d’un hôte ou d’un service. (voir Figure 77)

Figure 77 : Le monitoring

1. L’interface propose un système de recherche d’hôte ou de service. Quand il y a plusieurs centaines d’hôtes et de services cette option est bien pratique.

2. Le monitoring propose de contrôler les services en premier, ensuite les hôtes et enfin les évènements gérés par Nagios.

3. Pour les services seulement il est possible de forcer le contrôle de celui-ci ou de le stopper. Toutes les actions possibles sont disponibles dans ce menu déroulant.

4. Ce menu propose d’afficher soit juste les services ayant des problèmes soit tous les services. Il est aussi possible de classifier les services par hôte ou par groupe d’hôtes ou de services. Les grilles de statuts permettent d’afficher l’état des services sans détails.

5. C’est dans ce petit menu qu’il est possible de voir qui est connecté sur l’interface graphique d’Oreon.

Le reporting

Le reporting va permettre à l’utilisateur d’avoir un historique du fonctionnement de l’hôte et des services. Il y a aussi un calcul de pourcentage de l’état de l’hôte par rapport à une période de temps qui peut être spécifiée par l’utilisateur. (Voir Figure 78)

1. C’est un diagramme qui représente le pourcentage d’activité de l’hôte sur la période de temps défini par l’utilisateur.

2. L’utilisateur peut ici définir la période qui va être prise en compte par Oreon pour afficher les statistiques.

3. Tableau récapitulatif de l’état de l’hôte. En pourcentage.

4. Tableau récapitulatif de tous les services associé à l’hôte avec leurs états respectifs en pourcentage. Il est possible de cliquer sur un service pour obtenir des détails approfondis.

5. Le calendrier peut être déplacé en laissant le bouton gauche de la souris enfoncer et en se déplaçant de gauche à droite. Permets de naviguer dans le calendrier pour afficher un jour précis.

Figure 78 : Le reporting

La vue Oreon

La vue Oreon est la page web ou tous les graphiques sont affichés.

Figure 79 : Vue Oreon

Les graphiques générés par le « Oreon graphes » sont faits par ODS. Les « Graph par plugins » sont générés uniquement grâce au plugin et ne passent pas par ODS.

Les fiches d’identités

Les fiches d’identité affichent les détails des hôtes entrés dans Nagios. Pour que cette fonction soit utilisée, il faut qu’un agent SNMP soit installé sur l’hôte à superviser.

Figure 80 : Fiches d’identités

Il est ainsi possible de voir les descriptions suivantes :

• Brève description de la machine.
• Description de la carte réseau.
• Description de la mémoire en générale (disque dur, RAM, etc.).
• Les différents logiciels installés.
• Les processus qui tournent.

L’interface d’Oreon est donc conçue de façon à ce que l’on puisse toujours voir s’il y a un problème sur le réseau, elle permet aussi de bien classifier les problèmes pour savoir rapidement où se trouvent les défauts majeurs qui induisent des dysfonctionnements dans le système. Il est aussi possible de modifier le contrôle d’un service pour l’adapter à nos besoins de façon rapide.

Exemple de monitoring

Dans ce chapitre il va être vu trois exemples d’intégration d’hôtes avec leurs services respectifs. D’abord sur une station Windows, ensuite sur une station Linux et enfin sur un Switch Nortel. Tous les exemples qui suivent implique qu’un utilisateur, un groupe d’utilisateur et qu’un groupe d’hôtes aient été créés.

Station Windows

Quatre services vont être intégrés à cette station. La plupart des services vont être contrôlés grâce au protocole SNMP.

Intégration de l’hôte

Pour voir plus de détails sur la configuration de l’hôte qui suit voir le chapitre « Host ».

Notre hôte va se nommer Host1 et son alias est Windows.

Pour contrôler l’état de l’hôte il a été défini d’utiliser la commande check_host_alive.

Intégration de la commande de contrôle CPU

Dans ces exemples, il ne va être donné que la commande pour afficher les données voulues. Pour plus de précision, voir les chapitres précédents sur la configuration d’un service, et le chapitre sur les plugins.

Afficher l’aide du plugin :

> ./check_snmp_load.pl -h

Commande sous console :

> ./check_snmp_load.pl -H 192.168.1.1 -C public -w 70 -c 80 -T stand

Intégration de la commande de contrôle de l’espace disque

Afficher l’aide du plugin :

> ./check_snmp_storage.pl -h

Commande sous console :

> ./check_snmp_storage.pl -H 192.168.1.1 -C public -m ^[C]: -w 90 -c 95

Intégration de la commande de contrôle de la mémoire

Afficher l’aide du plugin :

> ./check_snmp_storage.pl -h

Commande sous console :

> ./check_snmp_storage.pl -H 192.168.1.1 -C public -m Physical Memory -w 90 -c 95

Station Linux

De même que pour la station Windows il y a quatre services intégrés qui sont principalement utilisés avec du SNMP.

Intégration de l’hôte

Notre hôte va se nommer Host2 et son alias est Linux.

Pour contrôler l’état de l’hôte il a été défini d’utiliser la commande check_host_alive.

Intégration de la commande de contrôle CPU

Afficher l’aide du plugin :

> ./check_snmp_load.pl -h

Commande sous console :

>./check_snmp_load.pl -H 192.168.1.2 -C public -w 5,7,10 -c 15,17,20 -T netsl

Intégration de la commande de contrôle de l’espace disque

Afficher l’aide du plugin :

> ./check_snmp_storage.pl -h

Commande sous console :

> ./check_snmp_storage.pl -H 192.168.1.2 -C public -m / -r -w 90 -c 95

Intégration de la commande de contrôle de la mémoire

Afficher l’aide du plugin :

> ./check_snmp_storage.pl -h

Commande sous console :

> ./check_snmp_storage.pl -H 192.168.1.2 -C public -m Real Memory -w 90 -c 95

Switch Nortel

Pour le switch Nortel, il est possible de voir toutes les interfaces utilisées grâce à un plugin nommé check-graph-traffic.

Pour voir le numéro de ces interfaces, il faut taper la commande suivante :

> ./check_graph_traffic.pl -H 192.168.1.254 -C public -v 2 -s

Pour contrôler le trafic d’une interface :

> ./check_graph_traffic.pl -H 172.16.16.254 -C public -v 2 -i 2 -w 80 -c 95

N’oubliez pas que pour avoir des graphiques il faut obligatoirement ajouter les options -f ou

-g -S suivant ce que supporte le plugin.

Création d’une cartographie

Pour bien afficher la cartographie du réseau, il est impératif d’avoir le navigateur Mozilla Firefox. En effet, la dernière version d’Internet Explorer ne prend pas bien en charge ce module.

D’abord, télécharger le module suivant :

http://download.oreon-project.org/index.php?id=57

Ensuite, décompressez-le :

> tar -xzf NagiosStatusMap-1.0.tar.gz

Il faut maintenant le déplacer dans le répertoire suivant :

> mv statusmap /usr/local/oreon/www/modules

Ne pas oublier de mettre les bons droits et utilisateurs :

> chown -R apache:apache statusmap

Enfin, sur l’interface graphique d’Oreon allez dans « Options >> modules », et installez le module en cliquant sur l’icône de la colonne Actions.

Configurer la statusmap dans « Option >> Options Générales >> Nagios Status Map »

Figure 81 : Configuration de la status map

Ne pas oublier de mettre la bonne adresse IP et le bon mot de passe pour accéder aux informations stockées dans la CGI Status Map de Nagios.

Pour accéder à la Status Map il faut aller dans le menu Monitoring. On obtient ainsi la cartographie de Nagios.

Figure 82 : Exemple de cartographie

Conclusion :

À travers cette documentation, il aura été vu, l’importance de l’intégration d’un système de supervision réseau. En effet, un réseau instable empêche le bon fonctionnement d’une entreprise.

Ensuite, l’installation et la configuration du service sont des étapes primordiales pour l’intégration du serveur de supervision. Effectivement, un serveur mal optimisé devient lent et peut encombrer le réseau inutilement.

La conception de plugin et l’utilisation du SNMP et des démons NSCA et NRPE sont des étapes peut-être aussi importantes que la configuration, car elles optimisent au maximum les capacités du logiciel.

Enfin, la création d’une cartographie aura été expliquée pour les entreprises qui souhaitent obtenir rapidement des informations sur l’emplacement des différents équipements réseau ou tout simplement pour avoir une vue hiérarchisée de leur réseau.

Répertoire des illustrations:

Bibliographie :

Documentation complète sur les fichiers de configuration de Nagios :

En Français :

http://nagios.manubulon.com/traduction/fr_2.5/index.html

En Anglais :

http://nagios.sourceforge.net/docs/2_0/

Wiki du logiciel Oreon :

http://wiki.oreon-project.org/index.php/Main_Page

Forum du logiciel Oreon :

http://forum.oreon-project.org/index.php

Nagios exchange est un site regroupant tous les plugins concernant Nagios :

http://www.nagiosexchange.org/

Différents plugins pour contrôler les bases de données Oracle :

http://www.nagiosexchange.org/Search_Projects.43.0.html?tx_netnagext_pi1%5Bphrase%5D=oracle&tx_netnagext_pi1%5Bsubmit%5D=search&tx_netnagext_pi1%5Bsearch%5D=1

---