NAGIOs / NAGVIS - thomashaenboucher.weebly.comthomashaenboucher.weebly.com/uploads/2/6/4/8/26486257/procédure... · - Configuration et compréhension des relations de fichiers Nagios

BTS SIO

NAGIOS / NAGVIS Serveur de supervision

Thomas Haën-Boucher

THOMAS HAEN-BOUCHER 1

Table des matières

I/ FAN: Fully Automated Nagios .............................................................................................................. 2

II/ Les fichiers de configuration de Nagios .............................................................................................. 3

III/ L’héritage ........................................................................................................................................... 9

IV/ Plugin : du service à la commande .................................................................................................. 12

V/ NSClient++ ........................................................................................................................................ 17

VI/ Application : création de nouveaux hôtes ....................................................................................... 19

VII/ Périodes et stratégies de notification ............................................................................................. 23

VIII/ Relations parents/enfants ............................................................................................................. 24

IX/ NAGVIS ............................................................................................................................................. 24

A/ Créer une carte ............................................................................................................................. 25

B/ Ajouter des hôtes et services ........................................................................................................ 28

C/ Importer ses propres modèles : icônes et figures ........................................................................ 33

1/ Ajout d’un fond de carte ........................................................................................................... 33

2/ Astuce à la création ................................................................................................................... 33

3/ Ajout de figures ......................................................................................................................... 34

4/ Ajout d’icônes ........................................................................................................................... 34

D/ Résultat ..................................................................................................................................... 35

X/ Postfix ............................................................................................................................................... 35


I/ FAN: Fully Automated Nagios

Wikipedia:

« FAN est une distribution GNU/Linux basée sur la distribution CentOS. Son objectif est de

fournir une installation de Nagios garnie de tous les outils que met à disposition la

communauté Nagios. FAN est distribué sous forme d'image disque. »

Nagios est un outil de supervision réseau. Concrètement Nagios affiche sur son interface

web des éléments supervisés (serveurs, routeurs/switch, imprimantes etc…) ainsi que l’état des

services sur chacun d’eux. Nagios permet également une gestion avancée des groupes de contact et

des notifications.

FAN comprend quatre outils :

- Nagios : le moteur de récupération des informations

- Centreon : la couche application qui exploite les données de Nagios et les présente sur

une interface web simplifiée (configurations au travers d’une GUI, consultation sous

forme de graphique etc…)

- NAGVIS : une autre couche application qui permet de créer des cartes de manière

intuitive.

- Dokuwiki : Wiki complet sur les fonctionnalités de FAN (en anglais)

Il est possible d’installer ces outils indépendamment les uns des autres mais de nombreuses

lignes de commandes seront nécessaires à l’installation, la configuration et la liaison de ces outils.

Au-delà de l’automatisation de ces étapes, FAN inclus nativement de nombreux plugins ainsi

que des outils complémentaires très utiles.

Cette procédure ne porte pas sur l’installation du serveur de supervision Nagios : il suffit

d’installer FAN (FAN.iso) sur un serveur (physique / virtuel) et de fixer son adressage IP. Il ne reste

alors qu’à entrer l’adresse IP du serveur dans un navigateur pour accéder à l’interface web de FAN.

L’identifiant et le mot de passe par défaut pour accéder aux outils FAN sont : nagiosadmin

Sont abordés ici les éléments suivants :

- Configuration et compréhension des relations de fichiers Nagios

- Présentation de Nagvis

- Configuration de Postfix

J’utiliserai les outils WinSCP et Putty, l’un afin de cerner le système de fichier, l’autre pour

exécuter la commande de vérification : # nagios /etc/nagios/nagios.cfg. Nous y reviendrons.

Enfin, je fais le choix de ne pas inclure Centreon car cet outil sera relativement facile à prendre en

main si le fonctionnement de Nagios est bien compris. Il mérite une procédure à lui seul.


II/ Les fichiers de configuration de Nagios

