+---------------+------------------+--------------+--------------+
| Queue Name    | Worker Available | Jobs Waiting | Jobs Running |
+---------------+------------------+--------------+--------------+
| check_results | 1                | 0            | 0            |
| host          | 50               | 0            | 1            |
| service       | 50               | 0            | 13           |
| eventhandler  | 50               | 0            | 0            |
+---------------+------------------+--------------+--------------+

+-----------------------+------------------+--------------+--------------+
| Queue Name            | Worker Available | Jobs Waiting | Jobs Running |
+-----------------------+------------------+--------------+--------------+
| check_results         | 1                | 0            | 0            |
| host                  | 50               | 0            | 1            |
| service               | 50               | 0            | 13           |
| servicegroup_jmx4perl | 3                | 0            | 3            |
| hostgroup_japan       | 3                | 1            | 3            |
| eventhandler          | 50               | 0            | 0            |
+-----------------------+------------------+--------------+--------------+

The easiest variant is a simple load balancing. For example if your single nagios box just cannot handle the load, you could just add a worker in the same network (or even on the same host) to reduce your load on the nagios box. Therefor we just enable hosts, services and eventhandler on the server and the worker.

If your checks have to be run from different network segments, then you can use the hostgroups (or servicegroups) to define a hostgroup for specific worker. The general hosts and services queue is disabled for this worker and just the hosts and services from the given hostgroup will be processed.

Your distributed setup could easily be extended to a load balanced setup with just adding more worker of the same config.

If you just want to replace a current NSCA solution, you could load the Mod-Gearman NEB module and disable all distribution features. You still can receive passive results by the core send via send_gearman / send_multi. Make sure you use the same encryption settings like the neb module or your core won’t be able to process the results.

Using OMD is propably the easiest way of installing and using Mod-Gearman. You just have to run omd config or set Mod-Gearman to on.

Pre Requirements:

• gcc / g++

• autoconf / automake / autoheader

• libtool

• libgearman (>= 0.14)

Download the tarball and perform the following steps:

Then add the mod_gearman.o to your nagios installation and add a broker line to your nagios.cfg:

see Configuration for details on all parameters

The next step is to start one or more worker. You may use the same configuration file as for the neb module.

or use the supplied init script.

or a supplied init script (extras/gearmand-init). Command line arguments have change in recent gearman versions and you now should use something like:

A sample broker in your nagios.cfg could look like:

See the following list for a detailed explanation of available options:

Shared options for worker and the NEB module:

config

include config from this file. Options are the same as described here. include is an alias for config.

config=/etc/nagios3/mod_gm_worker.conf

debug

use debug to increase the verbosity of the module. Possible values are:

• 0 - only errors

• 1-4 - debug verbosity

• 5 - trace and all gearman related logs are going to stdout

Default is 0.

debug=1

logmode

set way of logging. Possible values are:

• automatic - logfile when a logfile is specified. stdout when no logfile is given. stdout for tools.

• stdout - just print all messages to stdout

• syslog - use syslog for all log events

• file - use logfile

• core - use nagios internal loging (not thread safe! Use with care)

Default is automatic.

debug=1

logfile

Path to the logfile.

logfile=/path/to/log.file

server

sets the address of your gearman job server. Can be specified more than once to add more server. Mod-Gearman uses the first server available.

server=localhost:4730,remote_host:4730

eventhandler

defines if the module should distribute execution of eventhandlers.

eventhandler=yes

services

defines if the module should distribute execution of service checks.

services=yes

hosts

defines if the module should distribute execution of host checks.

hosts=yes

hostgroups

sets a list of hostgroups which will go into seperate queues.

hostgroups=name1,name2,name3

servicegroups

sets a list of servicegroups which will go into seperate queues.

servicegroups=name1,name2,name3

encryption

enables or disables encryption. It is strongly advised to not disable encryption. Anybody will be able to inject packages to your worker. Encryption is enabled by default and you have to explicitly disable it. When using encryption, you will either have to specify a shared password with key=... or a keyfile with keyfile=... Default is On.

encryption=yes

key

A shared password which will be used for encryption of data pakets. Should be at least 8 bytes long. Maximum length is 32 characters.

key=secret

keyfile

The shared password will be read from this file. Use either key or keyfile. Only the first 32 characters from the first line will be used. Whitespace to the right will be trimmed.

keyfile=/path/to/secret.file

Additional options for the NEB module only:

localhostgroups

sets a list of hostgroups which will not be executed by gearman. They are just passed through.

