Fresh out of Advanced training and need help (modGearman)

[bheden]

Do you have any workers that are set with

Code: Select all

hosts=yes
services=yes

Because, if you have any hosts/services that aren't in a defined hostgroup/servicegroup queue or localhostgroup/localservicegroup, you need to have at least 1 worker that has a hosts queue - otherwise they'll never get checked, and then be orphaned.

[dlukinski]

Do you have any workers that are set with

Code: Select all

hosts=yes
services=yes

Because, if you have any hosts/services that aren't in a defined hostgroup/servicegroup queue or localhostgroup/localservicegroup, you need to have at least 1 worker that has a hosts queue - otherwise they'll never get checked, and then be orphaned.

Which means I should run worker on XI or next to XI (our case)?

Thank you for explaining memberships.
Please keep this thread open as we are to test more

[bheden]

I think its already been said here..

If you don't want the XI server to execute ModGearman checks, its as simple as turning the ModGearman worker off on the XI box. BUT REMEMBER: if you want some checks to be executed by XI (outside of ModGearmans interaction) you have to define them in a hostgroup or servicegroup, and define that group in the module.conf as a local pass through.

Also, you did not answer my question about if you have any ModGearman worker with hosts=yes or services=yes defined. Thats important, as it could directly be the cause of your orphaned checks.

[dlukinski]

I think its already been said here..

If you don't want the XI server to execute ModGearman checks, its as simple as turning the ModGearman worker off on the XI box. BUT REMEMBER: if you want some checks to be executed by XI (outside of ModGearmans interaction) you have to define them in a hostgroup or servicegroup, and define that group in the module.conf as a local pass through.

Also, you did not answer my question about if you have any ModGearman worker with hosts=yes or services=yes defined. Thats important, as it could directly be the cause of your orphaned checks.

- I do not (workers have it set for NO, while XI got worker disabled as per your notes)
- Just realized local group being pass-through if if worker is disabled. So I would have to re-enable one or to have worker by XI side (to offload checks if required)

What happens if the same host is defined in local and in remote site group?
What is host defined as local, but its checks defined as remote?

[bheden]

- I do not (workers have it set for NO, while XI got worker disabled as per your notes)

You need at least 1 worker to execute checks for the hosts and services queues! At least 1 worker will need to have these enabled in order for checks to not be orphaned!

- Just realized local group being pass-through if if worker is disabled. So I would have to re-enable one or to have worker by XI side (to offload checks if required)

localhostgroups and localservicesgroups ARE NOT executed by ModGearman, they are passed directly to Nagios to execute.

What happens if the same host is defined in local and in remote site group?
What is host defined as local, but its checks defined as remote?

I ..have no idea. Based on the source code in ModGearman it looks like hostgroup would take precedence, but you'll never know until you lab it!

[dlukinski]

- I do not (workers have it set for NO, while XI got worker disabled as per your notes)

You need at least 1 worker to execute checks for the hosts and services queues! At least 1 worker will need to have these enabled in order for checks to not be orphaned!

- Just realized local group being pass-through if if worker is disabled. So I would have to re-enable one or to have worker by XI side (to offload checks if required)

localhostgroups and localservicesgroups ARE NOT executed by ModGearman, they are passed directly to Nagios to execute.

What happens if the same host is defined in local and in remote site group?
What is host defined as local, but its checks defined as remote?

I ..have no idea. Based on the source code in ModGearman it looks like hostgroup would take precedence, but you'll never know until you lab it!

Hmm. again questions:

So I define host in local (because it is otherwise orphaned in my scenario) despite its services being defined in remote group...
Now if Am to define host in remote group and remove from local, it is still orphaned because remote workers are set to NO (no matter if remote groups are specifically defined for them)

if I re-enable worker on XI, remove some host(s) from local and define their services (not the hosts themselves) as remote, this should work correctly (because we want to have same type of unique checks done against the same hosts from various remote workers.. ?
- shows 5 workers after restart & re-enable on XI (no jobs waiting for 2 hosts out of local) / mod_gearman2_worker is not recognized as service for some reason

[bheden]

So I define host in local (because it is otherwise orphaned in my scenario) despite its services being defined in remote group...
Now if Am to define host in remote group and remove from local, it is still orphaned because remote workers are set to NO (no matter if remote groups are specifically defined for them)

You need all queues that will be picked up by workers defined in the worker and in the neb configuration

if I re-enable worker on XI, remove some host(s) from local and define their services (not the hosts themselves) as remote, this should work correctly (because we want to have same type of unique checks done against the same hosts from various remote workers.. ?

If I understand that correctly, yes.

- shows 5 workers after restart & re-enable on XI (no jobs waiting for 2 hosts out of local) / mod_gearman2_worker is not recognized as service for some reason

It is mod-gearman2-worker, not mod_gearman2_worker!

[Box293]

(please confirm - Troy's manual has a paragraph starting from editing worker.conf and ending with "save module.conf")

I have fixed this mistake, it should have said "save worker.conf".

[dlukinski]

So I define host in local (because it is otherwise orphaned in my scenario) despite its services being defined in remote group...
Now if Am to define host in remote group and remove from local, it is still orphaned because remote workers are set to NO (no matter if remote groups are specifically defined for them)

You need all queues that will be picked up by workers defined in the worker and in the neb configuration

if I re-enable worker on XI, remove some host(s) from local and define their services (not the hosts themselves) as remote, this should work correctly (because we want to have same type of unique checks done against the same hosts from various remote workers.. ?

If I understand that correctly, yes.

- shows 5 workers after restart & re-enable on XI (no jobs waiting for 2 hosts out of local) / mod_gearman2_worker is not recognized as service for some reason

It is mod-gearman2-worker, not mod_gearman2_worker!

Right, problem in between chair and the keyboard in my case
- service status works.

How to verify and confirm checks running on Worker (and not locally)?
- just created new worker. Did not install any plugins (on purpose)
- configured nsclient/nrpe checks agaisnt the new host (host in local hosts group / services in the remote site group)
- all green and working 8-\ where they really should not

[bheden]

How to verify and confirm checks running on Worker (and not locally)?
- just created new worker. Did not install any plugins (on purpose)
- configured nsclient/nrpe checks agaisnt the new host (host in local hosts group / services in the remote site group)
- all green and working 8-\ where they really should not

What did you set the hosts/services definitions to on the new worker? What did you set the hostgroups/servicegroups queues to on the new worker?