Nagios fonctionne à travers la définition d’objets. Voici la liste des objets que l’on peut/doit définir :

- Host : Equipement à superviser (serveur, routeur, imprimante etc…)

- Hostgroup : Groupe d’hôtes

- Service : Service « supervisable » (HTTP, SSH, PING etc…)

- Servicegroup : Groupe de services

- Contact : « Superviseurs »

- Contactgroup : Groupe de «superviseurs»

- Command : Commandes sur lesquelles s’appuient les services

- Timeperiods : Périodes (24x7, 09:00-17:00 etc…)

Afin de superviser, Nagios s’appuie sur plusieurs fichiers de configuration d’objets dont la

compréhension du fonctionnement constitue la clé d’une bonne maitrise de l’outil.

Ces fichiers se trouvent ici : /etc/nagios/

Le premier fichier que Nagios consultera pour charger sa configuration est : nagios.cfg

On retrouve l’extension *.cfg à chaque fichier de configuration.

Ouvrons-le avec NotePad++. La numérotation des lignes sera très utile lors de la vérification

d’éventuelles erreurs de configuration.


Les lignes précédées d’un « # » sont des commentaires qui ne seront pas pris en compte lors de

l’exécution de ce fichier de configuration. Si j’isole uniquement les lignes dé-commentées, cela

donne alors :

log_file=/var/log/nagios/nagios.log

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

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

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

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

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


La ligne log_file contient le chemin vers le fichier de log, qui lui-même contient les logs (historique

des activités Nagios).

Les lignes cfg_file correspondent aux chemins de fichiers que Nagios va prendre en compte dans son

exécution.

Au premier démarrage de Nagios, un seul équipement (hôte) est supervisé : localhost, c’est-

à-dire Nagios lui-même.

On constate alors qu’il existe dans nagios.cfg, un chemin vers un autre fichier de configuration :

/etc/nagios/objects/localhost.cfg

Ouvrons-le :


Ce fichier contient plusieurs « parties » séparées par une série du caractère de commentaire « # »

La première partie explique le contenu du fichier de configuration, chose que je vais faire

maintenant.

La seconde est titrée : HOST DEFINITION ou définition d’hôte. C’est donc à cet endroit qu’est défini

l’hôte localhost (le serveur Nagios lui-même). Pour définir un hôte, il suffit donc de respecter le

format suivant :

Define host {

Host_name Nom_de_l’_hôte

Address @_IP_de_l’_hôte

}

La commande use (capture écran précédente) indique à Nagios que l’hôte défini, hérite des

caractéristiques d’un autre hôte : linux-server. Nous allons revenir en détail sur cette notion

d’héritage qui est la base du fonctionnement de Nagios.

La commande alias parle d’elle-même. Elle correspond à une très courte description de l’hôte.

Exemple : Hostname = Serveur-Web ; Alias = Serveur Web IIS 192.168.0.1

Dans Nagios, toute définition commence par l’instruction define. Seul ce qui se trouve

derrière define différenciera ce qui est défini : host (hôte), hostgroup (groupe d’hotes), service,

servicegroup, command, contact, contactgroup ou timeperiod.

La troisième partie de localhost.cfg est : HOST GROUP DEFINITION ou définition d’un groupe d’hôte

Notion de groupe : Un hôte peut faire partie d’un ou de plusieurs groupe(s) d’hôtes, un service d’un

groupe de services et un contact d’un groupe de contacts. Cela simplifie la configuration de ce qu’on

désire superviser.

Exemple : On souhaite superviser (remonter l’information sur l’interface Nagios) la version d’un

logiciel installé sur tous les serveurs Windows. On a préalablement défini chaque hôte en respectant

le format précité. Ces informations sont écrites (pour le moment) dans un seul fichier dont

l’extension est *.cfg et qui est déclaré dans nagios.cfg (comme déjà expliqué).

REMARQUE : à cette étape il n’est pas nécessaire de comprendre le contenu de ce qui suit. Seule

