service_check_timeout

[Maxwellb99]

Hello,

I'm running the check_oracle_health plugin; specifically the can-allocate-next-extent module. It can take upwards of 10 minutes to crunch through all our tablespaces. I set the "-t" timeout flag to 600 & I set the following: check_interval:12; retry_interval:10; max_check_attempts: 2; Here's where I'm at. Sometimes it returns results. Sometimes it returns timeout in 60.1 seconds:

Questions:
-Suggestions about troubleshooting? Note: I haven't gotten a timeout when running it from the command line using the timeout flag. It might take a while for some of the DB's but it always returns a result from the command line.
-I saw in the main config the service-timeout is set to 60. Who wins the service-timeout in the plugin or the one in the main config?
-Thoughts about changing the main config to be 600?

service_timeout.PNG

service_timeout2.PNG

Thanks,
Maxwell Ramirez

[mcapra]

I would change the structure of this check to be a passive check. Then run it on something like a cron job with a ~15 minute interval.

More info here:
https://assets.nagios.com/downloads/nag ... ios-XI.pdf

But the gist of it is, you create a wrapper script/command to call your Oracle plugin(s) and have them submit results to Nagios XI via external commands, NRDP, or some other passive method.

You certainly could bump up the service_check_timeout, but that has implications on the entire monitoring system and the above setup only affects one single service check.

[cdienger]

I agree with @mcapra's suggestion. And to help clarify the behavior - Using the -t option will work , but requires also increasing the service_check_value in nagios.cfg which is a global change. When the command is run from the cli it doesn't take the nagios.cfg into consideration.

[Maxwellb99]

Thank you both for your responses. I'll run it by management and see what they want to do. Kind of a bummer that I'd have to push out an agent. Right now I'm doing everything through the check_oracle_health plugin & connecting directly to the DB's.

Please close this thread.

Cheers,
Maxwell Ramirez