Introduction

Tests passifs, tests actifs

Nagios distingue deux type de tests à effectuer sur les hôtes, par le biais de ses déclarations de services : les tests actifs et les tests passifs.

  • Les tests actifs sont les tests réalisés par Nagios via un de ses plugins : ça peut être le test d’un port ou le contrôle de la réponse d’un service. Ces tests sont synchrones (effectués à intervalle fixe).
  • Les tests passifs sont les tests dont les résultats sont reportés à Nagios par d’autres programmes : là ça sera NSCA. Ces tests sont asynchrones (effectués “quand on peut”, pas forcément régulièrement).

NSCA

NSCA est littéralement « Nagios Service Check Acceptor ». C’est un démon qui tourne en arrière plan, et qui va recevoir les résultats des tests passifs, pour le retransmettre à Nagios.

Pour plus de simplicité, NSCA sera installé sur la même machine que le serveur Maître de Nagios.

Munin <=> NSCA

Le serveur maître de Munin va communiquer à NSCA les résultats des tests grâce à la commande send_nsca, utilisant le protocole NSCA.

Pour encore plus de simplicité, nous allons supposer que le serveur maître de Munin et le serveur NSCA (et donc Nagios aussi) se trouvent sur la même machine (comme ça, pas besoin de chiffrer les communications entre Munin et NSCA).

NSCA <=> Nagios

NSCA va communiquer avec Nagios via un tube nommé, c’est à dire un fichier dans lequel il va écrire, et qui va être lu par Nagios à intervalle régulier.

On peut faire porter ce tube par une socket pour réaliser une installation de NCA et Nagios sur deux machines différentes, mais ce n’est pas le sujet de cet article.

Installation et configuration de NSCA

Installation

NSCA se trouve dans les dépôts : sudo apt-get install nsca

Configuration

La configuration de NSCA se trouve dans /etc/nsca.cfg. Voici les valeurs à retenir :

#Ne jouez pas à changer ça
pid_file=/var/run/nsca.pid

# Notre master Munin se trouve sur la même machine, donc on bind sur 127.0.0.1 et ça suffit
server_address=127.0.0.1

# Il est important que cet utilisateur puisse écrire dans le tube nommé pour communiquer avec Nagios !
nsca_user=nagios

# Ce fichier spécial devra aussi être mentionné dans la configuration de Nagios, et le nsca_user doit pouvoir y écrire
command_file=/var/lib/nagios3/rw/nagios.cmd

Ouvrez le fichier /etc/init.d/nsca et vérifiez que le PIDFILE est le même que celui de la configuration :

PIDFILE="/var/run/nsca.pid"

Configuration de Munin

Ouvrez le fichier /etc/munin/munin.conf.

Normalement, vus avez déjà configuré un “contact” pour être avertit en cas de défaillance d’un service contrôlé par Munin. Nous allons à la suite en rajouter un second :

contact.nagios.command /usr/sbin/send_nsca -H localhost
contact.nagios.always_send ok warning critical
contact.nagios.max_messages 1

Petite information qui vous fera gagner une journée de travail : max_messages doit être à 1 sous Debian 7. Ceci parce que le NSCA des dépôts a été mis  jour, et est devenu incompatible avec la version du protocole NSCA implémentée par Munin. On peut bidouiller NSCA pour corriger ça, mais la solution de contournement la plus simple est de n’envoyer qu’un message à la fois à NSCA.

Ici Munin enverra les résultats “OK”, “Warning” et “Critical” de ses module. Nous allons également faire en sorte qu’un Munin muet déclenche une erreur UNKNOWN chez Nagios, pour s’assurer que le “OK” correspond bien à un test “OK” et non à l’absence de “Warning” et de “Critical”.

Ok, on triche un peu. En fait, les tests de Munin sont synchrones. On a donc un mécanisme synchrone (Munin) qui va envoyer de manière synchrone les résultats au mécanisme asynchrone de collecte (NSCA). L’aspect synchrone va nous permettre de détecter le moment où on aurait dût recevoir un résultat, et alerter si ce n’a pas été le cas.

Configuration de Nagios

Communication avec NSCA

Ouvrez le fichier de configuration /etc/nagios3/nagios.cfg et vérifiez que la ligne suivante est bien présente et dé-commentée :

command_file=/var/lib/nagios3/rw/nagios.cmd

Les services

Si vous avez déjà redémarré les services après chaque modification de la configuration, vous pourrez voir dans les logs de Nagios les erreurs suivantes :

[1381670602] Warning:  Passive check result was received for service 'some service' on host 'hostname.ext', but the service could not be found!

