Code: Select all
# use debug to increase the verbosity of the module.
# Possible values are:
# 0 = only errors
# 1 = debug messages
# 2 = trace messages
# 3 = trace and all gearman related logs are going to stdout.
# Default is 0.
debug=0
# Path to the logfile.
logfile=/var/log/mod_gearman/mod_gearman_worker.logCode: Select all
Host Description Max. Check Attempts Normal Check Interval Retry Check Interal Obsess Over
host-name01 interfaces 3 0h 3m 0s 0h 1m 0s YesThat is a proper explanation. The check_results queue should always be empty, or if it's not it should empty itself rather quickly. When it is not empty it means that Nagios and/or the NEB module have stalled for one reason or another. Troubleshooting why that's happening is where you start. What does the load look like on your central server? Is anything showing up in the neb module debug log to indicate why the stall is occurring? It's possible also that enabling gearmand logging and looking there will give insight. There is a problem, but the problem is *not* that mod_gearman is unstable, as mentioned when properly configured it can easily handle many tens of thousands of checks without fail. I recommend offloading as much work from the central server as you can, run all of your host and service checks on external workers and maybe even offload gearmand. I've seen great results from having gearmand on one or more separate servers.klajosh2 wrote:"The check_results queue is pilling up usually means that there is a problem with Nagios or the Mod-Gearman NEB module."
Most likely on-demand checks, not an uncommon scenario:klajosh2 wrote:What I saw the problem is that checks were
sent not the regular time as they were set in nagios config (3 mins) but in every 15-20 seconds.
Do you have any idea why this is happening?