L'administration du système

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

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

NRPE, ou exécuteur du plugin à distance 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'il ne fait aucun travail à faire. Sur 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

Exigences logicielles et conventions de ligne de commande Linux
Catégorie Exigences, conventions ou version logicielle utilisée
Système Ubuntu 18.04, Fedora 30
Logiciel Nagios 4.3.4, NRPE 3.2.1
Autre Accès privilégié à votre système Linux en tant que racine ou via le Sudo commande.
Conventions # - Exige que les commandes Linux soient exécutées avec des privilèges racine soit directement en tant qu'utilisateur racine, soit par l'utilisation de Sudo commande
$ - Exige que les commandes Linux soient exécutées en tant qu'utilisateur non privilégié régulier

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-serveur, est 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épassement. 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 RPM distributions basées.

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 dans 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 packages également NRPE, et il devrait donc être accessible à partir des référentiels par défaut. Nous utiliserons simplement DNF pour l'installation.

# DNF Installer 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 NRPE Le package 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 le référentiel 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 du package sur NRPE.CFG peut être appliqué 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 des clients de manière centralisée et automatisée. En gardant cela à l'esprit, nous configurerons le client dans / etc / nrpe.D / Custom.CFG sur toutes les distributions dans les exemples suivants.

NRPE n'accepte aucune commande autre hôte local par défaut. C'est pour des raisons de sécurité. Pour autoriser l'exécution des commandes à partir d'un serveur, nous devons définir l'adresse IP du serveur comme adresse autorisée. Dans notre cas, le serveur est un serveur Nagios, avec adresse IP dix.101.20.34. Nous ajoutons ce qui suit à la configuration de notre client:

ALLIMED_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. En utilisant dhcp Sur le serveur de surveillance, cassera sûrement votre configuration, si vous utilisez l'adresse IP ici. Il en va de même pour le scénario où vous utilisez des noms d'hôte, 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 racine. Le courrier peut contenir un Tâche planifiée sortie, certains rapports ou quelque chose qui est écrit au Stderr et est livré en tant que courrier par défaut. Par exemple, abonner envoie un rapport de crash à racine Par défaut sur un procédure de processus. Nous n'avons pas configuré de relais de messagerie, mais nous aimerions toujours savoir si un courrier arrive. Écrivons un chèque personnalisé pour surveiller cela.

  1. 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 utilisateur = root si ["$ (commande -v doigt >> / dev / null; echo $?) "-gt 0]; puis écho" inconnu: le doigt de l'utilitaire n'est pas trouvé "Exit 3 fi if [" $ (id "$ user" >> / dev / null; echo $?) "-gt 0]; puis écho" inconnu: l'utilisateur $ l'utilisateur n'existe pas "Exit 3 fi ## chèque pour le courrier si [" $ (doigt -pm "$ user" | tail -n 1 | grep -ic "non poster.")" -gt 0]; puis écho "OK: pas de courrier non lu pour l'utilisateur $ utilisateur" Exit 0 else Echo "Avertissement: courrier non lu pour l'utilisateur $ utilisateur"
    Copie

    Ce simple contrôle utilise le doigt Utilité pour vérifier le courrier non lu pour l'utilisateur racine. 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, dernière ligne de sortie doigt -pm n'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 elle montre bien que lorsque vous travaillez avec différentes distributions et versions, certains travaux supplémentaires peuvent être nécessaires.

  2. Nous aurons besoin doigt Pour faire fonctionner ce chèque. Le nom du package est le même sur toutes les distributions, afin que nous puissions l'installer avec apte, zypper, DNF ou Miam.
  3. Nous devons définir l'exécutable de chèque: 
    # chmod + x check_unread_mail
  4. Nous allons placer le chèque dans le / usr / lib64 / nagios / plugins répertoire, la place commune pour les chèques NRPE. Nous le référenterons plus tard.
  5. Nous appellerons notre commande check_mail_root. Placerons 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: 
    Commande [check_mail_root] = / usr / lib64 / nagios / plugins / check_unread_mail
  6. Avec cela, notre configuration client est complète. Nous pouvons démarrer le service sur le client avec systemd. Le nom du service est nagios-nrpe-serveur sur les dérivés debian, et simplement NRPE sur d'autres distributions. 
    # systemctl start nagios-nrpe-server # statut systemctl nagios-nrpe-server ● nagios-nrpe-server.Service - Exécuteur du plugin à distance Nagios chargé: chargé (/ lib / systemd / system / nagios-nrpe-server.service; activé; Vendor Preset: Activé) Actif: Active (en cours d'exécution) Depuis Tue 2019-09-10 13:03:10 CEST; 1min 51s il y a des documents: http: // www.nagios.Org / Documentation principale PID: 3782 (NRPE) Tâches: 1 (Limite: 3549) CGroup: / System.Slice / Nagios-Nrpe-Server.Service └fiques3782 / USR / SBIN / NRPE -C / ETC / NAGIOS / NRPE.CFG -F Szept 10 13:03:10 Systemd-Client de Mail-Test [1]: Démarré l'exécuteur du plugin distant de Nagios. Szept 10 13:03:10 Mail-test-Client NRPE [3782]: Démarrage de Daemon Szept 10 13:03:10 NRPE de test de messagerie-test [3782]: Écoute du serveur sur 0.0.0.0 port 5666. Szept 10 13:03:10 NRPE de test de messagerie-test [3782]: Écoute du serveur sur :: Port 5666. Szept 10 13:03:10 NRPE de test de messagerie par courrier [3782]: Écoute des connexions sur le port 5666
  7. Maintenant, nous pouvons configurer le côté serveur. Si nous n'en avons pas déjà un, nous pouvons définir une commande qui appelle une télécommande NRPE instance avec une commande comme son seul argument: 
    # Cette commande exécute un programme $ arg1 $ sans arguments de définir la commande command_name check_nrpe_1arg command_line $ user1 $ / check_nrpe -h $ hostaddress $ -t 60 -c $ arg1 $ 2> / dev / null
    Copie
  8. Nous définissons également le client comme un hôte: 
    Define Host Utilisez Linux-Server Host_name Mail-Test-Client Alias ​​Mail-Test-Client Address Mail-Test-Client
    Copie

    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.

  9. 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: 
    Définir le service Utiliser Generic-Service Host_name Mail-Test-Client Service_Description OS: Mail non lu pour root check_command check_nrpe_1arg!check_mail_root
    Copie

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

  10. 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, dans 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 racine).

Les scripts ci-dessus ne rapportent pas un avertissement que si un nouveau courrier arrive exprès: dans l'exemple de l'environnement, il n'est pas considéré. 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 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 chèques de countles (appelés plugins) sont écrits 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 soient une excellente ressource lorsque nous devons surveiller quelque chose de nouveau, ne prenez pas pour acquis qu'ils feront exactement ce dont vous avez besoin. Ajuster leur configuration et leurs tests minutieux sont également nécessaires 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 ainsi que c'est construit en premier lieu, après tout.

Tutoriels Linux connexes:

  • Boucles imbriquées dans les scripts bash
  • Optimisation des performances de Linux: outils et techniques
  • Choses à installer sur Ubuntu 20.04
  • Choses à faire après l'installation d'Ubuntu 20.04 Focal Fossa Linux
  • Ubuntu 20.04 Surveillance du système avec des widgets conky
  • Comment envoyer des notifications de bureau à l'aide de notify-sens
  • Ubuntu 22.04 Surveillance du système avec des widgets conky
  • Meilleur outil de surveillance du système pour Linux
  • Système linux hung? Comment s'échapper vers la ligne de commande et…
  • Linux: Configuration SSH