Différences entre versions de « Nagios »

De The Linux Craftsman
Aller à la navigation Aller à la recherche
(Page créée avec « = Prérequis = Tout d'abord, assurez-vous d'avoir installer le dépôt EPEL car la majeure partie de nos paquets viennent de cette source ! = Installation = »)
 
 
(77 versions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
 
= Prérequis =
 
= Prérequis =
−
Tout d'abord, assurez-vous d'avoir installer le dépôt EPEL car la majeure partie de nos paquets viennent de cette source !  
+
Dans un premier temps, il faudra avoir une connexion à Internet, utiliser un serveur DNS et désactiver SELinux.
 +
 
 +
Pour ceux qui auraient manqué des étapes les voici:
 +
* [[resolv.conf|Configuration du client DNS]]
 +
* [[ifcfg-ethX|Paramétrer sa carte réseau]]
 +
* [[SELinux#Changement_d.27.C3.A9tat|Désactiver SELinux]]
 +
 
 +
Une fois ces étapes effectuées, assurez-vous d'avoir installé le [[Linux_repository | dépôt EPEL]] car la majeure partie de nos paquets viennent de cette source !
  
 
= Installation =
 
= Installation =
 +
Nagios à besoin d'un serveur web pour fonctionner, ce qui nous donne :
 +
<pre>
 +
yum -y install httpd nagios nagios-plugins-all
 +
</pre>
 +
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.
 +
 +
[[Fichier:nagios_config_operation.png|centré]]
 +
 +
== 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''.
 +
 +
[[Fichier:nagios_service_notification.png|centré]]
 +
 +
== Vérifications distantes ==
 +
Pour assurer des vérifications ''locales'' sur des machines distantes, il faut un moyen d'exécuter les ''plugins'' sur la machine distante. Ce moyen c'est ''NRPE'' pour ''Nagios Remote Plugins Executor''.
 +
[[Fichier:nagios_nrpe_operation.png|centré]]
 +
 +
= Fichiers de configuration =
 +
Commençons par observer le contenu du répertoire ''/etc/nagios/objects'':
 +
<pre>
 +
# 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
 +
</pre>
 +
== 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 :
 +
<pre>
 +
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
 +
}
 +
</pre>
 +
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 :
 +
<pre>
 +
define timeperiod{
 +
  timeperiod_name week_start
 +
  alias          Lundi matin de 8h à 9h
 +
  monday          08:00-09:00
 +
}
 +
</pre>
 +
 +
== 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 :
 +
<pre>
 +
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 ******
 +
}
 +
</pre>
 +
Si on regardes bien, ce contact utilise un template qui contient les lignes suivantes:
 +
<pre>
 +
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!
 +
}
 +
</pre>
 +
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:
 +
<pre>
 +
# '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$
 +
}
 +
</pre>
 +
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 :
 +
<pre>
 +
define contactgroup{
 +
  contactgroup_name      admins
 +
  alias                  Nagios Administrators
 +
  members                nagiosadmin
 +
}
 +
</pre>
 +
Dans ce groupe figure uniquement le contact ''nagiosadmin'' mais il est possible d'en ajouter en les séparant par une virgule.
 +
 +
==commands.cfg==
 +
=== Déclaration d'une commande===
 +
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 :
 +
<pre>
 +
define command{
 +
  command_name    check_local_procs
 +
  command_line    $USER1$/check_procs -w $ARG1$ -c $ARG2$ -s $ARG3$
 +
}
 +
</pre>
 +
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':
 +
<pre>
 +
# /usr/lib64/nagios/plugins/check_procs -h
 +
</pre>
 +
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'' :
 +
<pre>
 +
# 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)
 +
</pre>
 +
Cependant, la commande ''check_local_procs'' ne permet pas d'utiliser le 'plugin' avec cet argument... Déclarons une nouvelle commande !
 +
<pre>
 +
define command{
 +
  command_name    check_user_process
 +
  command_line    $USER1$/check_procs -w $ARG1$ -c $ARG2$ -u $ARG3$
 +
}
 +
</pre>
 +
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:
 +
<pre>
 +
define host{
 +
  use                    linux-server            ; Name of host template to use
 +
  host_name              localhost
 +
  alias                  localhost
 +
  address                127.0.0.1
 +
}
 +
</pre>
 +
