NAGIOs / NAGVIS -...
Transcript of NAGIOs / NAGVIS -...
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
THOMAS HAEN-BOUCHER 2
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.
THOMAS HAEN-BOUCHER 3
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.
THOMAS HAEN-BOUCHER 4
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
THOMAS HAEN-BOUCHER 5
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 :
THOMAS HAEN-BOUCHER 6
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.
THOMAS HAEN-BOUCHER 7
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.
THOMAS HAEN-BOUCHER 8
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 :
THOMAS HAEN-BOUCHER 9
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.
THOMAS HAEN-BOUCHER 10
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.
THOMAS HAEN-BOUCHER 11
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 ?
THOMAS HAEN-BOUCHER 12
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 :
THOMAS HAEN-BOUCHER 13
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.
THOMAS HAEN-BOUCHER 14
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é.
THOMAS HAEN-BOUCHER 15
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) :
THOMAS HAEN-BOUCHER 16
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
THOMAS HAEN-BOUCHER 17
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)
THOMAS HAEN-BOUCHER 18
THOMAS HAEN-BOUCHER 19
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.
THOMAS HAEN-BOUCHER 20
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.
THOMAS HAEN-BOUCHER 21
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.
THOMAS HAEN-BOUCHER 22
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 :
THOMAS HAEN-BOUCHER 23
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)
THOMAS HAEN-BOUCHER 24
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 :
THOMAS HAEN-BOUCHER 25
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 :
THOMAS HAEN-BOUCHER 26
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 ».
THOMAS HAEN-BOUCHER 27
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 »
THOMAS HAEN-BOUCHER 28
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.
THOMAS HAEN-BOUCHER 29
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.
THOMAS HAEN-BOUCHER 30
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.
THOMAS HAEN-BOUCHER 31
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.
THOMAS HAEN-BOUCHER 32
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.
THOMAS HAEN-BOUCHER 33
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
THOMAS HAEN-BOUCHER 34
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.
THOMAS HAEN-BOUCHER 35
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.
THOMAS HAEN-BOUCHER 36
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.