l’idée générale est à acquérir.


En rouge, une définition de service appliquée à chaque hôte un par un : il y aura donc autant

de déclaration de ce service qu’il n’y a d’hôte. Il est absolument exclu de recourir à cette méthode

très inefficace et impraticable (services trop nombreux).

En vert, les hôtes sont d’abord définis dans un groupe et le service n’est déclaré qu’une seule

fois en pointant sur le groupe et plus sur un seul hôte.

Cet exemple de gestion des hôtes par groupe s’applique également aux services et aux

contacts. La gestion de groupe d’hôtes, de groupe de services et de groupe de contacts simplifie la

gestion et la configuration de la supervision.


Pour démontrer l’utilité de créer des groupes, revenons maintenant dans le fichier

localhost.cfg à la troisième partie : HOST GROUP DEFINITION.

Il existe donc un groupe linux-servers contenant: localhost uniquement ! Lorsqu‘on définira un

nouvel hôte (un serveur linux en toute logique), il suffira d’ajouter son hostname dans les members

de cette définition de groupe afin qu’il en fasse partie.

A l’installation de FAN, seul le serveur FAN est supervisé et on le constate en regardant ce

« mauvais » exemple : un service est défini uniquement pour localhost. Nous pourrions modifier ce

service et remplacer :


define service{

use local-service ; Name of service template to use

host_name localhost

service_description PING

check_command check_ping!100.0,20%!500.0,60%

}

PAR

define service{

use local-service ; Name of service template to use

hostgroup_name linux-servers

service_description PING

check_command check_ping!100.0,20%!500.0,60%

}

Ainsi les services pointant sur le hostgroup linux-servers seront supervisés sur chaque hôte du

groupe.

III/ L’héritage

Revenons maintenant sur la commande use que l’on a observée dans la deuxième partie du fichier de

configuration localhost.cfg :

use linux-server

; Name of host template to use. This host definition will inherit all variables that are defined in (or

inherited by) the linux-server host template definition.

La virgule est un caractère qui permet de faire des commentaires dans une définition.

Tentons une traduction: Nom du modèle à utiliser. Cette définition d’hôte héritera de toutes les

variables définies dans le modèle de définition linux-server.

Tout ce qui est écrit dans la définition d’hôte linux-server s’appliquera donc aussi à localhost.

On comprend que linux-server est un modèle, une template.


On va donc regarder ce qui s’y trouve en ouvrant le fichier des templates :

/etc/nagios/objects/templates.cfg

Ici encore, le fichier de configuration est divisé en plusieurs « parties ». On repère celle qui

nous intéresse maintenant : HOST TEMPLATES et particulièrement linux-server

La première variable est name. On l’a vu, une définition d’hôte doit respecter un format

particulier (define host {infos … info2 … etc…} ).

Il existe une différence subtile entre la définition d’un hôte de base et la définition d’une

template : le premier doit être déclaré par un host_name et le second seulement par un name.

La seconde variable est… use ! Cela signifie que linux-server hérite à son tour de toutes les variables

définies dans l’hôte generic-host.

Reprenons : localhost hérite de linux-server qui hérite de generic-host !

localhost hérite donc de generic-host.


Cette cascade d’héritage s’explique simplement : certaines variables sont communes à tous

les hôtes. D’autres ne s’appliquent qu’à un ou plusieurs types d’hôtes sans que tous soient

concernés.

Pour comprendre, regardons maintenant le contenu de la template generic-host :

Cette template se trouve juste au-dessus de linux-server dans le fichier des templates :

templates.cfg

La variable notifications_enabled correspond à l’activation ou non des notifications

concernant un hôte. Par exemple, est-ce que je souhaite être notifié si l’hôte concerné n’est plus

joignable sur le réseau ? (le chapitre VI est consacré aux stratégies de notification)

Ici, la variable est à 1 ce qui signifie que tous les hôtes héritant de cette template notifieront

