NRPE kann die Ausgabe nicht lesen, aber warum?

Ich habe dieses Problem mit NRPE. Alles, was ich bisher im Internet gefunden habe, scheint mich auf Dinge hinzuweisen, die ich bereits ausprobiert habe.

# /usr/local/nagios/plugins/check_nrpe -H nrpeclient

gibt

NRPE v2.12

wie erwartet.

Wenn Sie den Befehl manuell ausführen (wie in nrpe.cfg unter "nrpeclient" definiert), erhalten Sie die erwartete Antwort

nrpe.cfg:

command[check_openmanage]=/usr/lib/nagios/plugins/additional/check_openmanage -s -e   -b ctrl_driver=0 bat_charge

"Expected response"

Wenn ich jedoch versuche, den Befehl vom Nagios-Server auszuführen, erhalte ich Folgendes:

# /usr/local/nagios/plugins/check_nrpe -H comxps -c check_openmanage
NRPE: Unable to read output

Kann sich irgendjemand etwas anderes vorstellen, bei dem ich vielleicht einen Fehler gemacht habe? Ich habe das gleiche auf mehreren anderen Servern ohne Probleme gemacht. Der einzige Unterschied, den ich mir dabei vorstellen kann, ist, dass diese Box auf RHEL 5 basiert, während die anderen auf RHEL 4 basieren.

Die beiden oben genannten Punkte, die ich getestet habe, scheinen den meisten Leuten nahezulegen, wenn sie dieses Problem hatten.

Ich sollte erwähnen, dass ich einen seltsamen Fehler in den Protokollen bekomme, wenn ich neu starte nrpe:

nrpe[14534]: Unable to open config file '/usr/local/nagios/etc/nrpe.cfg' for reading 
nrpe[14534]: Continuing with errors...
nrpe[14535]: Starting up daemon
nrpe[14535]: Warning: Daemon is configured to accept command arguments from clients!
nrpe[14535]: Listening for connections on port 5666 
nrpe[14535]: Allowing connections from: bodbck,combck,nam-bck

Obwohl es einfach ist, diese /usr/local/nagios/etc/nrpe.cfgDatei zu lesen, um die Dinge zu bekommen, über die es weiter unten spricht.

Sie haben ein Rechteproblem.

Ändern Sie den Befehl in:

command[check_openmanage]=sudo /usr/lib/nagios/plugins/additional/check_openmanage -s -e -b ctrl_driver=0 bat_charge

(füge sudo hinzu)

Fügen Sie dann den Nagios-Benutzer zu den Sudoern hinzu:

nagios ALL=(ALL) NOPASSWD:/usr/lib/nagios/plugins/additional/check_openmanage

Oder Sie könnten einfach die Datei chmod ... Das funktioniert auch.

Wenn Sie CentOS, Red Hat, Scientific oder Fedora verwenden, müssen Sie Defaults requirettydie sudoers-Datei deaktivieren .

Kurze Antwort: Wenn Sie ein Bash-Plugin verwenden, stellen Sie sicher, dass Sie einen Shebang haben , der angibt, welcher Interpreter verwendet werden soll:#!/bin/bash

Ich hatte das gleiche Problem mit einem Nagios-Plugin, das ich selbst geschrieben habe. Das Skript wurde beim lokalen Start erwartungsgemäß ausgeführt, auch wenn es als Benutzer nagiosmit der folgenden Anweisung ausgeführt wurde:

$ sudo sudo -s -u nagios
$ /path/to/my/plugin.sh
STATUS: OK

Das Remote-Starten mit NRPE vom Nagios3-Server aus war jedoch nicht erfolgreich:

$ /usr/lib/nagios/plugins/check_nrpe -H my-nagios-client -c my_plugin
NRPE: Unable to read output

Schließlich löste ich diesen Fall, indem ich meinem Skript einen Shebang hinzufügte , da anscheinend beim Ausführen des Skripts über NRPE nicht derselbe Interpreter wie beim Ausführen verwendet wurde sudo sudo -s -u nagios.

In meinem Fall bestand das Problem einfach darin, dass der Benutzer nagios das Skript nicht ausführen konnte. Nach chmod fing es an zu arbeiten. Sudo ist nicht notwendig. Es ist sogar böse :)

check_nrpe erhielt 'NRPE: Ausgabe konnte nicht gelesen werden', obwohl die Überprüfung lokal funktionierte, da das von mir verwendete Plugin mit SELinux nicht gut funktionierte. Deaktivieren Sie es und stellen Sie sicher, dass Sie die Kontexte der Datei entfernen:

$ ls -l check_om_storage
-r-xr-xr--. 1 root nrpe 3808 Feb 27 17:54 check_om_chassis
$ setfattr -x security.selinux check_om_storage
$ ls -l check_om_chassis 
-r-xr-xr-- 1 root nrpe 3808 Feb 27 17:54 check_om_chassis

