Comment configurer le NRPE pour la surveillance côté client

NRPE, ou exécuteur du plugin distant de Nagios, est le service côté client d'une configuration de surveillance. Le serveur de surveillance enverra des commandes au client, qui écoute passivement lorsqu'elle n'a pas de travail à faire. Sur la commande entrante, le nrpe vérifie sa configuration locale et exécute le plugin configuré avec la commande, puis renvoie les résultats au serveur pour le traitement. Vous pouvez en savoir plus sur l'installation côté serveur dans le guide d'installation de Nagios, tandis que ce guide se concentrera sur le côté client.

Dans ce tutoriel, vous apprendrez:

Comment installer NRPE sur les distributions basées sur Debian/Red Hat
Comment configurer NRPE pour accepter les commandes du serveur
Comment configurer une vérification personnalisée sur le serveur et le côté client

NRPE - exécuteur du plugin à distance de Nagios

Exigences et conventions logicielles utilisées

Installation du NRPE sur les distributions basées sur Debian/Red Hat

L'installation du logiciel requis est simple. Nous couvrirons Ubuntu, Opensuse, Fedora et Rhel.

Installation du NRPE sur Ubuntu

Sur Ubuntu, ce processus est un seul liner. Le package du démon NRPE, appelé nagios-nrpe-server , figure dans les référentiels par défaut.

# apt-get install nagios-nrpe-server

Dans le cas d'Ubuntu, le fichier de configuration principal est /etc/nagios/nrpe.cfg , le répertoire inclus par défaut est /etc/nagios/nrpe.d/ , qui peut être utilisé pour la configuration de dépôt. Le package ajoute également un fichier de configuration local vide /etc/nagios/nrpe_local.cfg pour plus de commodité. Ce dernier n'est pas inclus dans les distributions basées sur rpm .

Installation du NRPE sur OpenSUSE

Sur les versions récentes OpenSuse, le logiciel NRPE est également emballé dans les référentiels par défaut. L'installation est donc une seule commande Linux.

# zypper in nrpe

Contrairement aux autres distros, OpenSUSE place le fichier de configuration principal sur le chemin /etc/nrpe.cfg .

Installation du NRPE sur Fedora

Le projet Fedora emballe également NRPE , et il doit donc être accessible à partir des référentiels par défaut. Nous utiliserons simplement dnf pour l'installation.

# dnf install nrpe

Le fichier de configuration principal sera /etc/nagios/nrpe.cfg , et le répertoire inclus par défaut est /etc/nrpe.d/.

Installation du NRPE sur Red Hat Enterprise Linux

En cas de RHEL, le package nrpe n'est pas dans les référentiels par défaut. Vous devrez activer le référentiel EPEL afin d'installer des packages à partir de là.

Vous pouvez suivre les étapes décrites dans le guide pour activer le référentiel EPEL, ou importer et publier le contenu des référentiels EPEL, si vous avez un environnement fermé avec une distribution de logiciels interne. Dans les deux sens, une fois que le référentiel est disponible pour la machine client, le processus d'installation est tout à fait le même que ci-dessus.

# yum install nrpe

Les fichiers de configuration sont au même endroit que dans le cas de Fedora.

Avertissement
Faites toujours des tests attentifs avant d'activer un nouveau référentiel dans un environnement de production. Dans ce cas, EPEL peut contenir des packages qui pourraient être considérés comme des mises à jour pour les packages Red Hat, entraînant des modifications logicielles inattendues sur le système lors de l'exécution d'une mise à jour complète.

Configuration du NRPE pour accepter les commandes du serveur

Pour configurer le service client, nous pourrions utiliser le fichier de configuration principal, mais je recommande d'utiliser un fichier personnalisé et de le placer dans un répertoire inclus dans le fichier de configuration principal. De cette façon, les mises à jour provenant d'une mise à niveau de package sur nrpe.cfg peuvent être appliquées sans modifications à notre configuration personnalisée.

Nous pouvons également inclure nos propres fichiers de configuration personnalisés dans nos packages personnalisés, permettant ainsi à la mise à jour de la configuration de surveillance du client de manière centralisée et automatisée. En gardant cela à l'esprit, nous allons configurer le client dans /etc/nrpe.d/custom.cfg sur toutes les distributions dans les exemples suivants.