On peut remarquer que cette déclaration utilise le template ''linux-server'':
 +
<pre>
 +
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!
 +
}
 +
</pre>
 +
Qui lui même utilise le template ''generic-host'':
 +
<pre>
 +
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!
 +
}
 +
</pre>
 +
 +
=== 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.
 +
<pre>
 +
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%!/
 +
}
 +
</pre>
 +
On peut remarquer que cette déclaration utilise le template ''local-service'':
 +
<pre>
 +
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!
 +
}
 +
</pre>
 +
Qui lui même utilise le template ''generic-host'':
 +
<pre>
 +
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!
 +
}
 +
</pre>
 +
 +
= 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===
 +
<pre>
 +
define host{
 +
  use linux-server
 +
  host_name dhcp.tala-informatique.fr
 +
  alias sdhcpd
 +
  address 192.168.3.251
 +
}
 +
</pre>
 +
 +
===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.
 +
<pre>
 +
## 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
 +
}
 +
</pre>
 +
Pour que ''check_dhcp'' fonctionne, n'oubliez pas d'ouvrir le pare-feu :
 +
<pre>
 +
# iptables -I INPUT 2 -p udp --dport 68 -j ACCEPT
 +
</pre>
 +
= 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:
 +
<pre>
 +
# 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
 +
</pre>
 +
=Démarrage =
 +
Une fois la configuration terminée, on démarre ''Nagios'' et on l'enregistre dans le chargeur de démarrage:
 +
* Pour SystemVInit:
 +
<pre>
 +
service nagios start
 +
chkconfig nagios on
 +
</pre>
 +
* Pour SystemD:
 +
<pre>
 +
systemctl start nagios.service
 +
systemctl enable nagios.service
 +
</pre>
 +
 +
=Accès Web=
 +
== Accès administrateur ==
 +
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 nagiosadmin
 +
New password:
 +
Re-type new password:
 +
Updating password for user nagiosadmin
 +
</pre>
 +