Überprüfen Sie die Pfade, Berechtigungen, Selinux und Iptables.

Meins war ein Pfadproblem im Client: nrpe.cfg, überprüfen Sie den Befehlspfad zum Namen des check_ * -Plugins. Dies kann verwirrend sein (lib / local) (libexec / plugins) als Pfadname. Ich habe fälschlicherweise gezerrt und die Pfade aus der kommentierten vorverpackten nrpe cfg-Datei eingefügt, um Befehle zu erstellen. Die make install- oder yum plugin-Installation legt diese in einem anderen Verzeichnis ab.

commaneted: / usr / local / nagios / libexec / check_disk

gegen

realpath: / usr / lib / nagios / plugins / check_disk

Vom Server aus konnte ich bestätigen, dass es sich nicht um ein Firewall-Problem handelt, konnte eine Telnet-Verbindung zum 5666-Port herstellen, konnte eine Blanket-check_nrpe ausführen und den Status als Rückgabewert abrufen. Konnte die Befehle lokal ausführen, aber nrpe hatte den falschen Pfad auf dem Client in der Datei nrpe.cfg.

In meinem Fall ist nur ein Plugin ausgefallen, während mehrere andere in Ordnung waren. Es stellte sich heraus, dass es sich um ein LOCALE-Problem handelte.

Das Plugin war check_mem.shund es hat ein Grep für Memdie Ausgabe von ausgeführt free. Aber systemweite LOCALE zurück Speicher(deutsch) statt Mem, so dass alle empfangenen Werte leere Strings waren.

Dies ist ein Berechtigungsproblem. Geben Sie dem Skript einfach das richtige Ausführungsrecht und es ist in Ordnung:

Hier ein Beispiel: Vorher / Remote Host :

[root@puppet1 nrpe.d]# ls -l /usr/lib/nagios/plugins/check_mem.sh
-rwxr--r-- 1 root root 1598 Jul  7 10:55 /usr/lib/nagios/plugins/check_mem.sh

NRPE-Server :

[root plugins]# ./check_nrpe -H 172.19.9.200 -c check_mem_vb
NRPE: Unable to read output

Nachher: Remote-Host :

[root@puppet1 plugins]# chmod o+x /usr/lib/nagios/plugins/check_mem.sh

[root plugins]# ./check_nrpe -H 172.19.9.200 -c check_mem_vb
Memory: OK Total: 1980 MB - Used: 139 MB - 6% used|Total=2076479488;;;Used=145076224;;;Cache=1528111104;;Buffer=211890176;;;

Problem gelöst.

In meinem Fall befand sich die überwachte Protokolldatei im Besitz von root: adm, sodass das Hinzufügen des Nagios-Benutzers zur Gruppe adm den Befehl check_log erfolgreich ausführte, jedoch nur, wenn er direkt auf den überwachten Hosts ausgeführt wurde. Die Verwendung von check_nrpe auf dem Nagios-Server schlug weiterhin fehl, bis ich den Dienst nagios-nrpe-server auf den überwachten Hosts neu startete, z

service nagios-nrpe-server restart

Offensichtlich war ein Neustart des Dienstes erforderlich, damit die Berechtigungsänderung für NRPE wirksam wird, aber es dauerte eine Weile, bis ich das herausgefunden hatte.

Stellen Sie bei benutzerdefinierten NRPE-Plug-ins sicher, dass einige Ausgaben zusammen mit dem Exit-Wert gedruckt werden. Wenn keine Ausgabe vom Skript vorhanden ist, meldet NRPE "NRPE kann die Ausgabe nicht lesen" . Sie können das Debuggen in nrpe.cfg aktivieren und diesen Fehler beobachten.

In meinem Fall hatten die Probleme mit Selinux zu tun (unter RHEL 6.5 ist Selinux auf Enforcement eingestellt).

Wenn Sie nagios-plugins- * über yum installieren, werden Ihre Plugin-Dateien in / usr / lib64 / nagios / plugins erstellt. Wenn Sie den Kontext für diese Plug-in-Dateien überprüfen (ls -lZ), werden Sie feststellen, dass für die Dateien der Kontexttyp "nagios_system_plugin_exec_t" festgelegt ist. Dies ist der Kontexttyp, den check_nrpe erwartet.

In meinem Fall hatte ich ein benutzerdefiniertes Skript "check_mem.sh" mit "vi" erstellt. Die resultierende Datei hatte den Kontexttyp "lib_t". Dies führte dazu, dass nrpe die Meldung "NRPE: Ausgabe kann nicht gelesen werden" ausgab.

Durch Ändern des Dateikontexts in "nagios_system_plugin_exec_t" wurde das Problem behoben:

chcon -t nagios_system_plugin_exec_t /usr/lib64/nagios/plugins/check_mem.sh