NRPE n'accepte aucune commande autre que localhost par défaut. C'est pour des raisons de sécurité. Pour permettre l'exécution des commandes à partir d'un serveur, nous devons définir l'adresse IP du serveur en tant qu'adresse autorisée. Dans notre cas, le serveur est un serveur Nagios, avec l'adresse IP 10.101.20.34 . Nous ajoutons ce qui suit à la configuration de notre client:

allowed_hosts=10.101.20.34

Plusieurs adresses ou noms d'hôte peuvent être ajoutés, séparés par des virgules. Notez que la logique ci-dessus nécessite une adresse statique pour le serveur de surveillance. L'utilisation de dhcp sur le serveur de surveillance cassera sûrement votre configuration, si vous utilisez une adresse IP ici. Il en va de même pour le scénario où vous utilisez des noms d'hôtes, et le client ne peut pas résoudre le nom d'hôte du serveur.

Configuration d'une vérification personnalisée sur le serveur et le côté client

Pour démontrer les capacités de notre configuration de surveillance, disons que nous aimerions savoir si le système postfix local fournit un courrier sur un client pour l'utilisateur root . Le courrier peut contenir une sortie CRONJOB , un rapport ou quelque chose qui est écrit dans le stderr et est livré en tant que courrier par défaut. Par exemple, ABRT envoie un rapport de crash à root par défaut sur un crash de processus. Nous n'avons pas configuré de relais de messagerie, mais nous aimerions toujours savoir si un courrier arrive. Écrivons une vérification personnalisée pour surveiller cela.

Notre première pièce du puzzle est le chèque lui-même. Considérez le script de bash simple suivant appelé check_unread_mail :

#!/bin/bash

USER=root

if [ "$(command -v finger >> /dev/null; echo $?)" -gt 0 ]; then
        echo "UNKNOWN: utility finger not found"
        exit 3
fi
if [ "$(id "$USER" >> /dev/null ; echo $?)" -gt 0 ]; then
        echo "UNKNOWN: user $USER does not exist"
        exit 3
fi
## check for mail
if [ "$(finger -pm "$USER" | tail -n 1 | grep -ic "No mail.")" -gt 0 ]; then
        echo "OK: no unread mail for user $USER"
        exit 0
else
        echo "WARNING: unread mail for user $USER"
        exit 1
fi

Cette vérification simple utilise l'utilitaire Finger pour vérifier le courrier non lu pour l'utilisateur root . La sortie du doigt -pm peut varier selon la version et donc la distribution, donc certains ajustements peuvent être nécessaires.

Par exemple, sur Fedora 30, la dernière ligne de la sortie de Finger -Pm est «pas de courrier»., Mais sur OpenSuse Leap 15.1, ce serait «pas de courrier». (Remarquez le courrier supérieur). Dans ce cas, le grep -i gère cette différence, mais il montre bien que lorsque vous travaillez avec différentes distributions et versions, des travaux supplémentaires peuvent être nécessaires.

Nous aurons besoin de doigt pour faire fonctionner cette vérification. Le nom du package est le même sur toutes les distributions, nous pouvons donc l'installer avec apt , zypper , dnf ou yum .
Nous devons définir l'exécutable de chèque:
```
# chmod +x check_unread_mail
```
Nous allons placer la vérification dans le répertoire /usr/lib64/nagios/plugins , la place commune pour les vérifications NRPE. Nous le référenterons plus tard.
Nous appellerons notre commande check_mail_root . Placez une autre ligne dans notre configuration client personnalisée, où nous disons nrpe quelles commandes nous acceptons et ce qui doit être fait lorsqu'une commande donnée arrive:
```
command[check_mail_root]=/usr/lib64/nagios/plugins/check_unread_mail
```

Avec cela, notre configuration client est terminée. Nous pouvons démarrer le service sur le client avec systemd . Le nom du service est nagios-nrpe-server sur les dérivés debian, et simplement nrpe sur d'autres distributions.