leur état.

Generic-host porte alors bien son nom : ce modèle, générique, peut aussi bien concerner un

serveur linux, qu’un serveur windows, un routeur, un switch, une imprimante etc…

Revenons maintenant à la définition de la template linux-server.

Pourquoi définir un modèle spécifique aux serveurs linux ?


Il existe autant de raison que de politiques différentes en matière de supervision. Par

exemple, on pourrait spécifier une variable contact-group qui viserait à ne notifier que des

« superviseurs » qualifiés pour intervenir sur des serveurs linux.

Conclusion : Nagios est un outil très flexible puisqu’il autorise toute sorte de cascade

d’héritage. On peut créer autant de template que l’on désire. Il est très important de donner des

noms évocateurs aux templates pour s’y retrouver facilement. Le choix d’organisation des fichiers de

configuration est propre à chacun, le seul impératif étant d’ajouter le chemin de ces fichiers à

nagios.cfg.

IV/ Plugin : du service à la commande

Avant de commencer à manipuler, voyons le fonctionnement des plugins et d’abord ce qu’est

un plugin.

Le plugin est la base de la supervision : sans lui, il est impossible d’obtenir les informations

des hôtes.

Les plugins Nagios sont présents ici : /usr/lib/nagios/plugins

Nagios connait l’emplacement de ces plugins grâce au fichier resource.cfg qu’il sait consulter

puisque le chemin de celui-ci est renseigné dans nagios.cfg :

Il est donc facile de changer l’emplacement des plugins en prenant soin de renseigner le

nouveau chemin dans ce fichier de configuration.

Ouvrons resource.cfg :


On constate que le chemin du dossier des plugins est enregistré dans la variable $USER1$.

Reprenons maintenant notre fichier localhost.cfg. En milieu de fichier, se trouve la

déclaration de service suivante :

On voit que cette définition de service hérite de la template local-service. Celle-ci n’est pas

utile à la compréhension du service.


La ligne check_command nous intéresse ici. Cette ligne est présente dans toutes les

définitions de service sans laquelle la définition n’est pas valable.

Check_command appel check_ping.

Après check_ping, se trouvent des arguments séparés par des “!”. Des détails et des exemples sur ces

arguments sont disponibles en exécutant la commande :

#./check_plugin - -help

Dans le dossier des plugins.

Un service appel donc systématiquement une commande.

Allons donc voir la commande check_ping dans le fichier de configuration des commandes :

Ce fichier contient un grand nombre de commande. On retrouve rapidement celle qui nous

concerne par une recherche (ctrl+f) sur check_ping.

La commande check_ping exécute donc la ligne de commande :

command_line $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5

On retrouve ici la variable $USER1$ qui contient le chemin vers le dossier des plugins.

- La variable d’environnement $HOSTADDRESS$ sera remplacée par l’adresse IP de l’hôte

concerné

- la variable $ARG1$ sera remplacée par le premier argument défini dans le service

associé.

- la variable $ARG2$ sera remplacée par le second argument défini dans le service associé.


Si on reprend la définition du service check_ping,

On comprend que :

$ARG1$ sera remplacé par 100.0,20%

$ARG2$ sera remplacé par 500.0,60%

L’important est ici de comprendre que c’est bien la même commande qui est appelée par les

hôtes concernés mais avec des valeurs ($hostadress$) propres à chacun d’eux à chaque fois.

Voici un lien pour plus de détails sur la manière dont Nagios résout les variables, qui sont en

fait des macros :

http://doc.monitoring-fr.org/3_0/html/thebasics-macros.html

Nous allons maintenant tester la command_line sur le serveur Nagios (par une connexion SSH

grâce à Putty). Pour cela on a besoin de la définition du service (pour récupérer la valeur des

arguments) et de la définition de commande (pour récupérer les lettres des arguments) :

http://doc.monitoring-fr.org/3_0/html/thebasics-macros.html