localhostgroups=name1,name2,name3

localservicegroups

sets a list of servicegroups which will not be executed by gearman. They are just passed through.

localservicegroups=name1,name2,name3

do_hostchecks

Set this to no if you want Mod-Gearman to only take care about servicechecks. No hostchecks will be processed by Mod-Gearman. Use this option to disable hostchecks and still have the possibility to use hostgroups for easy configuration of your services. If set to yes, you still have to define which hostchecks should be processed by either using hosts or the hostgroups option. Default: yes

do_hostchecks=yes

result_workers

Number of result worker threads. Usually one is enough. You may increase the value if your result queue is not processed fast enough.

result_workers=3

perfdata

Defines if the module should distribute perfdata to gearman.

perfdata=yes

Note	processing of perfdata is not part of mod_gearman. You will need additional worker for handling performance data. For example: PNP4Nagios. Performance data is just written to the gearman queue.

perfdata_mode

There will be only a single job for each host or servier when putting performance data onto the perfdata_queue in overwrite mode. In append mode perfdata will be stored as long as there is memory left. Setting this to overwrite helps preventing the perf_data queue from getting to big. Monitor your perfdata carefully when using the append mode. Possible values are:

• 1 - overwrite

• 2 - append

Default is 1.

perfdata_mode=1

result_queue

sets the result queue. Necessary when putting jobs from several nagios instances onto the same gearman queues. Default: check_results

result_queue=check_results_nagios1

Additional options for worker:

identifier

Identifier for this worker. Will be used for the worker_identifier queue for status requests. You may want to change it if you are using more than one worker on a single host. Defaults to the current hostname.

identifier=hostname_test

pidfile

Path to the pidfile.

pidfile=/path/to/pid.file

min-worker

Minimum number of worker processes which should run at any time. Default: 1

min-worker=1

max-worker

Maximum number of worker processes which should run at any time. You may set this equal to min-worker setting to disable dynamic starting of workers. When setting this to 1, all services from this worker will be executed one after another. Default: 20

max-worker=20

spawn-rate

Defines the rate of spawed worker per second as long as there are jobs waiting. Default: 1

spawn-rate=1

idle-timeout

Time in seconds after which an idling worker exits. This parameter controls how fast your waiting workers will exit if there are no jobs waiting. Set to 0 to disable the idle timeout. Default: 10

idle-timeout=30

max-jobs

Controls the amount of jobs a worker will do before he exits. Use this to control how fast the amount of workers will go down after high load times. Disabled when set to 0. Default: 1000

max-jobs=500

fork_on_exec

Use this option to disable an extra fork for each plugin execution. Disabling this option will reduce the load on the worker host, but may cause trouble with unclean plugins. Default: yes

fork_on_exec=no

dupserver

sets the address of gearman job server where duplicated result will be sent to. Can be specified more than once to add more server. Useful for duplicating results for a reporting installation or remote gui.

dupserver=logserver:4730,logserver2:4730

show_error_output

Use this option to show stderr output of plugins too. When set to no, only stdout will be displayed. Default is yes.

show_error_output=yes

workaround_rc_25

Duplicate jobs from gearmand result sometimes in exit code 25 of plugins because they are executed twice and get killed because of using the same ressource. Sending results (when exit code is 25 ) will be skipped with this enabled. Only needed if you experience problems with plugins exiting with exit code 25 randomly. Default is off.

workaround_rc_25=off

+-----------------------+--------+-------+-------+---------+
| Name                  | Worker | Avail | Queue | Running |
+-----------------------+--------+-------+-------+---------+
| check_results         | 1      | 1     | 0     | 0       |
| host                  | 3      | 3     | 0     | 0       |
| service               | 3      | 3     | 0     | 0       |
| eventhandler          | 3      | 3     | 0     | 0       |
| servicegroup_jmx4perl | 3      | 3     | 0     | 0       |
| hostgroup_japan       | 3      | 3     | 0     | 0       |
+-----------------------+--------+-------+-------+---------+

Use the supplied check_gearman to monitor your worker and job server. Worker have a own queue for status requests.

This will send a test job to the given job server and the worker will respond with some statistical data.

Job server can be monitored with:

You can use send_gearman to submit active and passive checks to a gearman job server where they will be processed just like a finished check would do.

check_multi is a plugin which executes multiple child checks. See more details about the feed_passive mode at: www.my-plugin.de

You can pass such child checks to Nagios via the mod_gearman neb module:

If you want to use only check_multi and no other workers, you can achieve this with the following neb module settings: