Différences entre versions de « Nagios »
Ligne 413 : | Ligne 413 : | ||
<pre> | <pre> | ||
# chkconfig nagios on | # chkconfig nagios on | ||
+ | </pre> | ||
+ | |||
+ | =Accès Web= | ||
+ | Pour accéder à l'interface Web de ''Nagios'', il faut avant tout paramétrer un mot de passe et autoriser l'accès depuis une autre machine que ''127.0.0.1'': | ||
+ | Cela se passe dans le fichier ''/etc/httpd/conf.d/nagios.conf'', où il faut commenter les lignes suivantes: | ||
+ | <pre> | ||
+ | # Order deny,allow | ||
+ | # Deny from all | ||
+ | # Allow from 127.0.0.1 | ||
+ | </pre> | ||
+ | Maintenant, il ne nous reste plus qu'à définir un mot de passe: | ||
+ | <pre> | ||
+ | # htpasswd /etc/nagios/passwd nagios | ||
+ | New password: | ||
+ | Re-type new password: | ||
+ | Updating password for user nagios | ||
</pre> | </pre> |
Version du 17 janvier 2016 à 20:11
Prérequis
Tout d'abord, assurez-vous d'avoir installé le dépôt EPEL car la majeure partie de nos paquets viennent de cette source !
Installation
Nagios à besoin d'un serveur web pour fonctionner, ce qui nous donne :
yum -y install httpd nagios nagios-plugins-all
Avant d'aller plus loin, intéressons-nous au fonctionnement de Nagios.
Fonctionnement
Configuration
Plusieurs éléments de configuration sont présents dans Nagios:
timeperiods
Elles permettent de fixer les plages de notifications des contacts et de contrôle des hôtes et services.
contact
Ceux sont les personnes qu'ils faut alerter par la supervision
contactgroup
Ceux sont des groupes de plusieurs contact qui vont être alertées en même temps. Ceux sont souvent des personnes occupant le même poste (administrateur système, webmestre , responsable d'exploitation, etc...)
hosts
Ils représentent les machines physiques à superviser
hostgroup
Permettent de rassembler plusieurs host occupant le même rôle ou faisant tourner une même application.
services
Ceux sont les contrôles à effectuer sur un host (DNS, est-ce que le démon SSH tourne ?, % d'utilisation CPU, % d'utilisation mémoire, l’IO disque, ...)
servicegroup
Permet de rassembler des services pour les considerer comme un bloc comme c'est souvent le cas dans un cluster applicatif.
template
Ils permettent d'éviter les redondances au niveau des définitions d’hôtes et de services en regroupant des variables communes.
Notifications
- Au début le service est disponible, le voyant est au vert (état OK)
- Quand le service ne répond plus, Nagios le passe de l’état OK à Warning. Le service passe en état SOFT, c'est à dire que Nagios va déclencher le cycle de vérification de la fiabilité de l’incident (utilisation de retry_check et max_check_attemps)
- Au bout du cycle de vérification, Nagios passe le service en état HARD, c'est à dire que l’incident est certifié. Le cycle de notification va commencer (tous les notification_interval).
- Quand le service répond de nouveau, Nagios envoi une dernière notification pour signaler que le service est repassé à l'état OK.
Fichiers de configuration
Commençons par observer le contenu du répertoire /etc/nagios/objects:
# ll /etc/nagios/objects total 48 -rw-rw-r--. 1 root root 7704 31 août 2013 commands.cfg -rw-rw-r--. 1 root root 2166 31 août 2013 contacts.cfg -rw-rw-r--. 1 root root 5403 31 août 2013 localhost.cfg -rw-rw-r--. 1 root root 3124 31 août 2013 printer.cfg -rw-rw-r--. 1 root root 3293 31 août 2013 switch.cfg -rw-rw-r--. 1 root root 11158 31 août 2013 templates.cfg -rw-rw-r--. 1 root root 3208 31 août 2013 timeperiods.cfg -rw-rw-r--. 1 root root 4019 31 août 2013 windows.cfg
Timeperiods.cfg
Dans ce fichier sont déclaré les périodes que nous allons pouvoir utiliser pour la vérification des hôtes ou des services. Ci-dessous un exemple :
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 }
On voit qu'une période se définit comme suit :
- timeperiod_name : identifiant de la période, doit être unique dans toute la configuration de 'Nagios;
- alias : appellation longue, permettant de mieux identifier la période;
- monday 00:00-24:00, tuesday 00:00-24:00, ... : les jours de la semaine suivis de l'heure de début et de l'heure de fin.
Pas très compliqué de créer sa propre période. Imaginons que nous voulions une période qui correspond aux lundi matin entre 8h et 9h :
define timeperiod{ timeperiod_name week_start alias Lundi matin de 8h à 9h monday 08:00-09:00 }
contact.cfg
Contact
Dans ce fichier sont déclaré les contacts qui vont pouvoir être contactés quand un problème surviendra. Ci-dessous un exemple :
define contact{ contact_name nagiosadmin ; Short name of user use generic-contact ; Inherit default values from generic-contact template (defined above) alias Nagios Admin ; Full name of user email nagios@localhost ; <<***** CHANGE THIS TO YOUR EMAIL ADDRESS ****** }
Si on regardes bien, ce contact utilise un template qui contient les lignes suivantes:
define contact{ name generic-contact ; The name of this contact template service_notification_period 24x7 ; service notifications can be sent anytime host_notification_period 24x7 ; host notifications can be sent anytime service_notification_options w,u,c,r,f,s ; send notifications for all service states, flapping events, and scheduled downtime events host_notification_options d,u,r,f,s ; send notifications for all host states, flapping events, and scheduled downtime events service_notification_commands notify-service-by-email ; send service notifications via email host_notification_commands notify-host-by-email ; send host notifications via email register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL CONTACT, JUST A TEMPLATE! }
Quelques précisions :
- les notification_options prennent les paramètres suivants :
- w: notification sur les états WARNING;
- u: notification sur les états UNKNOWN;
- c: notification sur les états CRITICAL;
- r: notification quand le service repasse à l'état OK (RECOVERY);
- f: notification quand il y a du flapping (quand le service démarre et s'arrête sans cesse);
- s: notification quand la période d'arrêt programmée (SCHEDULED DOWNTIME) est terminée;
- n: pas de notification (NONE).
Notifications
- les notification_commands sont déclarées dans le fichier /etc/nagios/objects/commands.cfg:
# 'notify-host-by-email' command definition define command{ command_name notify-host-by-email command_line /usr/bin/printf "%b" "***** Nagios *****\n \nNotification Type: $NOTIFICATIONTYPE$ \nHost: $HOSTNAME$ \nState: $HOSTSTATE$ \nAddress: $HOSTADDRESS$ \nInfo: $HOSTOUTPUT$ \n\nDate/Time: $LONGDATETIME$\n" | /bin/mail -s "** $NOTIFICATIONTYPE$ Host Alert: $HOSTNAME$ is $HOSTSTATE$ **" $CONTACTEMAIL$ } # 'notify-service-by-email' command definition define command{ command_name notify-service-by-email command_line /usr/bin/printf "%b" "***** Nagios *****\n \nNotification Type: $NOTIFICATIONTYPE$ \n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$ \nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$ \n\nDate/Time: $LONGDATETIME$ \n\nAdditional Info:\n\n$SERVICEOUTPUT$\n" | /bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$ }
Ces deux commandes envoie un mail (/bin/mail) au contact désigné.
Groupe
Toujours dans le fichier /etc/nagios/objects/contact.cfg on peut trouver la déclaration d'un groupe de contact :
define contactgroup{ contactgroup_name admins alias Nagios Administrators members nagiosadmin }
Dans ce groupe figure uniquement le contact nagiosadmin mais il est possible d'en ajouter en les séparant par une virgule.
commands.cfg
Dans ce fichier sont écrites différentes commandes que l'on peut utiliser pour faire des vérifications sur des hôtes. Ces commandes utilisent des 'plugins' qui se trouvent dans le répertoire /usr/lib64/nagios/plugins et nous allons plutôt détailler l'usage de ces 'plugins'.
Pour terminer avec ce fichier, nous allons prendre un exemple. Le plugin check_procs, qui permet de vérifier combien de processus tourne sur une machine et utilisé dans le fichier commande comme suit :
define command{ command_name check_local_procs command_line $USER1$/check_procs -w $ARG1$ -c $ARG2$ -s $ARG3$ }
Seulement, ce n'est pas la seul façon d'utiliser check_procs, et on peut s'en rendre compte en demandant le help du 'plugin':
# /usr/lib64/nagios/plugins/check_procs -h
On peut utiliser l'option -u pour vérifier si un utilisateur a lancé un processus. Cela peut être pratique si vous voulez vérifier que certain démon fonctionnent, comme par exemple ntp :
# ps -ef | grep ntp | grep -v grep ntp 10458 1 0 07:55 ? 00:00:00 ntpd -u ntp:ntp -p /var/run/ntpd.pid -g # ./check_procs -u ntp PROCS OK: 1 processus avec UID = 38 (ntp)
Cependant, la commande check_local_procs ne permet pas d'utiliser le 'plugin' avec cet argument... Déclarons une nouvelle commande !
define command{ command_name check_user_process command_line $USER1$/check_procs -w $ARG1$ -c $ARG2$ -u $ARG3$ }
On laisse les options -w et -c pour nous pouvoir mettre des paliers sur le nombre de processus lancés. Dans le cas d'un serveur Apache, cela peut être intéressant de déclenché des alarmes en fonction du nombre de processus lancés. En effet, si trop de processus sont démarré, le serveur est peut-être trop sollicité ou sous en train de subir une attaque DDOS. On peut de toute façon, passer la valeur -1 à -w ou -c pour les désactiver.
Listes des commandes
- notify-host-by-email
- notify-service-by-email
- check-host-alive
- check_local_disk
- check_local_load
- check_local_procs
- check_local_users
- check_local_swap
- check_local_mrtgtraf
- check_ftp
- check_hpjd
- check_snmp
- check_http
- check_ssh
- check_dhcp
- check_ping
- check_pop
- check_imap
- check_smtp
- check_tcp
- check_udp
- check_nt
- process-host-perfdata
- process-service-perfdata
localhost.cfg
Définition d'un hôte
Au début du fichier on trouve la déclaration de l'hôte:
define host{ use linux-server ; Name of host template to use host_name localhost alias localhost address 127.0.0.1 }
On peut remarquer que cette déclaration utilise le template linux-server:
define host{ name linux-server ; The name of this host template use generic-host ; This template inherits other values from the generic-host template check_period 24x7 ; By default, Linux hosts are checked round the clock check_interval 5 ; Actively check the host every 5 minutes retry_interval 1 ; Schedule host check retries at 1 minute intervals max_check_attempts 10 ; Check each Linux host 10 times (max) check_command check-host-alive ; Default command to check Linux hosts notification_period workhours ; Linux admins hate to be woken up, so we only notify during the day notification_interval 120 ; Resend notifications every 2 hours notification_options d,u,r ; Only send notifications for specific host states contact_groups admins ; Notifications get sent to the admins by default register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE! }
Qui lui même utilise le template generic-host:
define host{ name generic-host ; The name of this host template notifications_enabled 1 ; Host notifications are enabled event_handler_enabled 1 ; Host event handler is enabled flap_detection_enabled 1 ; Flap detection is enabled failure_prediction_enabled 1 ; Failure prediction is enabled process_perf_data 1 ; Process performance data retain_status_information 1 ; Retain status information across program restarts retain_nonstatus_information 1 ; Retain non-status information across program restarts notification_period 24x7 ; Send host notifications at any time register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE! }
Définition des services
Plus loin dans le fichier, nous pouvons voir la déclaration des services. Les services utilisent quatre paramètres:
- un template' ;
- un host ;
- une description ;
- une commande.
define service{ use local-service ; Name of service template to use host_name localhost service_description Root Partition check_command check_local_disk!20%!10%!/ }
On peut remarquer que cette déclaration utilise le template local-service:
define service{ name local-service ; The name of this service template use generic-service ; Inherit default values from the generic-service definition max_check_attempts 4 ; Re-check the service up to 4 times in order to determine its final (hard) state normal_check_interval 5 ; Check the service every 5 minutes under normal conditions retry_check_interval 1 ; Re-check the service every minute until a hard state can be determined register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE! }
Qui lui même utilise le template generic-host:
define service{ name generic-service ; The 'name' of this service template active_checks_enabled 1 ; Active service checks are enabled passive_checks_enabled 1 ; Passive service checks are enabled/accepted parallelize_check 1 ; Active service checks should be parallelized (disabling this can lead to major performance problems) obsess_over_service 1 ; We should obsess over this service (if necessary) check_freshness 0 ; Default is to NOT check service 'freshness' notifications_enabled 1 ; Service notifications are enabled event_handler_enabled 1 ; Service event handler is enabled flap_detection_enabled 1 ; Flap detection is enabled failure_prediction_enabled 1 ; Failure prediction is enabled process_perf_data 1 ; Process performance data retain_status_information 1 ; Retain status information across program restarts retain_nonstatus_information 1 ; Retain non-status information across program restarts is_volatile 0 ; The service is not volatile check_period 24x7 ; The service can be checked at any time of the day max_check_attempts 3 ; Re-check the service up to 3 times in order to determine its final (hard) state normal_check_interval 10 ; Check the service every 10 minutes under normal conditions retry_check_interval 2 ; Re-check the service every two minutes until a hard state can be determined contact_groups admins ; Notifications get sent out to everyone in the 'admins' group notification_options w,u,c,r ; Send notifications about warning, unknown, critical, and recovery events notification_interval 60 ; Re-notify about service problems every hour notification_period 24x7 ; Notifications can be sent out at any time register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE! }
Configuration
Les ajouts de configuration ceux font dans le répertoire /etc/nagios/conf.d.
Hôtes
Dans cette exemple, nous considérerons un serveur DHCP à l'adresse 192.168.3.251. Les lignes de configuration seront écrites dans le fichier /etc/nagios/conf.d/sdhcpd.conf
Déclaration de l'hôte
define host{ use linux-server host_name dhcp.tala-informatique.fr alias sdhcpd address 192.168.3.250 }
Vérifications externes
Dans un premier temps, nous allons déclarer des vérifications externes qui ne nécessite aucune intervention sur la machine à surveiller.
## SERVICE DEFINITION ## define service{ use local-service host_name dhcp.tala-informatique.fr service_description Host alive check_command check-host-alive } define service{ use local-service host_name dhcp.tala-informatique.fr service_description Check dhcpd check_command check_dhcp!192.168.3.250 }
Pre fly check
Avant de démarrer Nagios, il est intéressant de faire une vérification de la configuration pour voir s'il n'y a pas d'erreur:
# nagios -v /etc/nagios/nagios.cfg Nagios Core 3.5.1 Copyright (c) 2009-2011 Nagios Core Development Team and Community Contributors Copyright (c) 1999-2009 Ethan Galstad Last Modified: 08-30-2013 License: GPL Website: http://www.nagios.org Reading configuration data... Read main config file okay... Processing object config file '/etc/nagios/objects/commands.cfg'... Processing object config file '/etc/nagios/objects/contacts.cfg'... Processing object config file '/etc/nagios/objects/timeperiods.cfg'... Processing object config file '/etc/nagios/objects/templates.cfg'... Processing object config file '/etc/nagios/objects/localhost.cfg'... Processing object config directory '/etc/nagios/conf.d'... Processing object config file '/etc/nagios/conf.d/www.cfg'... Processing object config file '/etc/nagios/conf.d/sdhcpd.cfg'... Read object config files okay... Running pre-flight check on configuration data... Checking services... Checked 11 services. Checking hosts... Checked 3 hosts. Checking host groups... Checked 1 host groups. Checking service groups... Checked 0 service groups. Checking contacts... Checked 1 contacts. Checking contact groups... Checked 1 contact groups. Checking service escalations... Checked 0 service escalations. Checking service dependencies... Checked 0 service dependencies. Checking host escalations... Checked 0 host escalations. Checking host dependencies... Checked 0 host dependencies. Checking commands... Checked 24 commands. Checking time periods... Checked 5 time periods. Checking for circular paths between hosts... Checking for circular host and service dependencies... Checking global event handlers... Checking obsessive compulsive processor commands... Checking misc settings... Total Warnings: 0 Total Errors: 0 Things look okay - No serious problems were detected during the pre-flight check
Démarrage
Une fois la configuration terminée, on démarre Nagios:
# service nagios start
Et on l'enregistre dans le chargeur de démarrage:
# chkconfig nagios on
Accès Web
Pour accéder à l'interface Web de Nagios, il faut avant tout paramétrer un mot de passe et autoriser l'accès depuis une autre machine que 127.0.0.1: Cela se passe dans le fichier /etc/httpd/conf.d/nagios.conf, où il faut commenter les lignes suivantes:
# Order deny,allow # Deny from all # Allow from 127.0.0.1
Maintenant, il ne nous reste plus qu'à définir un mot de passe:
# htpasswd /etc/nagios/passwd nagios New password: Re-type new password: Updating password for user nagios