Die übliche Selinux-Fehlerbehebung hätte mich auch auf dieses Problem hingewiesen (siehe /var/log/audit/audit.log), aber natürlich war es das Letzte, woran ich dachte

Edit: chcon ändert nur vorübergehend den Kontext. Um es dauerhaft zu ändern, verwenden Sie semanage fcontext -a -t nagios_system_plugin_exec_t /usr/lib64/nagios/plugins/check_mem.sh restorecon -vF /usr/lib64/nagios/plugins/check_mem.sh

Es kann sein, dass Sie Ihre Nagios-Plugins nicht installiert haben, NRPE sie nicht findet oder nicht darauf zugreift.

Ich musste Sudoern noch nie meine Befehle hinzufügen. Stellen Sie sicher, dass die Befehle dem Nagios-Benutzer gehören und lesbar sind.

Ich denke, Sie müssen die Plugins in Ihrem lokalen Verzeichnis hinzufügen /usr/lib64/nagios/plugins/*. Ich hatte das gleiche Problem wie Sie und kann es mit dieser Lösung lösen.

Ich hatte das Problem, dass Sie schreiben. Der Test, den ich lief, war von Perl. Fügen Sie diese Zeile in die Datei ein /etc/nagios/nrpe.cfg, damit sie funktioniert.

command [check_memory] = /usr/bin/perl /usr/lib64/nagios/plugins/check_memory -w 75-c 90 

Es gibt einen sehr schönen Artikel, der die gesamte Installation und Konfiguration des NRPE-Agenten mit vielen check_commands-Beispielen behandelt. Ich verwende diesen Artikel immer dann, wenn ich NRPE auf einem neuen Server installieren muss. Darüber hinaus finden Sie am Ende der Seite ein cooles Skript, das NRPE automatisch installiert und konfiguriert (basierend auf den von Ihnen festgelegten Variablen). Den Artikel finden Sie hier

Dies geschieht normalerweise, wenn der NRPE-Server mit dem Benutzer nrpe anstelle von nagios gestartet wird.

Das Ändern des nrpe_userWerts in nagios in der /etc/nagios/nrpe.cfgDatei sollte Ihr Problem lösen.

Das nrpe_groupkann bei Bedarf auch geändert werden.

Eine andere zu überprüfende Sache ist, dass, wenn Ihr Befehl verwendet wird sudo -u <another user>, um den Befehl auszuführen, das libexecVerzeichnis (und die darüber liegenden Verzeichnisse) für den Benutzer lesbar sein müssen, für den Sudo ausgeführt werden soll.

Zum Beispiel, wenn Ihr Befehl lautet:

command[check_tomcat]=sudo -u tomcat /usr/local/nagios/libexec/check_tomcat ...

Der Tomcat-Benutzer muss auf diese Datei zugreifen können.

Eine Möglichkeit, dies zu beheben, wäre:

chmod 0775 /usr/local/nagios/
chmod 0755 /usr/local/nagios/libexec

Ersetzen Sie den letzten Teil durch den, in dem sich Ihre ausführbaren Dateien befinden

Ich hatte das gleiche Problem und schaffe es, es zu lösen, indem ich den Nagios-Prozess (auf dem überwachten Computer) abbrach:

ps -ef | grep nagios
kill -9 [NagiosProcessNumber]
/etc/init.d/nagios-nrpe-server start

Danach ging alles gut.

Hatte gerade dieses Problem auf FreeBSD. Nachdem ich meinen Kopf für eine Stunde gegen eine Wand geschlagen hatte, stellte ich fest, dass das /usr/local/nagios/etc/nrpe.cfgfür sudo auf die falsche Stelle zeigte.

So finden Sie den richtigen Speicherort für den Befehl sudo:

# whereis sudo

Ich habe dann das command_prefix in nrpe.cfg geändert von:

command_prefix=/usr/local/sudo

zu:

command_prefix=/usr/local/bin/sudo

Dann rannte service nrpe restart und das Problem wurde gelöst.

Ein ähnliches Problem könnte auch bei anderen Betriebssystemen auftreten. Überprüfen Sie nur, ob Sie alle anderen möglichen Berechtigungsprobleme überprüft haben und dieses Problem weiterhin besteht.

Fehlende Nagios-Plugins auf dem nrpe-Client.

Verwenden Sie nicht yum install nagios-plugins (nagios-plugins-2.0.3-1.el6.x86_64). Es werden nicht alle Plugins installiert. Laden Sie nagios-plugins-1.4.11.tar.gz herunter und befolgen Sie die Anweisungen in diesem Dokument.

http://www.thegeekstuff.com/2008/06/how-to-monitor-remote-linux-host-using-nagios-30/

Ich hatte dieses Problem und löste das Deaktivieren von Selinux

setenforce 0