Une fois que vous avez configuré et démarré [[HTTPD#Configuration_de_base | HTTPD]], vous avez accès à l’interface Web:
 +
[[Fichier:Web interface nagios intro.png|centré]]
 +
 +
== Autres accès ==
 +
Si vous décidez de créer d'autres utilisateurs que ''nagiosadmin'', il faudra leurs donner accès à certaines informations.
 +
Cela se passe dans le fichier ''/etc/nagios/cgi.conf'':
 +
<pre>
 +
use_authentication=1
 +
#edit username
 +
authorized_for_all_host_commands=username
 +
authorized_for_all_hosts=username
 +
authorized_for_all_service_commands=username
 +
authorized_for_all_services=username
 +
authorized_for_configuration_information=username
 +
authorized_for_system_commands=username
 +
authorized_for_system_information=username
 +
</pre>
 +
Il suffit d'ajouter les noms d'utilisateurs séparés d'une virgule.
 +
=NRPE : vérifications locales sur hôte distant =
 +
Les vérifications externes sont très intéressantes mais, malheureusement pas suffisantes pour garantir le bon fonctionnement d'un hôte.
 +
 +
Pour faire des vérifications locales sur un hôte distant, nous allons utiliser ''NRPE'' sur le serveur ''DHCP''.
 +
== Installation ==
 +
Pour faire des vérifications sur des machines distantes (autre que le serveur ''Nagios''), il faut installer le module ''NRPE'' sur ces machines:
 +
<pre>
 +
# yum -y install nrpe nagios-plugins-all
 +
</pre>
 +
 +
On n'oublie pas d'ouvrir le pare-feu:
 +
<pre>
 +
# iptables -I INPUT 2 -p tcp --dport 5666 -j ACCEPT
 +
</pre>
 +
 +
== Configuration ==
 +
=== Autorisation ===
 +
Nous allons modifier son fichier de configuration ''/etc/nagios/nrpe.cfg'' pour y ajouter l'adresse du serveur ''Nagios'':
 +
<pre>
 +
allowed_hosts=127.0.0.1, 192.168.3.242
 +
</pre>
 +
=== Commandes ===
 +
A la fin du fichier on peut voir les commandes qui sont déclarées :
 +
<pre>
 +
command[check_users]=/usr/lib64/nagios/plugins/check_users -w 5 -c 10
 +
command[check_load]=/usr/lib64/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
 +
command[check_hda1]=/usr/lib64/nagios/plugins/check_disk -w 20% -c 10% -p /dev/hda1
 +
command[check_zombie_procs]=/usr/lib64/nagios/plugins/check_procs -w 5 -c 10 -s Z
 +
command[check_total_procs]=/usr/lib64/nagios/plugins/check_procs -w 150 -c 200
 +
</pre>
 +
On peut modifier ''check_hda1'' en :
 +
<pre>
 +
command[check_sda]=/usr/lib64/nagios/plugins/check_disk -w 20% -c 10% -p /dev/sda
 +
</pre>
 +
== Démarrage ==
 +
Maintenant on peut démarrer ''NRPE'':
 +
<pre>
 +
# service nrpe start
 +
</pre>
 +
Et on l'enregistre dans le chargeur de démarrage:
 +
<pre>
 +
# chkconfig nrpe on
 +
</pre>
 +
 +
== Intégration dans ''Nagios'' ==
 +
=== Installation du plugin ===
 +
De retour sur le serveur ''Nagios'', nous allons tout d'abord installer le plugin ''NRPE'':
 +
<pre>
 +
# yum -y install nagios-plugins-nrpe
 +
</pre>
 +
== Test de connectivité ==
 +
Toujours sur le serveur ''Nagios'', pour être sûr que la connectivité est bonne, on peut utiliser le plugin:
 +
<pre>
 +
# /usr/lib64/nagios/plugins/check_nrpe -H 192.168.3.251
 +
NRPE v2.15
 +
</pre>
 +
Pourquoi pas une commande:
 +
<pre>
 +
# /usr/lib64/nagios/plugins/check_nrpe -H 192.168.3.251 -c check_sda
 +
DISK OK - free space: / 5472 MB (85% inode=95%);| /=947MB;5410;6086;0;6763
 +
</pre>
 +
Tout semble fonctionner, intégrons cela à la configuration !
 +
=== Modification de la configuration ===
 +
Tout d'abord, il faut ajouter une commande soit dans le fichier ''/etc/nagios/objects/commands.cfg'' soit dans le fichier ''/etc/nagios/conf.d/nrpe_plugin.cfg'' :
 +
<pre>
 +
#######################################################
 +
#
 +
# Ajout pour NRPE
 +
#
 +
#######################################################
 +
define command{
 +
  command_name    check_nrpe
 +
  command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
 +
}
 +
</pre>
 +
Nous pouvons maintenant modifier le fichier ''/etc/nagios/conf.d/sdhcp.cfg'' pour prendre en compte ces vérifications :
 +
<pre>
 +
define service{
 +
  use                    local-service
 +
  host_name              dhcp.tala-informatique.fr
 +
  service_description    Check users
 +
  check_command          check_nrpe!check_users
 +
}
 +
define service{
 +
  use                    local-service
 +
  host_name              dhcp.tala-informatique.fr
 +
  service_description    Check disk /dev/sda
 +
  check_command          check_nrpe!check_sda
 +
}
 +
define service{
 +
  use                    local-service
 +
  host_name              dhcp.tala-informatique.fr
 +
  service_description    Check load
 +
  check_command          check_nrpe!check_load
 +
}
 +
define service{
 +
  use                    local-service
 +
  host_name              dhcp.tala-informatique.fr
 +
  service_description    Check zombies
 +
  check_command          check_nrpe!check_zombie_procs
 +
}
 +
define service{
 +
  use                    local-service
 +
  host_name              dhcp.tala-informatique.fr
 +
  service_description    Check total process
 +
  check_command          check_nrpe!check_total_procs
 +
}
 +
</pre>
 +
Si on retourne sur l'interface Web, on peut observer ces nouvelles vérifications:
 +
[[Fichier:Nagios check nrpe web.png|centré]]
 +
 +
= Développement d'un plugin =
 +
Que faire lorsque rien ne permet de vérifier ce que vous voulez vérifier ?
 +
 +
Pas de panique, il suffit de développer son propre plugin. Avant d'aller plus loin, intéressons nous au fonctionnement des plugins :
 +
* les plugins renvoient trois états : 0 = OK ; 1 = WARNING ; 2 = CRITICAL
 +
* les plugins peuvent renvoyer '''une''' (1) ligne de retour
 +
 +
Développons un script pour retourner le nombre de machine qui ont eu une adresse IP dans la journée.
 +
== La date ==
 +
Sur nos machines françaises la date est la suivante :
 +
<pre>
 +
# date
 +
Thu Jan 14 04:28:04 CET 2016
 +
</pre>
 +
Or, dans le ''/var/log/message'', la date est formatée comme suit :
 +
<pre>
 +
Jan 14 00:54:08 dhcp dhcpd: added reverse map from 242.3.168.192.in-addr.arpa. to nagios.tala-informatique.fr
 +
</pre>
 +
Les mois ne correspondent pas... Il faut changer de langue pour que les mois s'affichent comme dans le ''/var/log/message''
 +
<pre>
 +
# LC_ALL=en_US.utf8
 +
# export LC_ALL
 +
# date
 +
Thu Jan 14 04:28:04 CET 2016
 +
# date +"%b %d"
 +
Jan 14
 +
</pre>
 +
On à la date du jour, maintenant filtrons les entrées qui concernent le serveur dhcpd:
 +
<pre>
 +
# cat /var/log/message | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK
 +
Jan 14 00:17:12 dhcp dhcpd: DHCPACK on 192.168.3.242 to 00:0c:29:32:07:4a via eth0
 +
Jan 14 00:54:08 dhcp dhcpd: DHCPACK on 192.168.3.242 to 00:0c:29:32:07:4a via eth0
 +
Jan 14 01:00:27 dhcp dhcpd: DHCPACK on 192.168.3.242 to 00:0c:29:32:07:4a via eth0
 +
Jan 14 03:41:37 dhcp dhcpd: DHCPACK on 192.168.3.242 to 00:0c:29:32:07:4a via eth0
 +
</pre>
 +
 +
== Les IPs ==
 +
Ceux sont vraiment les adresses IP qui nous intéresse, nous allons utiliser un filtre en colonne:
 +
<pre>
 +
#  cat /var/log/messages | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK | awk -F ' ' '{ print $8 }'
 +
192.168.3.242
 +
192.168.3.242
 +
192.168.3.242
 +
192.168.3.242
 +
</pre>
 +
Enfin, nous allons utiliser la commande ''sort'' pour faire resortir uniquement les adresses différentes:
 +
<pre>
 +
# cat /var/log/messages | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK | awk -F ' ' '{ print $8 }' | sort -u
 +
192.168.3.242
 +
</pre>
 +
Nous pourrions retourner l'adresse MAC associée à cette IP:
 +
<pre>
 +
# cat /var/log/messages | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK | grep 192.168.3.242 | awk -F ' ' '{ print $10 }' | sort -u
 +
00:0c:29:32:07:4a
 +
</pre>
 +
== Le plugin ==
 +
Ce qui nous donne les lignes suivantes que nous placeront dans ''/opt/nagios/check_dhcp_ip.sh'' :
 +
<source lang="bash">
 +
#!/bin/bash
 +
## Setting local time lang
 +
LC_ALL=en_US.utf8
 +
RET=""
 +
export LC_ALL
 +
## Getting IPs
 +
IPS=$(cat /var/log/messages | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK | awk -F ' ' '{ print $8 }' | sort -u)
 +
NBIP=0
 +
## Getting MACs
 +
for IP in ${IPS};do
 +
  MAC=$(cat /var/log/messages | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK | grep $IP | awk -F ' ' '{ print $10 }' | sort -u)
 +
  if [ "${RET}" != "" ];then
 +
      RET="${RET} ;"
 +
  fi
 +
  RET="${RET} ${IP} <-> ${MAC}"
 +
  let NBIP++
 +
done
 +
## Echoing return
 +
echo "${NBIP} ip delivered by dhcp : ${RET}"
 +
exit 0
 +
</source>
 +
Cela donne le résultat suivant:
 +
<pre>
 +
# ./check_dhcp_ip.sh
 +
2 ip delivered by dhcp :  192.168.3.242 <-> 00:0c:29:32:07:4a ; 192.168.3.243 <-> 00:0c:29:8f:03:25
 +
</pre>
 +
== Les droits ==
 +
Si on fait un :
 +
<pre>
 +
# ps -ef | grep nrpe | grep -v grep
 +
nrpe      3518      1  0 05:39 ?        00:00:00 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d
 +
</pre>
 +
On constate que ''NRPE'' se lance avec l'utilisateur ''nrpe'', et si on fait un :
 +
<pre>
 +
# ll /var/log/messages
 +
-rw------- 1 root root 33596 14 janv. 05:46 /var/log/messages
 +
</pre>
 +
On constate que le fichier ''/var/log/messages'' et lisible uniquement par ''root''. On va donc ''étendre'' les droits du fichier :
 +
<pre>
 +
# chmod 555 /var/log/messages
 +
</pre>
 +
De la sorte notre plugin sera fonctionnel, même exécuté par l'utilisateur ''nrpe''.
 +
 +
== Ajout dans nrpe.cfg ==
 +
Nous allons maintenant déclarer notre plugin dans le fichier ''/etc/nagios/nrpe.cfg'' :
 +
<pre>
 +
#####################
 +
#
 +
# SPECIFIC PLUGINS
 +
#
 +
#####################
 +
command[check_dhcp_ip]=/opt/nagios/check_dhcp_ip.sh
 +
</pre>
 +
On n'oublie pas de redémarrer ''NRPE'' :
 +
<pre>
 +
# service nrpe restart
 +
</pre>
 +
== Ajout sur le serveur Nagios ==
 +
Nous allons faire de même sur le serveur Nagios dans le fichier ''/etc/nagios/conf.d/sdhcpd.cfg'' :
 +
<pre>
 +
define service{
 +
  use                    local-service
 +
  host_name              dhcp.tala-informatique.fr
 +
  service_description    Check DHCP IP
 +
  check_command          check_nrpe!check_dhcp_ip
 +
}
 +
</pre>
 +
On n'oublie pas de redémarrer ''Nagios'' :
 +
<pre>
 +
# service nagios restart
 +
</pre>
 +
Et on vérifie sur l'interface web :
 +
[[Fichier:Check dhcp ip web.png|centré]]

Version actuelle datée du 25 novembre 2019 à 17:23

Prérequis

Dans un premier temps, il faudra avoir une connexion à Internet, utiliser un serveur DNS et désactiver SELinux.

Pour ceux qui auraient manqué des étapes les voici:

Une fois ces étapes effectuées, 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

Vérifications distantes

Pour assurer des vérifications locales sur des machines distantes, il faut un moyen d'exécuter les plugins sur la machine distante. Ce moyen c'est NRPE pour Nagios Remote Plugins Executor.

Nagios nrpe operation.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

Déclaration d'une commande

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.251
}

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
}

