NRPE Packet Size

[Fred Kroeger]

It appears that the NRPE packet size is limited to 1024Bytes. While this is OK for most checks, I do have a some disk checks that are larger, with the nett result that the performance data returned is truncated.
I have seen a few posts on this issue, but they seem to be workarounds instead of addressing the issue.
Is there anything available that provides a permanent solution to allow packets > 1024B

thanks - Fred Kroeger

[abrist]

check_by_ssh has essentially no upper limit. You could also break up the check into separate checks for each mount and group them into a servicegroup.

[Fred Kroeger]

Thanks - really wanted to use the nrpe agent instead of going down the ssh path.
Also toyed with breaking up the check, but then I have to rely on people to add any new filesystems to the check script

Fred

[slansing]

Yes, NRPE is a very handy protocol, though because of how it interfaces with the nagios server it must have this limit currently. How large are these disk checks? Is there anything you can break out of them to make them smaller?

[Fred Kroeger]

I've already cut down the output returned from the plugin to the absolute minmum. It;s just the amount of perfdata returned takes me over the 1024 limit.
I guess the only other option I have is to change my plugin & run it as a passive service and then just return each file system as an individual check.

[sreinhardt]

Even doing an individual check per disk returns more than 1024? If you really wanted to use nrpe you could likely run the check, then pass the data through something like gz or bz2 compressions before sending to nagios. Once nagios receives it, decompress and apply the results. I am not sure if anyone has done this, but it would be a pretty great solution to an issue especially if much of that data is redundant or simply ascii and easily compressable.

[Fred Kroeger]

I'm checking all local disks (not individual ones) , so if a server has 20 mounted file systems, then the perfdata for all 20 is returned.
The reason I do this is that all disks are always monitored - so I don't have to rely on someone remembering to add a check if they add a new filesystem.
It also allows me to display all drives on one graph using the new Graph Explorer in NagiosXI

However... this has now come back to bite me, because the rrd file that is created when the check runs for the first time, will contain the current list of disks.
If a filesystem is added or removed (some mounts are dynamic) , the number of entries returned doesn't match the number of entries in the rrd file and won't update the rrd file.
So I'm looking for a Check Disk plugin, that can check all local disks and returns each disk as an individual entry including perfdata.
This will keep me below the 1024 limit and also ensure that the rrd file updates aren't affected if a disk is missing (that particular rrd file just won't be updated)

regards Fred

[sreinhardt]

We were discussing this exact issues with rrds just after my post there and were concerned that may happen. Just to clarify, you would like to have say a 0 value for disks that are not there, just to continue the same track information? Do all servers that you monitor with this have the same number of disks or would you also need to have a parameter to specify how many total disks you would like to monitor regardless if they are present or not. Just to clarify, I do not know of anything presently that exists like this, however it should be possible to create.

[Fred Kroeger]

Not sure if it's as simple as inserting a 0 for a missing disk. How does the check_disk plugin know if a disk is missing?
For instance, if I run the check_disk and it reports 4 file systems - / ; /home ; /export ; / app
If one of the filesystems is unmounted (/export), the next time check_disk runs, it will just report the 3 filesystems.
The RRd load routine then won't work, because the rrd file expects 4 entries.

The same thing will happen on a Windows server that has 3 drives mounted - C:, D:, & E: - if a nother drive is added - D: then the rrd updates will stop working because it is only expecting 3 entries not 4.
So aprt from having individual monitors for every disk/filesystem, I'm not sure how I can reliable monitor all the filesyystems on a server.
I go back to my earlier point that if we monitor ecah disk individually, we hae a potential monitoing gap if a drive gets added anf the tech forgets to add the drive to Nagios.

Fred

[abrist]

This is due to the *bin* nature of rrds. Metrics cannot be added after the rrd is created. Even if the plugin returned "0" for missing mounts, you would still be limited by the original number of metrics - i.e. you would still not be able to add new disks. This is why we suggest to setup your mounts as *separate* checks. When new filesystems are added, as with any new service, you will have to create a check for it.