A la racine de notre serveur Nagios, on peut donc écrire :

/usr/lib/nagios/plugins/check_ping –H 127.0.0.1 –w 100.0,20% -c 500.0 ;60% -p 5

Le plugin check_ping fonctionne correctement.

Affichons maintenant la liste de tous les plugins :

Il existe deux moyens de connaître le fonctionnement d’un plugin en particulier (comment

utiliser quels arguments)

- Dans ce dossier des plugins, exécuter la commande : ./check_plugin - -help

- Sur l’interface web de FAN : Dokuwiki/Nagios plugins documentation

http://@IP_FAN/dokuwiki/doku.php?id=plugins:start

http://@IP_FAN/dokuwiki/doku.php?id=plugins:start


V/ NSClient++

NSClient++ est un outil qui fonctionne sur la relation client serveur :

- Check_nt = le plugin Nagios

- NSClient++ = l’agent à installer sur chaque serveur à superviser

Il est dédié à la supervision de serveurs Windows (présent dans l’installation FAN). Les

variables et quelques exemples sont disponibles ici :

« http://X.X.X.X/dokuwiki/doku.php?id=plugins:check_nt »

Ces quelques captures résument l’installation de l’agent NSClient++ qu’il suffit de télécharger sur le

site de l’éditeur. ATTENTION : un client différent sera peut être nécessaire pour certaine versions de

Windows serveur (plus anciennes)



VI/ Application : création de nouveaux hôtes

Nous avons « dégrossi » le travail de compréhension, cernons maintenant le fonctionnement

de Nagios par l’exemple.

FAN propose des templates qui constituent un bon départ pour se « faire la main » :

- localhost.cfg

- printer.cfg

- switch.cfg

- windows.cfg

Rappelons que ces templates contiennent des définitions de service qui pointent sur des

commandes du fichier commands.cgf. Il est bien sûr possible d’ajouter / créer des services à

condition que ceux-ci pointent sur une définition de commande et celle-ci sur le plugin

correspondant.

Ces templates (sauf localhost) sont commentées par défaut dans le fichier nagios.cfg : elles

ne sont pas exécutées par Nagios.

Il est plus prudent de copier et renommer ces templates avant de les modifier et de les

adapter. Cela permet de les réutiliser si trop de modifications ont pollué le modèle.

Il faudra ensuite les déclarer dans nagios.cfg

La commande cfg_file indique à Nagios qu’il doit exécuter un fichier en particulier.

La commande cfg_dir indique à Nagios d’exécuter tous les *.cfg du dossier pointé.

Ici, Nagios exécutera tous les fichiers de configuration présents dans le dossier Mes_objets.


Ouvrons-le :

J’ai copié les templates du dossier par défaut objects que j’ai renommées et modifiées.

Par exemple, le fichier Serveurs-Linux.cfg est une copie du fichier objects/localhost.cfg. J’ai

simplement ajouté des déclarations d’hôte, créé un nouveau groupe d’hôte et appliqué les

déclarations de service à ce groupe comme expliqué dans le chapitre précédent.

IMPORTANT : Après avoir modifié des fichiers de configuration, il est indispensable d’exécuter deux

commandes :

# nagios –v /etc/nagios/nagios.cfg les modifications sont acceptées OU il y a des erreurs

# service nagios restart redémarrage de Nagios pour la prise en compte des modifications

Avec la première commande, le succès des vérifications (série de « check ») se solde par le

message :

Cette commande présente un réel intérêt lorsqu’il y a un problème de configuration : elle

permet de cibler l’erreur.

Exemple : je défini un hostgroup « Serveurs-Linux » dans le fichier de configuration

Mes_objets/Serveur-Linux.cfg

Le nom du fichier de configuration et le nom du hostgroup sont les mêmes à une lettre prêt : l’erreur

est possible.


Je fais volontairement l’erreur d’oublier le « s » de Serveurs dans le hostgroup_name de ma

