[icinga-users] organizing remote passive checks?

Simon Oosthoek soosthoek at nieuwland.nl
Wed Jan 23 16:59:06 CET 2013

On 01/23/2013 01:01 PM, Michael Friedrich wrote:
> On 23.01.2013 12:25, Simon Oosthoek wrote:
>> 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).
> Yep, I did a little research yesterday, asked colleagues at netways, and
> so on. On the LConf part i was wrong with my assumption that killing off
> global active checks would be a solution.
> It's rather more of an export trick used, which misses documentation as
> well.
> in short
> - add a tree node with 2 attribute, lconfactiveservicechecksenabled 0
> and a special description for LCONF->EXPORT->MODIFY->SERVICE with enabled 1
> - do not set those attributes in sub nodes or hosts or services
> - lconf export will generate the master config based on the normal
> configuration, lconf slave export will take care of modifying all slaves
> to enable active checks again
> the long version will be in the docs, last resort is release 1.3
> This still lacks off the passive check command replacement mentioned
> above, where i need to find a suitable solution as well.

Ok, so this is more or less the same type of fix I was thinking of with 
a script running over a checked out repository (changing the 
check_command for the services that cannot be actively checked from the 
central host).

>> 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.
> Yep, that's what this does. Though, as noted, you cannot inherit those
> service->hostgroup relation to hostgroup members in termins of a child
> hostgroup.
> i.e
> svc1--->  hg1  ---member--->host1
>            /
> svc2----/
> means that host1 will get svc1 and svc2 from hg1 attached.
> if you create something like this.
> svc1--->  hg1
>            / \
> svc2----/   \
>                \member
>                 hg2 ---member---->host2
> means that hg1 knows svc1 and svc2 as services, but hg2 doesn't. so
> host2 is in hg2, but does not get any services.

Up till now I wasn't even considering hostgroups as members of 
hostgroups ;-)

How I had it in mind is more like:

svc1--->  hg1  ---member--->host1

svc1--->  hg1
          / \
svc2----/   \
              \member---- host1
svc3--->  hg2
           / \
svc4----/    \---member---->host2

so host1 gets svc1..svc4 and host2 gets only svc3 and 4

I haven't tried this yet on a (recent) icinga install, so it's only 
theoretical for now.

> this is a code specific implementation on object inherits, and i did not
> look into it how difficult it would be to change. mainly also for
> maintenance and support reasons - we want to create something certainly
> new, getting away from such nested sets of hostgroup tricks, rather more
> with easy template objects where you can easily add services to host
> templates, using those in the host definiton.
> see
> https://wiki.icinga.org/display/icinga2/Installing+Icinga+2#InstallingIcinga2-SpecialTemplates

Looks like the configuration files for icinga2 will be quite different, 
is documentation already available for the new syntax?

>> 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 ;-)
> Yep, for the easyness and lazyness, templates in the 1.x design are not
> expected to be fun. Though, if you like to, play around with the Icinga2
> Tech Preview which introduces a new format - not for your prod setup,
> but just for some feedback to team icinga, about the look, feel and usage.
> More on that here -
> https://wiki.icinga.org/display/icinga2/Installing+Icinga+2
> Though for the moment, you may experiment with the venn diagram attempt.

That link doesn't seem to explain service checks with host_group members 
for services that are not host specific, like webservers, which can be 
run on any platform.

I'll see if I can experiment with a real system in the near future, but 
somehow the circumstances aren't favourable here for that at this time :-(



More information about the icinga-users mailing list