# systemctl start nagios-nrpe-serversystemctl status nagios-nrpe-server
● nagios-nrpe-server.service - Nagios Remote Plugin Executor
   Loaded: loaded (/lib/systemd/system/nagios-nrpe-server.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-09-10 13:03:10 CEST; 1min 51s ago
     Docs: http://www.nagios.org/documentation
 Main PID: 3782 (nrpe)
    Tasks: 1 (limit: 3549)
   CGroup: /system.slice/nagios-nrpe-server.service
           └─3782 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -f

szept 10 13:03:10 mail-test-client systemd[1]: Started Nagios Remote Plugin Executor.
szept 10 13:03:10 mail-test-client nrpe[3782]: Starting up daemon
szept 10 13:03:10 mail-test-client nrpe[3782]: Server listening on 0.0.0.0 port 5666.
szept 10 13:03:10 mail-test-client nrpe[3782]: Server listening on :: port 5666.
szept 10 13:03:10 mail-test-client nrpe[3782]: Listening for connections on port 5666

Nous pouvons maintenant configurer le côté serveur. Si nous n'en avons pas déjà un, nous pouvons définir une commande qui appelle une instance à distance NRPE avec une commande comme seul argument:

# this command runs a program $ARG1$ with no arguments
define command {
        command_name    check_nrpe_1arg
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -t 60 -c $ARG1$ 2>/dev/null
}

Nous définissons également le client comme un hôte:

define host {
        use                     linux-server
        host_name               mail-test-client
        alias                   mail-test-client
        address                 mail-test-client
}

L'adresse peut être une adresse IP ou un nom d'hôte. Dans le dernier cas, nous devons nous assurer qu'il peut être résolu par le serveur de surveillance.

Nous pouvons définir un service sur l'hôte ci-dessus à l'aide de la commande côté Nagios et de la commande côté client:

define service {
        use                        generic-service
        host_name                  mail-test-client
        service_description        OS:unread mail for root
        check_command              check_nrpe_1arg!check_mail_root
}

Ces ajustements peuvent être placés à n'importe quel fichier de configuration que le serveur Nagios lit au démarrage, mais il est de bonne pratique de garder les fichiers de configuration rangés.

Nous vérifions notre nouvelle configuration Nagios:
```
# nagios -v /etc/nagios/nagios.cfg
```
Si «les choses semblent correctes», nous pouvons appliquer la configuration avec un rechargement de serveur:
```
# systemctl reload nagios
```

Conclusion

Si tout fonctionne, en quelques minutes, nous devrions voir notre nouveau client apparaître sur la page Web de Nagios, avec son nouveau service «OS: Mail non lu pour root», et avec le statut en tant que «OK» vert (c' est-à-dire s'il n'y a pas de t un courrier non lu pour root ).

Les scripts ci-dessus ne rapportent pas un avertissement si un nouveau courrier arrive exprès: dans l'exemple de l'environnement, il n'est pas considéré comme un problème critique, un crash d'application devrait avoir généré une erreur critique avant un courrier à ce sujet. En arrière-plan, le serveur Nagios transmet la commande «Check_mail_root» au client, où nrpe exécute notre script personnalisé, qui fournit la sortie «OK: pas de courrier non lu pour la racine de l'utilisateur », et le code de sortie du code 0 (qui est traduit par Nagios par état «OK»).

Cette configuration simple vise à afficher le flux de commandes et de données dans une configuration NAGIOS + NRPE, ainsi que d'expliquer les moyens de base pour étendre nos capacités de surveillance. Les vérifications de countles (appelées plugins) sont écrites dans divers langages pour des usages courants, par exemple l'analyse de fichiers de journaux, les vérifications de la base de données, les informations d'état du serveur Web, etc.

Beaucoup d'entre eux sont également pré-emballés dans les référentiels mentionnés ci-dessus, et encore plus peuvent être trouvés sur les pages officielles de Nagios. Bien que ce soit une excellente ressource lorsque nous devons surveiller quelque chose de nouveau, ne tenez pas pour acquis qu'ils feront exactement ce dont vous avez besoin. Il faut également modifier leur configuration et leurs tests minutieux dans ce cas, et si vous constatez qu'une petite modification peut ajouter une grande fonctionnalité/bugfix, n'hésitez pas à le contribuer à la communauté de surveillance. C'est la façon dont il est construit en premier lieu, après tout.