déclaration de service check_ping.

La commande # nagios –v /etc/nagios/nagios.cfg me renvoi :

Le problème est correctement ciblé. Je corrige mon erreur.

Allons maintenant voir si mes hôtes sont correctement supervisés sur l’interface web Nagios.


Les hôtes sont correctement supervisés. Remarque : mon Serveur-Sophos-AV n’accepte pas les

connexions SSH.

Signifie que les notifications sur ce service ne sont pas activées. Un prochain chapitre

aborde la notion de notification et d’alerte.

Voici un schéma synthétisant les relations entre « objets » Nagios. Mon premier fichier est

windows.cfg

Control + Clic droit pour zoomer :

relations Nagios.png


Cette configuration n’est qu’un exemple de la manière dont il possible d’organiser sa

supervision. Il serait possible de créer un fichier de configuration pour chaque hôte en définissant

plus de variables au même endroit. Cela rend l’utilisation de template inutile et la supervision

difficile.

A l’inverse, il serait possible de créer un fichier de configuration ne contenant que les hôtes, un

autre ne contenant que les groupes d’hôtes, un autre encore que les services, les groupes de

services, les contacts, les groupes de contact etc…

VII/ Périodes et stratégies de notification

Nagios inclus une gestion de période de temps qui permet de définir à quel moment une

action est à mener.

Reprenons la template linux-server sur laquelle se base l’hôte localhost.

Check_period = périodes que Nagios respecte pour exécuter une supervision.

Check_interval = localhost sera supervisé toutes les 5 minutes.

Retry_intervel = Nagios arrive au bout de 5 minutes, il exécute une nouvelle supervision.

Problème : l’information ne remonte pas sur le serveur. Nagios réessayera 1 minute plus tard.

Max_check_attempts = Nagios réessayera de remonter l’information 10 fois de suite. Sans

succès, le statut OK changera en Warning Unknow Critical Recovery ou Down.

Notification_period = L’hôte concerné hérite de la définition timeperiod workhours. Celle-ci

se trouve dans le fichier de configuration timeperiods.cfg. Cette définition correspond aux horaires

de travail d’une entreprise. En résumé, Nagios n’enverra de notification que sur les heures de travail

indiquées.

Notification_interval = Temps entre 2 notifications.

Notification_options = Nagios n’enverra de notification que pour les états définis ici (d =

downtime / u = unreachable / r = recovery)


Stratégies de notification : Une supervision efficace passe par de véritables stratégies de notification.

Les notifications doivent alerter le ou les superviseurs de manière efficace. Une avalanche de

notification noiera l’alerte réellement importante. Il est indispensable de limiter les alertes aux hôtes

et aux services « critiques ».

Recevoir une notification alertant sur la quantité insuffisante d’encre noire dans le toner du

copieur X est bien moins inquiétant qu’une alerte sur l’état du port WAN d’un routeur sur lequel

repose la connexion internet d’une entreprise.

VIII/ Relations parents/enfants

Le chapitre n°34 de la documentation Nagios sur le site doc.monitoring-fr.org explique et

illustre parfaitement les enjeux d’une bonne gestion des relations parents / enfants.

Pour résumer la commande parents (à utiliser dans les définitions d’hôtes) permet de décrire

l’emplacement géographique des équipements réseaux afin d’éviter les cascades de notifications.

Exemple :

Un serveur se trouve derrière un routeur. Si le routeur tombe il est évident que ce serveur ne

sera plus joignable. Pour autant cela ne veut pas dire que ce serveur est tombé : il n’est pas down

mais unreachable ce qui change le comportement de Nagios lors des notifications.

http://doc.monitoring-fr.org/3_0/html/thebasics-networkreachability.html

IX/ NAGVIS

NagVis est un addon de visualisation pour Nagios qui permet de générer des

cartes modélisant les objets de supervision (hôtes et services)