La bonne nouvelle c’est que Nagios reçoit les notifications de NSCA !

La mauvaise c’est qu’il ne peut pas le lier à un service et à un hôte, parce qu’ils ne sont tout simplement pas déclarés. Il va nous falloir déclarer un service Nagios pour chaque service Munin que nous lui transmettons, sinon celui-ci ne sera pas capable de le traiter.

Créez le fichier /etc/nagios3/conf.d/services/munin-services.cfg et placez à l’intérieur la configuration suivante :

# generic service template definition
define service{
    name                           generic-munin-service ; The 'name' of this service template
    use generic-service
    check_command                  return-unknown!"No Data from passive check"
    active_checks_enabled          0       ; Active service checks are disabled
    check_freshness                1
    freshness_threshold            360
    flap_detection_options         n
    max_check_attempts             2
    register                       0   ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
    ;first_notification_delay      6    ; Delay first notification for false positives (will execute 2 checks : munin sends 1 check every 5 minutes)
}

define service {
    hostgroup_name                munin
    service_description           Disk latency per device :: Average latency for /dev/sda
    use generic-munin-service
    notification_interval         0 ; set > 0 if you want to be renotified
}

define service {
    service_description           Disk latency per device :: Average latency for /dev/sdb
    use generic-munin-service
    notification_interval         0 ; set > 0 if you want to be renotified
}

define service {
    hostgroup_name                munin
    service_description           Disk usage in percent
    use generic-munin-service
    notification_interval         0 ; set > 0 if you want to be renotified
}

define service {
    hostgroup_name                munin
    service_description           Inode usage in percent
    use generic-munin-service
    notification_interval         0 ; set > 0 if you want to be renotified
}

define service {
    hostgroup_name                munin
    service_description           File table usage
    use generic-munin-service
    notification_interval         0 ; set > 0 if you want to be renotified
}

define service {
    hostgroup_name                 munin
    service_description            eth0 errors
    use generic-munin-service
    notification_interval          0 ; set > 0 if you want to be renotified
}

define service {
    hostgroup_name                  munin
    service_description             Exim Mailqueue
    use generic-munin-service
    notification_interval           0 ; set > 0 if you want to be renotified
}

Ce fichier est bien évidemment à compléter selon les plugins et les checks que vous avez activé dans Munin. Le service_description est le nom complet du service dans Munin.

La configuration du template générique nous assure qu’une erreur “UNKNOWN : No data from passive check” sera retournée en cas d’absence de résultat après le délai du “freshness_threshold”, avec 2 essais avant d’alerter du problème.

Les groupes d’hôtes

Les plus attentifs d’entre-vous ont remarqué la présence d’un hostgroup dans la configuration, mais nous ne l’avons pas encore déclaré. Allons-y, rajoutez dans le fichier /etc/nagios3/conf.d/groups.cfg :

# Hostgroup for Munin
define hostgroup {
    hostgroup_name  munin
    alias           Munin reporting clients
}

Les hôtes

Maintenant qu’on a le hostgroup, il ne reste plus qu’à modifier vos fichiers /etc/nagios3/conf.d/hosts/*.cfg pour rajouter le hostgroup sur les hôtes sur lesquels munin-node est installé.

Débuggage

En principe, après avoir redémarré tous les services, vous devriez recevoir assez vite les notifications de NSCA et voir passer vos indicateurs du gris vers le vert dans Nagios.

Si ce n’est pas le cas et que ces derniers passent au orange, c’est qu’il y a un problème de communication entre Nagios et Munin. Mon problème principal a été le non démarrage de NSCA au démarrage de la machine, pour de histoires de PID que le script de démarrage n’arrivait à écrire ou à supprimer.

Il arrive aussi que le tube nommé soit inaccessible en écriture à l’utilisateur qui lance NSCA, vérifiez bien que l’utilisateur nagios est celui qui fait tourner à la fois Nagios et NSCA.

Enfin, pour vérifier que le problème ne vient pas d’une mauvaise configuration de Nagios, faites un envoi de données “manuellement” avec la commande send_nsca :

echo -e "monhote.ext\tNom complet du service Munin\t1\t0\n\n" | /usr/sbin/send_nsca -H localhost

Pour conclure

En conclusion, nous avons terminé notre installation de Munin, Nagios, et NSCA ! Munin communique à présent ses alertes à Nagios, et Nagios est capable d’alerter si ces alertes ne sont pas remontées. Le reste est dans les billets précédents ! ;)

N’hésitez pas à me faire part dans les commentaires des problèmes que vous pourriez rencontrer en déroulant cette suite d’articles, ou à me corriger si vous constatez des erreurs dans la série d’article. :)

.