Pour que check_dhcp fonctionne, n'oubliez pas d'ouvrir le pare-feu : 

# iptables -I INPUT 2 -p udp --dport 68 -j ACCEPT

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 et on l'enregistre dans le chargeur de démarrage:

  • Pour SystemVInit:
service nagios start
chkconfig nagios on
  • Pour SystemD:
systemctl start nagios.service
systemctl enable nagios.service

Accès Web

Accès administrateur

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 nagiosadmin
New password:
Re-type new password:
Updating password for user nagiosadmin

Une fois que vous avez configuré et démarré HTTPD, vous avez accès à l’interface Web:

Web interface nagios intro.png

Autres accès

Si vous décidez de créer d'autres utilisateurs que nagiosadmin, il faudra leurs donner accès à certaines informations. Cela se passe dans le fichier /etc/nagios/cgi.conf: 

use_authentication=1
#edit username
authorized_for_all_host_commands=username
authorized_for_all_hosts=username
authorized_for_all_service_commands=username
authorized_for_all_services=username
authorized_for_configuration_information=username
authorized_for_system_commands=username
authorized_for_system_information=username

Il suffit d'ajouter les noms d'utilisateurs séparés d'une virgule.

NRPE : vérifications locales sur hôte distant

Les vérifications externes sont très intéressantes mais, malheureusement pas suffisantes pour garantir le bon fonctionnement d'un hôte.