NAGVIS est installé et lié automatiquement à Nagios par la distribution FAN. Ouvrons-le :

http://doc.monitoring-fr.org/3_0/html/thebasics-networkreachability.html


La page d’accueil présente peu d’intérêt : elle propose des démonstrations de ce qu’il est possible de

mettre en place.

A/ Créer une carte Entrons dans le vif du sujet et créons notre première carte :


Après avoir nommé notre nouvelle carte, il faut choisir dans la liste « Icônes de la carte »

notre modèle d’icône : un modèle correspond à une série d’icônes qui se mettront à jour, par

exemple, suivant l’état d’un hôte ou d’un service. Il est possible d’ajouter un modèle d’icone, nous y

reviendrons plus tard.

Enfin, il suffit de choisir un modèle de carte dans la liste qui correspond puis cliquer sur

« créer ».


ATTENTION

Si vous venez de choisir le même nom de carte que moi « Ma_première_carte » vous vous

rendez compte que Nagvis retourne une erreur. Il convient d’éviter les caractères spéciaux. Je

préfère donc nommer celle-ci : « macarte ».

Ca y est, notre carte est créée. J’ai choisis le fond de carte de démonstration « demo-

germany.png »


B/ Ajouter des hôtes et services

Il existe deux modes Nagvis : la vue normale et le mode édition. Celui-ci nous intéresse pour

ajouter des objets Nagios. Pour passer en mode édition il suffit de :

Parmi les fonctionnalités de ce menu d’édition, trois nous intéresses :

- Ajouter une icône

- Ajouter une ligne

- Ajouter un objet spécial

Les deux premières options proposent le même sous menu :

On décide d’ « ajouter une icône » et de sélectionner « host ». Notre curseur change en

pointeur afin de créer l’icône à l’endroit désiré sur la carte.


Je ne détaillerai pas les options

configurables ici, l’important étant

d’apprendre à créer une carte en lien avec

notre supervision Nagios.

Host_name nous propose un

menu déroulant recensant tous les hôtes

Nagios. Je fais le choix d’ajouter mon

routeur cisco-bata et je clique sur

sauvegarder.

Après le rafraichissement

automatique de la page, une icône et le

mode édition apparaissent. Il suffit

d’ajouter un seul objet pour que le mode

édition se manifeste.

En mode édition, les détails de supervision ne s’affichent pas. Il suffit de tout « bloquer »

comme vu ci-dessus, puis de passer le curseur sur notre nouvelle icone pour afficher le détail de la

supervision.


Maintenant que je sais le faire, j’ajoute une seconde icône symbolisant mon second routeur

(cisco-batb).

Nous allons maintenant créer une ligne « Hostgroup » reliant nos deux routeurs.

Il faut cliquer à deux endroits différents pour tracer la ligne.

N’essayer pas de cliquer sur les deux icones que l’on vient de créer dans le but de tracer une

ligne d’un routeur à l’autre, ça ne fonctionne pas. Il suffira de redimensionner et déplacer notre ligne

après sa création.


Cette fenêtre apparait et de la même manière, je sélectionne mon groupe dans le menu

déroulant « Hostgroup_name » et je sauvegarde :

Après avoir créé une ligne, Nagvis quitte le

mode édition.

Il suffit d’y retourner (Editer la carte > Tout

bloquer/débloquer)

On peut alors redimensionner et déplacer

notre ligne.

La ligne apparait en rouge ! Il y a donc

certainement des services « critical » dans

mon groupe d’hôtes Serveurs-Windows. Un

clic sur la ligne me donnera accès aux détails

de supervision.


Ajoutons maintenant un objet spécial de type figure :

Après avoir déterminé sa position sur la carte, déroulez le menu icon

Par défaut, vous n’avez pas les deux premières propositions qui sont des figures que j’ai

rajoutées, nous y venons juste après. Choisissez donc demo-nagvis-sponsor.png et sauvegardez.

