[icinga-users] organizing remote passive checks?

Simon Oosthoek soosthoek at nieuwland.nl
Wed Jan 23 12:25:09 CET 2013

On 01/22/2013 07:56 PM, Michael Friedrich wrote:
> On 22.01.2013 10:12, Simon Oosthoek wrote:
>> On 01/21/2013 09:43 PM, Michael Friedrich wrote:
>>> On 21.01.2013 15:30, Simon Oosthoek wrote:
>>>> Translating this to how I would administer this, I would apparently have
>>>> to keep two separate configuration entries for the same host, one for
>>>> the central server and one for the distributed check on the remote
>>>> server. (If the central server _can_ do active checks, the configuration
>>>> may not be different).
>>>> How does one keep this consistent?
>>> with different automated distribution methods (git, puppet, etc) or by
>>> hand with one central config, but different master templates, if you
>>> require parts of your master server to actually run checks too.
>>> if you do not want to let the master run any checks, globally disable
>>> the host and service check execution, only let freshness checks happen
>> In that case you would keep the service and host configurations the
>> same, but globally disable the checks from being run? What happens with
>> freshness checks?
> freshness checks are only skipped if both, checks_enabled and
> passive_checks are disabled. this like shouldn't be the case in your setup.

I should clarify that with passive checks I meant "check_dummy 2 
'service is stale'" when the freshness runs out (when the remote server 
loses contact with the central server).

But in general I get the idea of what you meant. That freshness is 
always checked, unless you also turn off passive checks on the central 

If the central server does checks on a different subset of hosts, then 
this might be problematic, since you can't disable checks at the server 

>> I'm having a bit of trouble understanding this part. I can see the
>> benefit of allowing empty hostgroups, as this allows you to add members
>> from the host definitions instead of centralised. Sometimes this may
>> result in empty hostgroups, especially if some groups don't occur at the
>> remote server. Is this what you meant?
> I know many people using this sort of object trick, also in their
> distributed setups. It was meant to be mentioned, but tbh I never fully
> understood that approach myself. You'll find me on the template side of
> life, having groups only for views on the gui, but not for some config
> inherit voodoo. By example, it does not work to assign services to a
> hostgroup, add a hostgroup member into it, and add the hosts into the
> sub hostgroup - that link between master and child hostgroup
> service-host does not work, and that's a limitation when using such
> tricks - the core was not designed to allow such tricks, and icinga2
> will be no exception on that, focussing on heavy templating as well
> (though, in a more logical way).
> So, generally speaking this could help at the moment, but I do not
> recommend to organize the configuration like that. rather keep the
> existing one, and find a master template for the active/passive part.

When reading the documentation about tricks (it's a little worrying to 
have this called "tricks" ;-) I interpreted this as meaning something 
analogous with Venn diagrams 
(http://en.wikipedia.org/wiki/Venn_diagram). (The hostgroups are the 
sets and the hosts can be a member of a set. The services are assigned 
to the hostgroups using the hostgroup_name directive)

So when I create hostgroups for certain kinds of service combinations, 
making a host a member of such a group would add the checks for this 
service combination to its checks.

So for example, I'd have templates for linux and windows servers, in 
which some standard things are checked and if a host is also a 
webserver, I'd add it to the hostgroup "webservers" and it would 
check_http on that host. If it also is a mysql server, add it to the 
group "mysqlservers" as well and it would automatically get the mysql 
checks as well.

If this is not the right way to think about it, I'll have to re-read 
some of the documentation I suppose...

Doing the same with templates seems to me less flexible, as it would be 
necessary to define a hierarchy of templates which can then be used to 
derive an instance of a host from. I also don't see (or rather, know) 
how to attach service checks to templates using something other than 
hostgroup_name, which brings us back to my interpretation of Venn 
diagrams ;-)

This is getting a bit off topic, but I'd love to know if my thinking is 

If it's unclear what I mean, I can try to provide pictures or example 
configs to explain...

Cheers (and thanks for your detailed e-mails!)


More information about the icinga-users mailing list