Pour faire des vérifications locales sur un hôte distant, nous allons utiliser NRPE sur le serveur DHCP.

Installation

Pour faire des vérifications sur des machines distantes (autre que le serveur Nagios), il faut installer le module NRPE sur ces machines: 

# yum -y install nrpe nagios-plugins-all

On n'oublie pas d'ouvrir le pare-feu: 

# iptables -I INPUT 2 -p tcp --dport 5666 -j ACCEPT

Configuration

Autorisation

Nous allons modifier son fichier de configuration /etc/nagios/nrpe.cfg pour y ajouter l'adresse du serveur Nagios: 

allowed_hosts=127.0.0.1, 192.168.3.242

Commandes

A la fin du fichier on peut voir les commandes qui sont déclarées : 

command[check_users]=/usr/lib64/nagios/plugins/check_users -w 5 -c 10
command[check_load]=/usr/lib64/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
command[check_hda1]=/usr/lib64/nagios/plugins/check_disk -w 20% -c 10% -p /dev/hda1
command[check_zombie_procs]=/usr/lib64/nagios/plugins/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/lib64/nagios/plugins/check_procs -w 150 -c 200

On peut modifier check_hda1 en : 

command[check_sda]=/usr/lib64/nagios/plugins/check_disk -w 20% -c 10% -p /dev/sda

