Meine Fragen: - Der Nagios läuft lokal, also checkt lokale Filesysteme? - wie ist die Definition des Check-Befehls? Normalerweise steht da ja ein "check_command $USER1$/check_disk" - wenn die Definition anders ist, wie? ein Befehl, der in commands.cfg definiert ist? Doch nrpe?
Wie gesagt, Nagios kümmert sich kein bisschen um Filesysteme und seine Größen. Nagios führt einen Befehl (hier: check_disk) aus und zeigt dann an, was der Befehl zurück gibt. Wenn es falsche Ergebnisse gibt, liegt es nicht an Nagios selbst, sondern am benutzten Befehl. Das kenne ich - wie gesagt -, wenn der Check nicht lokal läuft, sondern per nrpe aufgerufen wird. Wenn es zwischen Deinem manuellen Check und Nagios' Anzeige einen Unterschied gibt, verfolge den Weg, den Nagios zum Check benutzt. An irgend einer Stelle wird der falsche Befehl genutzt. Schlimmstenfalls mit indirektem Debugging (auf dem überwachten Host ausführen): a) (Befehl geht hier über 2 Zeilen) mv /usr/lib/nagios/plugins/check_disk \ /usr/lib/nagios/plugins/mycheck_disk b) (mehrzeilig, aber ein Befehl) cat >/usr/lib/nagios/plugins/check_disk<<EOT #!/bin/bash date +%F_%T >> /tmp/check_disk.log echo "\$@" >> /tmp/check_disk.log /usr/lib/nagios/plugins/mycheck_disk \$@ EOT c) chmod +x /usr/lib/nagios/plugins/check_disk Die Nagios-Konfiguration bleibt natürlich unverändert, so dass sie brav check_disk benutzt, sonst haben die erwähnten Schritte keinen Sinn.. Du erhältst dann die tatsächlichen Aufrufparameter von check_disk in der Logdatei. Und die dürften sich von den manuell eingesetzten unterscheiden. Dann musst Du nur noch suchen, wo diese Parameter in der Nagios-Config erwähnt werden. Die Sache mit nrpe ist irgendwann bei 15.3 (glaube ich, oder 15.2) aufgetreten, ohne erkennbare Warnung haben die Plugins dort ihre Check-Commands abgekippt und meine Ergebnisse zufallsorientiert ermittelt. Und die Nagios-Config als solche war auch seit Jahren unverändert (ich mache das seit 2005, SUSE seit 2003 beruflich). Im grep-Befehl kannst Du natürlich statt "/etc/nrpe.d/*" Dein eigenes Verzeichnis nehmen. Es wird rekursiv durchlaufen. Du kannst den Befehl auch auf "/etc/nagios/*" anwenden, vielleicht ist es doch da kaputt. HDH, Werner Am 2024-03-12 um 13:47 schrieb Astrid Kuhr: > Hallo! > > Besten Dank fuer die Antwort. > Ich schreib dann mal auf deutsch. > > Ich verwende das Nagios in nahezu unveraenderter Konfiguration > schon seit vielen vielen Jahren.> > Ich vermute mal, dass diese Ungereimheit jetzt mit einem Update > (von Nagios?) zusammenhaengt. > > Im ersten Bild ein Ausschnitt von meinem /home Filesystem Anfang 2022, > es sind ca. 3,4 TB belegt. Das gibt das Nagios ja auch korrekt wieder. > > Anfang 2023 passt es auch noch. > > Aber im letzten halben Jahr von 2023 ist dann was "passiert", > dass den Wert im Nagios zu Null gehen laesst. > Siehe 3. Bild. > > Bei einem anderen Filesystem, was auch in der aehnlichen TB Region > belegt ist, passiert dieses nicht. > > Siehe Bild 4. > > (Wie koennte ich dem Nagios fuer mein /home Filesystem sagen, dass es mir > es bitte auch in GB anzeigen soll, wie es es bei dem anderen Filesystem > tut?) > > Bei einem 3. Filesystem, was sich nur im GB Bereich belegt bewegt, da > stimmt auch die Grafik, aber die min/max Werte in der Beschriftung sind > auch krude... > > Der grep Befehl wird bei mir so nicht klappen, weil ich da eine > eigene Struktur hab. > > Und wie gesagt, meine Nagiosinstallation laeuft ueber viele viele > Jahre schon unveraendert und diese Filesystemungereimtheit ist > erst "jetzt" irgendwann aufgetreten. > > Gruss, Astrid > > Werner Flamme wrote: >> Am 2024-02-21 um 18:06 schrieb Astrid Kuhr: >>> Hello! >>> >>> I am using check_disk >>> (check_disk v2.3.1 (monitoring-plugins 2.3.1)) >>> for some filesystems. >>> >>> But for one filesystem of this, the perfdata >>> has strong values inside. >>> >>> As example: >>> >>> df -h >>> /dev/mapper/raid-home 4,0T 3,4T 553G 87% /home >>> /dev/mapper/raid-other 197G 155G 41G 80% /other >>> >>> /usr/lib/nagios/plugins/check_disk -w 12% -c 10% --unit GB -p /home >>> DISK OK - free space: /home 552 GB (13% inode=97%);| >>> /home=3474GB;3547;3627;0;4031 >>> >>> /usr/lib/nagios/plugins/check_disk -w 12% -c 10% --unit GB -p /other >>> DISK OK - free space: /usr/local/cfx 40 GB (20% inode=88%);| >>> /other=154GB;172;176;0;196 >>> >>> But if I look into NagiosGrid I will find this for /home: >>> >>> Status Information: DISK OK - free space: /home 1 GB (90% inode=99%): >>> Performance Data: /home=0GB;0;0;0;1 >>> >>> Which I do not understand, because it does not fit to the data, which >>> the command at console has as output. >>> >>> For the filesystem /other it is similar to command: >>> >>> Status Information: DISK OK - free space: /other 40 GB (20% >>> inode=88%): >>> Performance Data: /other=154GB;166;176;0;196 >>> >>> Is it possible, that Nagios can not do with terrabyte disks? >>> >>> Nagios is Nagios Core 4.4.7 from Suse Leap 15.5. >>> >>> Thanx. >>> >>> Regards, Astrid >> >> Hello Astrid, >> >> nagios does not know anything about the filesystem size. It just >> executes a command, normally using a plugin, and uses the returned text >> output and return values (aka "errorlevel"). >> >> Can it be that nagios executes a check_nrpe command that triggers >> something other on the monitored host than you execute yourself >> manually? I had this several times, because some plugins store their >> default config in /etc/nrpe.d and thus nrpe commands may be defined >> multiple times. You can never be sure which of the definitions are used. >> So I have nrpe checking in /etc/nrpe.ufz.d instead of the standard >> /etc/nrpe.d, which often gets infested when updates roll in ;) >> >> You can execute "grep -rn check_disk /etc/nrpe.d/*" to check this. And >> make sure that you change all commands in /etc/nrpe.cfg to comments. >> >> HTH, Werner >> >> > > > >
smime.p7s
Description: Kryptografische S/MIME-Signatur
