Graphing question

[BanditBBS]

Have a stupid question for you all....since I know I should know this...I think it's just some of the knowledge that has been forced out as new knowledge has entered my brain!

Quite a few of my disk check graphs are no longer graphing. There are ungodly amounts of mount points being tracked, i.e.:

Code: Select all

/=1403MB;1784;1883;0;1983 /usr=10410MB;13390;14134;0;14878 /var=1687MB;13390;14134;0;14878 /tmp=153MB;8927;9423;0;9919 /boot=20MB;88;93;0;98 /dev/shm=23769MB;65223;68847;0;72471 /ugrc=65496MB;90711;95751;0;100791 /tmpbackups=85534MB;317528;335168;0;352809 /us3001=27526MB;45356;47876;0;50396 /us4001=26483MB;45356;47876;0;50396 /ud4001=131406MB;181425;191504;0;201584 /ua4001=91MB;136068;143627;0;151187 /us1001=9395MB;36287;38303;0;40319 /ud1001=39785MB;90711;95751;0;100791 /ua1001=213MB;54424;57448;0;60472 /ut4001=210MB;27213;28725;0;30237 /uu4001=3104MB;27213;28725;0;30237 /ut1001=8377MB;13606;14362;0;15118 /uu1001=736MB;13606;14362;0;15118 /ur1001=799MB;4535;4787;0;5039 /ur1002=778MB;4535;4787;0;5039 /ur4001=397MB;4535;4787;0;5039 /ur4002=267MB;4535;4787;0;5039 /backup=56478MB;54427;57451;0;60475 /temp-mount-point=2478MB;2230;2354;0;2478

Some mount points may be removed over time and new ones may be added. Is that the cause of the graphs stopping working? Is there any way for me to resolve?

[abrist]

Some mount points may be removed over time and new ones may be added.

This is most likely the problem. To verify, increase the debug levels for perfdata and npcd, wait 15 minutes, and then check the perfdata and npcd logs:
http://support.nagios.com/wiki/index.ph ... h_Problems

Code: Select all

tail -50 /usr/local/nagios/var/perfdata.log
tail -50 /usr/local/nagios/var/npcd.log

[sreinhardt]

Yes almost definitely. Well I should clarify that it wont necessarily break the rrd initially, but it will absolutely cause issues all over the place, from tracks not getting the right data, to tracks filling with zero at the end of the rrd. You could use Andy's rrd fix script on the FAQ for fixing icmp\ping rrds. It works with everything. But that will only ensure that you have the proper number of tracks, not that the data is going to the correct track. There almost nothing you can do to resolve that, short of having a MUCH more intelligent plugin that understands what mountpoint, partion, drive, etc goes with which track. I unfortunately do not know of anything that would do this short of individual checks.

[BanditBBS]

Yes almost definitely. Well I should clarify that it wont necessarily break the rrd initially, but it will absolutely cause issues all over the place, from tracks not getting the right data, to tracks filling with zero at the end of the rrd. You could use Andy's rrd fix script on the FAQ for fixing icmp\ping rrds. It works with everything. But that will only ensure that you have the proper number of tracks, not that the data is going to the correct track. There almost nothing you can do to resolve that, short of having a MUCH more intelligent plugin that understands what mountpoint, partion, drive, etc goes with which track. I unfortunately do not know of anything that would do this short of individual checks.

So is the short answer: I'm screwed and should tell the plugin to not even bother returning perfdata(if that's an option on the plugin I'm using)?

Longer answer is this: Separate into two checks, one that is hard coded to only check /, /usr, /var, /tmp so it never changes and another that is set to check all the data mount point we use?

[sreinhardt]

Unfortunately, yep that is about right. Sorry.

[BanditBBS]

Unfortunately, yep that is about right. Sorry.

Yes, you better personally apologize, it's all your fault!

Feel free to lock this up, just wanted to make sure I was understanding properly, thanks!

[krobertson71]

I think it's just some of the knowledge that has been forced out as new knowledge has entered my brain!

Personally I think this is the issue to being with.... I have met you, so not much buffer space there.

[sreinhardt]

locking this one up, before you guys get too out of hand over here.