Démarrage

Maintenant on peut démarrer NRPE: 

# service nrpe start

Et on l'enregistre dans le chargeur de démarrage: 

# chkconfig nrpe on

Intégration dans Nagios

Installation du plugin

De retour sur le serveur Nagios, nous allons tout d'abord installer le plugin NRPE: 

# yum -y install nagios-plugins-nrpe

Test de connectivité

Toujours sur le serveur Nagios, pour être sûr que la connectivité est bonne, on peut utiliser le plugin: 

# /usr/lib64/nagios/plugins/check_nrpe -H 192.168.3.251
NRPE v2.15

Pourquoi pas une commande: 

# /usr/lib64/nagios/plugins/check_nrpe -H 192.168.3.251 -c check_sda
DISK OK - free space: / 5472 MB (85% inode=95%);| /=947MB;5410;6086;0;6763

Tout semble fonctionner, intégrons cela à la configuration !

Modification de la configuration

Tout d'abord, il faut ajouter une commande soit dans le fichier /etc/nagios/objects/commands.cfg soit dans le fichier /etc/nagios/conf.d/nrpe_plugin.cfg : 

#######################################################
#
# Ajout pour NRPE
#
#######################################################
define command{
   command_name    check_nrpe
   command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

Nous pouvons maintenant modifier le fichier /etc/nagios/conf.d/sdhcp.cfg pour prendre en compte ces vérifications : 

define service{
   use                    local-service
   host_name              dhcp.tala-informatique.fr
   service_description    Check users
   check_command          check_nrpe!check_users
}
define service{
   use                    local-service
   host_name              dhcp.tala-informatique.fr
   service_description    Check disk /dev/sda
   check_command          check_nrpe!check_sda
}
define service{
   use                    local-service
   host_name              dhcp.tala-informatique.fr
   service_description    Check load
   check_command          check_nrpe!check_load
}
define service{
   use                    local-service
   host_name              dhcp.tala-informatique.fr
   service_description    Check zombies
   check_command          check_nrpe!check_zombie_procs
}
define service{
   use                    local-service
   host_name              dhcp.tala-informatique.fr
   service_description    Check total process
   check_command          check_nrpe!check_total_procs
}

Si on retourne sur l'interface Web, on peut observer ces nouvelles vérifications:

Nagios check nrpe web.png

Développement d'un plugin

Que faire lorsque rien ne permet de vérifier ce que vous voulez vérifier ?

Pas de panique, il suffit de développer son propre plugin. Avant d'aller plus loin, intéressons nous au fonctionnement des plugins :

  • les plugins renvoient trois états : 0 = OK ; 1 = WARNING ; 2 = CRITICAL
  • les plugins peuvent renvoyer une (1) ligne de retour

Développons un script pour retourner le nombre de machine qui ont eu une adresse IP dans la journée.

La date

Sur nos machines françaises la date est la suivante : 

# date
Thu Jan 14 04:28:04 CET 2016

Or, dans le /var/log/message, la date est formatée comme suit : 

Jan 14 00:54:08 dhcp dhcpd: added reverse map from 242.3.168.192.in-addr.arpa. to nagios.tala-informatique.fr

Les mois ne correspondent pas... Il faut changer de langue pour que les mois s'affichent comme dans le /var/log/message 

# LC_ALL=en_US.utf8
# export LC_ALL
# date
Thu Jan 14 04:28:04 CET 2016
# date +"%b %d"
Jan 14

On à la date du jour, maintenant filtrons les entrées qui concernent le serveur dhcpd: 

# cat /var/log/message | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK
Jan 14 00:17:12 dhcp dhcpd: DHCPACK on 192.168.3.242 to 00:0c:29:32:07:4a via eth0
Jan 14 00:54:08 dhcp dhcpd: DHCPACK on 192.168.3.242 to 00:0c:29:32:07:4a via eth0
Jan 14 01:00:27 dhcp dhcpd: DHCPACK on 192.168.3.242 to 00:0c:29:32:07:4a via eth0
Jan 14 03:41:37 dhcp dhcpd: DHCPACK on 192.168.3.242 to 00:0c:29:32:07:4a via eth0

Les IPs

Ceux sont vraiment les adresses IP qui nous intéresse, nous allons utiliser un filtre en colonne: 

#  cat /var/log/messages | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK | awk -F ' ' '{ print $8 }'
192.168.3.242
192.168.3.242
192.168.3.242
192.168.3.242

Enfin, nous allons utiliser la commande sort pour faire resortir uniquement les adresses différentes: 

# cat /var/log/messages | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK | awk -F ' ' '{ print $8 }' | sort -u
192.168.3.242

Nous pourrions retourner l'adresse MAC associée à cette IP: 

# cat /var/log/messages | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK | grep 192.168.3.242 | awk -F ' ' '{ print $10 }' | sort -u
00:0c:29:32:07:4a

Le plugin

Ce qui nous donne les lignes suivantes que nous placeront dans /opt/nagios/check_dhcp_ip.sh : 

#!/bin/bash
## Setting local time lang
LC_ALL=en_US.utf8
RET=""
export LC_ALL
## Getting IPs
IPS=$(cat /var/log/messages | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK | awk -F ' ' '{ print $8 }' | sort -u)
NBIP=0
## Getting MACs
for IP in ${IPS};do
   MAC=$(cat /var/log/messages | grep "$(date +"%b %d")" | grep dhcpd | grep DHCPACK | grep $IP | awk -F ' ' '{ print $10 }' | sort -u)
   if [ "${RET}" != "" ];then
      RET="${RET} ;"
   fi
   RET="${RET} ${IP} <-> ${MAC}"
   let NBIP++
done
## Echoing return
echo "${NBIP} ip delivered by dhcp : ${RET}"
exit 0

Cela donne le résultat suivant: 

# ./check_dhcp_ip.sh
2 ip delivered by dhcp :  192.168.3.242 <-> 00:0c:29:32:07:4a ; 192.168.3.243 <-> 00:0c:29:8f:03:25

Les droits

Si on fait un : 

# ps -ef | grep nrpe | grep -v grep
nrpe       3518      1  0 05:39 ?        00:00:00 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d

On constate que NRPE se lance avec l'utilisateur nrpe, et si on fait un : 

# ll /var/log/messages
-rw------- 1 root root 33596 14 janv. 05:46 /var/log/messages

On constate que le fichier /var/log/messages et lisible uniquement par root. On va donc étendre les droits du fichier : 

# chmod 555 /var/log/messages

De la sorte notre plugin sera fonctionnel, même exécuté par l'utilisateur nrpe.

Ajout dans nrpe.cfg

Nous allons maintenant déclarer notre plugin dans le fichier /etc/nagios/nrpe.cfg : 

#####################
#
# SPECIFIC PLUGINS
#
#####################
command[check_dhcp_ip]=/opt/nagios/check_dhcp_ip.sh

On n'oublie pas de redémarrer NRPE : 

# service nrpe restart

Ajout sur le serveur Nagios

Nous allons faire de même sur le serveur Nagios dans le fichier /etc/nagios/conf.d/sdhcpd.cfg : 

define service{
   use                    local-service
   host_name              dhcp.tala-informatique.fr
   service_description    Check DHCP IP
   check_command          check_nrpe!check_dhcp_ip
}

On n'oublie pas de redémarrer Nagios : 

# service nagios restart

Et on vérifie sur l'interface web :

Check dhcp ip web.png
Récupérée de « https://tala-informatique.fr/index.php?title=Nagios&oldid=3473 »