Nagios

De The Linux Craftsman
Aller à la navigation Aller à la recherche

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.

Nagios config operation.png

Notifications

  1. Au début le service est disponible, le voyant est au vert (état OK)
  2. 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)
  3. 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).
  4. Quand le service répond de nouveau, Nagios envoi une dernière notification pour signaler que le service est repassé à l'état OK.
Nagios service notification.png

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.

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!
}

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 qui