NAGIOS v1.0

Transcription

NAGIOS v1.0

Rectorat de l'Académie de Nancy-Metz
NAGIOS v1.0
Version
Date
Opérations et Commentaires
V1.0
15/01/03
1ère version officielle du document.
Nom
Fonction
Laurent LE PRIEUR
Responsable du pôle de compétences Supervision
Eric SENET
Technicien
Nagios – Racvision v1.0
Page 1/16
NAGIOS v1.0
Concepts :
Nagios est un logiciel de supervision des réseaux. Ou peut-être plus exactement, c'est un logiciel de
supervision des systèmes. Il supervise des hôtes et des services (vous alertant quand les choses se
passent mal), mais ne fait pas d'analyse de trafic, de capture de paquets, etc...
Nagios (ex NetSaint) a été conçu à l'origine pour fonctionner sous Linux, mais il devrait fonctionner sous la
plupart des autres unix également.
Nous avons choisi le système GNU LINUX pour RACVISION.
Voici quelques-unes des nombreuses fonctionnalités de Nagios :
Supervision de services réseau (SMTP, POP3, HTTP, NNTP, PING, etc.)
Supervision des ressources des hôtes (charge du processeur, utilisation du disque, etc.)
Système de plugins simple permettant des développements "maison" faciles
Contrôle parallélisé des services
Possibilité de définir une hiérarchie dans les hôtes grâce aux hôtes "parents", permettant la
détection et la distinction entre les hôtes en panne et ceux qui ne sont plus accessibles
Notifications à des contacts de l'apparition ou de la disparition de problèmes sur les hôtes ou les
services (via email, pager, ou toute méthode définie par l'utilisateur)
Possibilité de définir des gestionnaires d'événements qui sont lancés automatiquement lors de
l'apparition d'événements concernant les hôtes ou les services, pour une résolution préventive des
problèmes
Rotation automatique des fichiers journaux
Support de la supervision redondante
Interface web optionnelle pour visualiser l'état du réseau, les notifications et l'historique des
problèmes, les fichiers journaux, etc.
Nagios n'est pas...
Un gestionnaire SNMP
Un outil d'évaluation des vulnérabilités de sécurité
Le site web de référence de NAGIOS est : http://www.nagios.org
Ce document ne se veut pas être une documentation complète du logiciel mais un guide
d'accompagnement dans la mise en œuvre de Nagios sur RACVISION.
Il permet aux équipes systèmes ayant mis en œuvre un serveur RACVISION de mettre facilement en
production leur dispositf d'alertes.
Si nous le pouvons, nous contribuerons à Nagios en traduisant en français la documentation anglaise...
Page 2/16
Fonctionnement :
L’application utilise un binaire (nagios) lancé en tant que daemon ou service pour la partie exécution des
commandes de surveillance et des pages web Cgi pour l’interface graphique. Les commandes de
surveillance existent sous 2 formats, des binaires issus d’une compilation de fichier C, que l’on trouvera
principalement sur la machine Racvision, ou des scripts Perl pour la portabilité vers d’autres OS comme
AIX, Nagios étant principalement développé de base pour un environnement Linux.
Certains services ne peuvent être surveillés qu’en local d’où l’utilisation d’un plugins intitulé Nagiosstatd
(héritage de Netsaint) décrit dans le chapitre « Installation Académique »
Nagios est installé sur racvision, seul son paramétrage est nécessaire.
Le frontal WEB est accessible à l'URL http://racvision.in.ac-académie.fr
le login/mot de passe par défaut est : admin / racvision.
Descriptif du menu :
Page 3/16
Pré-requis :
Nagios est livré/installé sur racvision. Il suffit de renseigner les services réseaux à superviser et d'installer
les agents sur les machines (remontées CPU, systèmes de fichiers, process non réseaux).
Pour pouvoir indiquer à Nagios quels serveurs, quels services surveiller, il convient d'établir un audit
exhaustif de l'académie afin de recenser l'existant.
Configuration :
Par défaut l'installation de Nagios comporte un certain nombre de serveurs et de services communs à
toutes les académies. Ces serveurs et services sont livrés à titre d'exemple.
Plusieurs services sont paramétrés de base pour Racvision, mais seule la commande check_host_alive est
utilisée pour les serveurs Mac1, Mac2, Mac3, Grh1 et Grh2.
Les répertoires d’installation ne correspondent pas à l’installation par défaut décrite dans le manuel d’origine
de Nagios pour les raisons suivantes :
utilisation d’un fichier RPM à l’installation afin de respecter la norme LFS (Linux File System)
plus grande souplesse pour les mises à jour ultérieures
Voici donc la correspondance des répertoires utilisés :
Répertoire décrit dans le manuel
Répertoire réel d'installation
/usr/local/nagios
Répertoire éclaté (voir ci-dessous)
/usr/local/nagios/etc
/etc/nagios
/usr/local/nagios/libexec
/usr/lib/nagios/plugins
/usr/local/nagios/var/log
/var/log/nagios
/usr/local/nagios/share
/usr/share/nagios
/usr/local/nagios/bin
/usr/sbin
/usr/local/nagios/bin
/usr/lib/nagios/cgi
Paramétrage (les différents fichiers) :
Nagios nécessite une partie de configuration non négligeable afin de faire fonctionner l’ensemble de la
surveillance.
Cette configuration est découpée en plusieurs fichiers significatifs par leur nom afin de simplifier les
démarches.
Le descriptif des syntaxes de ces commandes se trouvent dans la documentation en ligne sur la page
d’accueil de Nagios. Il ne sera donc pas repris dans ce chapitre. Seuls quelques exemples de déclaration de
machines seront énoncés.
Page 4/16
a) fichier /etc/nagios/nagios.cfg
Ce fichier contient les paramètres concernant le binaire nagios :
positionnement du fichier de log (nagios.log)
positionnement des fichiers de configuration (tous les fichiers .cfg)
positionnement du fichier des ressources resource.cfg
positionnement du fichier de stockage des états de matériels et services (status.log)
définition de l’utilisateur et du groupe du programme nagios
définition de l’utilisation de commandes externes avec leur intervalle d’exécution
définition du fonctionnement des fichiers d’archives
définition des surveillances à intégrer dans les logs
les temps de TimeOut pour les surveillances.
b) fichier /etc/nagios/cgi.cfg
Ce fichier contient les paramètres concernant la partie web :
positionnement du fichier principal (nagios.cfg)
positionnement du répertoire /share contenant entre autres les images pour les pages web
définition du chemin URL utilisé pour le navigateur
définition de la commande d’auto-check (nagios peut se tester lui-même)
définition du mode d’authentification
définition des droits pour différents utilisateurs
définition de l’image de fond utilisé dans les status map 2D et 3D
définition du temps de rafraîchissement des pages web
définition des sons désirés pour les alertes
positionnement des fichiers pour la status map (hostextinfo.cfg et serviceextinfo.cfg)
c) fichier /etc/nagios/resource.cfg
Ce fichier contient les définitions des variables globales utilisées dans la définition des commandes
déclarées essentiellement dans le fichier checkcommand.cfg :
Ex : $USER1$=/usr/local/nagios/libexec
$USER2$=/tmp/essai/mescommandes
Page 5/16
d) fichier /etc/nagios/contacts.cfg
Ce fichier contient la déclaration, en mode objet, des contacts de notification.
Il permet d’indiquer pour un contact à quelle moment (timeperiods.cfg) il doit recevoir les notifications, par
quel moyen et sur quel critère (warning, unknown, critical et/ou recovery).
Exemple :
# 'cigal' contact definition
define contact{
contact_name
dsi
alias
Administrateurs DSI
service_notification_period
24x7
host_notification_period
24x7
service_notification_options
w,u,c,r
host_notification_options
d,u,r
service_notification_commands
notify-by-email
host_notification_commands
host-notify-by-email
email
[email protected]
}
e) fichier /etc/nagios/contactgroups.cfg
Ce fichier permet d’associer les contacts à un ou plusieurs groupes d’utilisateurs afin de cibler les
notifications par groupe de matériel. Par conséquent, un contact peut faire partie de plusieurs groupes
différents. On pourra par exemple créer des groupes pour les routeurs, un autre pour les serveurs Linux, un
autre pour les serveurs AIX, etc… Ce qui permettra de cibler les notifications par rapport aux compétences
des contacts.
# 'aix-admins' contact group definition
define contactgroup {
contactgroup_name
aix-admins
alias
Administrateur Serveurs AIX
members
dsi
}
f) fichier /etc/nagios/checkscommands.cfg
Ce fichier contient la déclaration des commandes qui seront utilisées pour surveiller les matériels ou
services.
Une commande se déclare par un alias et sa ligne d’exécution.
On peut soit utiliser le chemin absolu pour arriver au script ou binaire de la commande, soit utilisé les
variables prédéfinies dans le fichier resource.cfg ($USER1$).
Les commandes sont à définit avec des paramètres tels que l’adresse IP de l’hôte, le taux de warning et le
taux critique, paramètres définis sous forme de variables globales afin de généraliser la commande à
plusieurs services différents.
Page 6/16
Certaines commandes nécessitent des arguments supplémentaires. Pour les vérifier, il suffit d’exécuter, au
prompt, la commande incriminée avec l’option (-h ou --help) pour lister les paramètres attendus.
Exemple : (l’argument au moment de l’appel de la commande étant pour ce cas le port sur lequel le serveur
HTTP est à l’écoute).
# 'check_http' command definition
define command{
command_name
command_line
check_http
$USER1$/check_http $HOSTADDRESS$ -p $ARG1$
}
g) fichier /etc/nagios/misccommands.cfg
Ce fichier sert principalement à déclarer les commandes de notifications avec la méthode employée (mail,
pager, udp,…).
Exemple : (l’argument au moment de l’appel de la commande étant pour ce cas le port sur lequel le serveur
HTTP est à l’écoute).
# 'notify-by-email' command definition
define command{
command_name
notify-by-email
command_line
/bin/echo -e '***** Nagios ***** \n\nNotification
Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress:
$HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $DATETIME$\n\nAdditional
Info:\n\n$OUTPUT$' | /bin/mail -s '** $NOTIFICATIONTYPE$ alert $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **' $CONTACTEMAIL$
}
Dans cet exemple, on notifie une alerte par E-Mail en précisant le type (warning, recovery,…), le service qui
incombe et son hôte, l’état du service et la date de notification.
h) fichier /etc/nagios/hosts.cfg
Ce fichier contient la déclaration des matériels à surveiller.
On y trouve principalement son nom et son alias, son adresse IP, l’hôte parent auquel il est rattaché (ex : un
switch est parent d’un serveur. Ceci permet de faire le lien dans la status map et d’avoir une vue
d’ensemble graphique de toutes les machines reliées à un switch), la commande permettant de voir s’il est
actif (généralement la commande chech_host_alive est utilisée qui est un ping avec 1 seul retour) et les
options de notifications (méthode, période et intervalle).
Page 7/16
i) fichier /etc/nagios/hostgroups.cfg
Ce fichier permet d’associer les matériels à un groupe généraliste. Par exemple, on créera un groupe
«Serveur Linux», un groupe «Serveur AIX», un groupe «Serveur NT» dans lequel on déclarera les hôtes
membres. On y déclare également le groupe de contacts pour les notifications.
Exemple :
# 'aix-servers' host group definition
define hostgroup{
hostgroup_name
aix-servers
alias
Serveurs AIX
contact_groups
aix-admins
members
svrs,ges,mac1,mac2,mac3,grh1,grh2
}
j) fichier /etc/nagios/hostextinfo.cfg
Ce fichier est primordial pour l’utilisation des status map 2D et 3D.
En effet, c’est ce fichier qui contient les coordonnées de positionnement des matériels, ainsi que les icônes
associées.
Exemple :
# 'mac1' hostextinfo definition
define hostextinfo{
host_name mac1
icon_image
aix.gif
vrml_image
aix.gif
gd2_image aix.gd2
icon_image_alt
Mac 1
2d_coords 233,544
}
Page 8/16
k) fichier /etc/nagios/services.cfg
Ce fichier contient les déclarations des services à surveiller par rapport aux hôtes.
Chaque service contient sa propre déclaration et est associé à un hôte, ou à un groupe d'hôte.
On y trouve essentiellement :
le nom d’hôte (ou groupe d'hôte)
la commande à exécuter (définie dans checkcommand.cfg) avec les paramètres chiffrés
les options de surveillance (intervalles de tests, période, nombre de tentatives avec le signalement
de l’échec,…)
les options de notification (période, groupe de contacts, gravité,…)
Exemple :
# Service definition
define service{
use
generic-service
host_name
mac1
service_description
Ping
is_volatile
0
check_period
24x7
max_check_attempts
3
normal_check_interval
3
retry_check_interval 1
contact_groups
aix-admins
notification_interval
240
notification_period
24x7
notification_options c,r
check_command
check_ping!40!200
}
l) fichier /etc/nagios/serviceextinfo.cfg
Ce fichier est optionnel. Il permet d’associer une icône à un service.
m) fichier /etc/nagios/dependancies.cfg
Ce fichier permet de créer des dépendances de services par rapport à un hôte, ou d’un hôte par rapport à
un hôte afin de supprimer les notifications multiples.
Ex : un serveur Mysql est arrêté, une application qui y fait appel sera également arrêtée. Il est inutile de
notifier pour les 2 problèmes.
n) fichier /etc/nagios/escalations.cfg
Ce fichier permet de retarder les notifications d’erreurs pour un matériel, un service ou un groupe de
matériels.
Par exemple, on pourra attendre 3 remontées d’erreur avant que le groupe de contacts ne soit prévenus.
Il peut être employé dans le cas où l'on désire gérer des niveaux d'administration différents.
Par exemple, de la 1ère à la 3ème alerte, Nagios prévient un groupe d'administrateur, puis à partir de la
4ème alerte, Nagios prévient un groupe d'administrateur avancé.
Page 9/16
o) fichier /etc/nagios/timeperiods.cfg
Ce fichier contient la définition des périodes de notifications. Il comprend les heures et les jours durant
lesquels les notifications sont appliqués.
On peut y définir différentes périodes.
Exemple :
# '24x7' timeperiod definition
define timeperiod{
timeperiod_name
24x7
alias
24 Hours A Day, 7 Days A Week
sunday
00:00-24:00
monday
00:00-24:00
tuesday
00:00-24:00
wednesday 00:00-24:00
thursday
00:00-24:00
friday
00:00-24:00
saturday
00:00-24:00
}
NAGIOSSTATD :
Pour des raisons de portabilité et de compatibilité, nous utilisons le module Nagiosstatd (repris de
Netsaint_statd) écrit en Perl. Son installation est simplifiée par rapport au nouveau module binaire de
Nagios intitulé NRPE donc les commandes ne sont pas toutes compatibles avec les systèmes AIX
particulièrement.
a) fonctionnement
Nagiosstatd est un script Perl permettant l’interrogation de services locaux sur une machine distante en
ouvrant un socket réseau sur un port déterminé à l’avance.
L’avantage de ce script est sa portabilité sur différents OS, il est totalement paramétrable quand à la
syntaxe des commandes à exécuter et du retour attendu par Nagios pour la remontée des alertes.
Nagios exécute un script_1 Perl qui ouvre une connexion sur un port déterminé en envoyant une demande
de commande.
Nagiosstatd reçoit cette demande et exécute la commande correspondante à l’OS en local, formate le
résultat et retourne la commande au script_1.
Le script_1 interprète les résultats et les retourne à Nagios.
b) installation
Livré sous forme de fichier RPM, son installation se procède par la commande suivante :
rpm -ivh nagiosstatd.rpm
Nagiosstatd est automatiquement intégré dans les processus de démarrage de Racvision et est défini en
tant que service possédant les commandes stop, start et restart (service nagiosstatd xxxx). Il s'installe dans
le répertoire /usr/sbin/
Il convient également d’installer Nagiosstatd sur Racvision, ce qui permet de tester son fonctionnement en
local. Son fonctionnement est bien sûr assujetti aux droits de communication des machines avec Racvision
au niveau des firewalls.
Il faut également éditer le fichier nagiosstatd (script perl) sur chaque serveur afin d’indiquer l’adresse IP de
Racvision dans la zone my @allowed_hosts.
Page 10/16
c) utilisation
Il faut, pour utiliser Nagiosstatd, déclarer une commande dans le fichier checkcommand.cfg.
Cette commande comprendra en paramètre l’adresse IP de l’hôte, les arguments utiles et le port sur lequel
la connexion doit se faire.
Ex : Voir l’occupation d’un volume sur AIX
Sur Racvision :
Dans le fichier checkcommands.cfg, on va trouver
define command{
command_name
check_disk_aix
command_line
/$USER1$/check_disk $HOSTADRESS $ARG1 $ARG2 $ARG3 1970
}
Dans le fichier services.cfg, on va trouver
define service{
host_name grh1
service_description
Test du point de montage /dev/hd1
check_command
check_disk_aix!/dev/hd1!90!95
……….
}
90 étant le pourcentage d’activation du warning et 95 le pourcentage d’activation du critical.
Pour que ceci fonctionne, il faut adapter le script Perl pour qu’il soit en phase avec Nagiosstatd. Dans
check_disk.pl, il y a une ligne qui envoie un alias de commande (en l’occurrence disk) sur le port ouvert.
Cet alias est déclaré dans le ficher Nagiosstatd (sur la machine hôte) et correspond donc à une ligne de
commande interprétable par le shell de l’hôte. D’où sa portabilité.
Par contre, le résultat de la commande doit être formaté afin que Nagios puisse l’interpréter. Il faut donc
obtenir en résultat la même ligne que si on avait exécuter la commande check_disk (binaire) se trouvant
dans le répertoire /usr/local/nagios/libexec.
Les principales commandes locales sont déjà paramétrées dans le fichier Nagiosstatd (processeur, swap,
point de montage)
Page 11/16
UTILISATION DES TEMPLATES :
La notion de templates permet la réduction massive des fichiers de définition des hôtes et des services
(hosts.cfg et services.cfg situés dans /etc/nagios).
Dans la définition classique des objets, on peut constater la répétition d’information dans chaque déclaration
comme l’intervalle de notification, les options de notification et la période de notification.
Voici un exemple de configuration ‘templatisée' :
# Generic host definition template
define host {
name
generic-host
notifications_enabled
1
event_handler_enabled
1
flap_detection_enabled
1
process_perf_data
1
retain_status_information
1
retain_nonstatus_information
1
register
0
; C’est un template
}
# Paramètres standarts pour les différents hosts
define host {
use
generic-host
name
stdr-host
max_check_attempts
3
300
notification_period
; Notifications 24h/24 7j/7
24x7
notification_options
(U)p et (R)ecovery
register
d,u,r
0
; Notification toutes les 5h
; Notifications pour (D)own,
; C'est un template
}
define host{
use
stdr-host
host_name webi
alias
Webi
address
webi.ac-nancy-metz.fr
parents
sw1-dmz.cigal
}
define host{
use
stdr-host
host_name cerbere
alias
Cerbere
Page 12/16
address
cerbere.ac-nancy-metz.fr
parents
sw1-dmz.cigal
}
Voici la même configuration sans les templates :
# Generic host definition template
define host {
name
generic-host
1
1
1
process_perf_data
1
1
1
register
0
}
define host{
use
generic-host
host_name webi
alias
Webi
address
webi.ac-nancy-metz.fr
parents
sw1-dmz.cigal
max_check_attempts
3
300
notification_period
24x7
notification_options d,u,r
; Notifications pour (D)own, (U)p et (R)ecovery
}
define host{
use
generic-host
host_name
cerbere
alias
Cerbere
address
cerbere.ac-nancy-metz.fr
parents
sw1-dmz.cigal
max_check_attempts
3
300
notification_period
24x7
notification_options d,u,r
; Notifications pour (D)own, (U)p et (R)ecovery
}
Le premier template déclaré (generic-host), ici pour le fichier hosts.cfg est décrit par défaut à l’installation
de Nagios.
Page 13/16
En ce qui concerne le fichier services.cfg, la méthode des templates devient très intéressante pour définir
les services communs à plusieurs types de machines. On retrouve toujours le principe d’élimination de
redondance d’information mais il permet la déclaration de service pour un groupe.
Par exemple, on déclare une seule fois les services swap, ping, ssh, file system pour les machines linux. Et
au lieu d’affecter un service à un hôte (hosts.cfg), on l’affecte à un groupe d’hôte (hostgroups.cfg). Ce qui
permet de créer uniquement l’hôte et de l’affecter à un groupe pour que les services communs soient
automatiquement affectés à cet hôte, et donc scanné par Nagios sans créé de service spécifique pour cet
hôte.
Voici un exemple du fichier services.cfg ‘templatisé’ :
# Generic service definition template
define service{
name
generic-service
active_checks_enabled
1
passive_checks_enabled
1
parallelize_check
1
obsess_over_service
1
check_freshness
0
1
1
1
process_perf_data
1
1
1
register
0
}
# Paramètres standards pour les différents services
define service{
name
srv-stdr-service
use
generic-service
is_volatile
0
check_period
24x7
max_check_attempts
3
normal_check_interval
5
retry_check_interval 1
notification_period
240
24x7
notification_options c,w,r
register
0
}
define service{
Page 14/16
name
srv-cpu-service
use
srv-stdr-service
service_description
CPU
check_command
check_load_unix!5!10
register
0
; C'est un template
}
define service{
name
srv-swap-service
use
srv-stdr-service
service_description
Swap
check_command
check_swapr!80!90
register
0
; C'est un template
}
# Test du CPU sur les serveurs AIX :
define service{
use
srv-cpu-service
hostgroup_name
aix-servers
contact_groups
aix-admins
}
# Test du CPU sur les serveurs Linux :
define service{
use
srv-cpu-service
hostgroup_name
linux-servers-cig
contact_groups
linux-admins
}
# Test du CPU sur les serveurs AIX :
define service{
use
srv-cpu-service
hostgroup_name
aix-servers
contact_groups
aix-admins
}
# Test du CPU sur les serveurs Linux :
define service{
use
srv-cpu-service
hostgroup_name
linux-servers-cig
contact_groups
linux-admins
}
Page 15/16
Le template generic-service est défini par défaut dans le fichier services.cfg.
Par contre, l’intêret se trouve dans le second template ici nommé srv-strd-service qui permet de définir une
seule fois les notifications.
Ensuite, on définit un service générique commun à plusieurs types d’hôtes (AIX, linux, switchs…) sous
forme de template.
Puis, on définit le service commun à un groupe de machines qui devient le service final qui apparaît dans
l’application Nagios.
Toute déclaration située dans un template (ex : notification_period, notification_intervall, contact_group,…)
peut être redéfinie dans un hôte ou un service. Dans ce cas, cette déclaration devient prioritaire sur le
template.
Par exemple, si vous indiquez dans le template de service que le service doit être vérifier toutes les 5
minutes, et que dans la déclaration de votre service, vous utilisez ce template, vous pouvez indiquer pour
ce service qu’il doit être vérifié toutes les 30 minutes. C’est cette option qui sera prise en compte. Ce qui
permet de garder des templates généralistes pour tous les services ou hôtes tout en affinant un hôte ou un
service particulier.
REDEMARRAGE DE NAGIOS :
Nagios possède une option de redémarrage ‘Reload’ (service nagios reload). Cette option permet de
recharger les configurations des fichiers CFG suite à un changement. L’option doit être activée dans le
fichier Nagios.cfg, comme l’exemple suivant (l’utilité de chaque ligne est décrite dans le fichier Nagios.cfg).
# RETAIN STATE INFORMATION
retain_state_information=1
# STATE RETENTION FILE
state_retention_file=/var/log/nagios/status.sav
# RETENTION DATA UPDATE INTERVAL
retention_update_interval=20
# USE RETAINED PROGRAM STATE
use_retained_program_state=1
Sans l’activation de ces 4 options, la commande ‘Reload’ fonctionnera mais tous les services définis seront
mis en mode ‘Pending’, c’est-à-dire en attente d’un nouveau résultat de check, qui selon le nombre de
services à checker peut être assez long dans la réinitialisation de toutes les données.
Sinon, Nagios lira les informations contenues dans le fichier ‘status.sav’ pour initialiser les services existant
avec leur état contenu dans ce fichier, et ne positionnera que les nouvelles données en mode ‘Pending’.
Page 16/16

NAGIOS v1.0

Transcription

Documents pareils

Courte Introduction « Nagios Business Process View » et « Nagios

Technicien Supérieur - downloads.tuxfamily.org

Mise en place de NAGIOS (logiciel de surveillance réseau) Sur l

LA SUPERVISION

formation en administration de reseaux

Administrateur Réseaux et systèmes

Procédure Nagios