Vous venez d’ajouter un encart qui ne réagit pas au passage de la souris (en mode normal).

Vous l’avez compris : ajouter une icône ou une ligne permet d’ajouter un objet sur la carte en

lien direct avec la supervision. Un objet spécial n’a pas de lien direct avec la supervision et peut

correspondre par exemple à la photo d’un équipement.


C/ Importer ses propres modèles : icônes et figures

Dans Nagvis les cartes, les icônes et les figures sont au format PNG. Ces images se trouvent

dans le dossier :

Astuce : Dans sa version 5.5.6 WinSCP ne permet pas d’afficher les images. Je préfère exporter le

dossier entier « images » vers mon disque dur local afin de travailler avec la vue « icône ».

J’appliquerai mes changements en important ce même dossier à sa place sur le serveur en

choisissant l’option « remplacer ».

1/ Ajout d’un fond de carte Ouvrons maps : les fonds de carte.

2/ Astuce à la création Afin de formater ma nouvelle carte à la bonne taille, je peux copier-coller-renommer une

map existante et respecter le format lors de l’édition (sous Paint par exemple).

Ici je modélise les bâtiments de Laval Mayenne Technopole en carrés. Je renomme mon fond de

carte lmt.png


3/ Ajout de figures On l’a vu, les figures ne sont pas en lien direct avec la supervision : ce ne sont que des

images, photos etc.. Inertes. Ils sont très utiles couplés avec un modèle d’icône, nous y reviendrons

dans un instant.

Dans le dossier shapes j’ajoute une photo de routeur Cisco et une photo de copieur.

4/ Ajout d’icônes

L’ajout d’icônes est plus délicat. Les icônes sont en lien avec la supervision Nagios : elles

doivent se succéder dynamiquement en fonction des changements d’état d’hôte ou de service.

Concrètement, une icône verte me rassure, une icône rouge me donne une alerte visuelle.


Si l’ajout de modèle d’icônes est délicat c’est parce qu’il nécessite de suivre une logique

particulière : le nombre et le nom doivent être respectés.

Je ne m’étends pas sur l’ajout de modèles d’icônes, les modèles par défauts fournissent déjà

de bons résultats à l’affichage.

D/ Résultat

Après avoir rechargé le dossier images à sa place sur le serveur, les nouvelles images seront

disponible sur l’interface web Nagvis.

Nagvis permet d’obtenir une cartographie pertinente de manière intuitive. A la fin de cette

courte présentation j’arrive à ce résultat :

X/ Postfix

FAN inclus l’installation de Postfix. Cet outil permet l’envoi de notifications vers un

serveur de messagerie. A la LMT il s’agit d’un serveur exchange. La configuration de

postfix est dans ce cas assez simple. Il convient de modifier trois paramètres dans le

fichier de configuration main.cfg.


myhostname

Le nom du myhostname doit être équivalent au nom de votre machine (nom qu’on retrouve

dans /etc/hosts ou /etc/hostname). Pas mal de serveur de messagerie auront des règles de

vérification et de mise au rebus de mails véreux. Il vaut mieux mettre votre nom de domaine en

complément du nom machine comme l’exemple ci-dessous:

Notre machine s’appelle “serveur-nagios” Le domaine de notre société est laval-technopole.fr Le

myhostname devra être: myhostname = serveur-nagios.laval-technopole.fr

mydestination

Le mydestination doit être identique au myhostname. En aucun cas c’est 2 valeurs ne doivent

être différentes car ça ne fonctionnera pas ou plus.

Le mydestination devra être: mydestination = serveur-nagios.laval-technopole.fr

relayhost

Le relayhost sert à renseigner l’IP ou le nom DNS du serveur de messagerie utilisé pour router

votre courrier.

Documents

NAGIOs / NAGVIS - thomashaenboucher.weebly.comthomashaenboucher.weebly.com/uploads/2/6/4/8/26486257/procédure... · - Configuration et compréhension des relations de fichiers Nagios