question to check_disk

[Werner Flamme]

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
>>
>>
> 
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5918 bytes
Desc: Kryptografische S/MIME-Signatur
URL: <https://www.monitoring-plugins.org/archive/help/attachments/20240312/92f1466a/attachment-0001.bin>