[icinga-users] organizing remote passive checks?

Michael Friedrich michael.friedrich at gmail.com
Wed Jan 23 13:01:39 CET 2013

On 23.01.2013 12:25, Simon Oosthoek wrote:
>> 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).

Yep, I am currently sitting in front of an LConf setup with such a 
question of different checkcommand for the passive master.

See my feature request here https://www.netways.org/issues/1866

> 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
> server.
> 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
> level.

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 

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.

(the most common approach to use lconf is for it being a config editor, 
but the possibilities for distributed setups are way more than described 
on the documentation).

> 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.

Yep, that's what this does. Though, as noted, you cannot inherit those 
service->hostgroup relation to hostgroup members in termins of a child 


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

means that host1 will get svc1 and svc2 from hg1 attached.

if you create something like this.

svc1--->  hg1
          / \
svc2----/   \
               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.

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.


> 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 - 

Though for the moment, you may experiment with the venn diagram attempt.

I may finish up my work on LConf next week, which will require some 
documentation updates as well for 1.3 release, but first off, I need to 
bring this 10k setup into prod state ;-)

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

not really, it still targets the initial question about how to organize 
distributed setups with remote slaves sending checkresults...

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

everything is possible, i am just lacking off reponse times within 24h 
(you're lucky this time)...

kind regards,

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

PS: keep the discussion rolling, I am considering this a topic being 
asked quite often by the community, and there are purely some different 
approaches here. google bot will be lucky to add an index to this 
mailinglist thread then.

> /Simon
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d
> _______________________________________________
> icinga-users mailing list
> icinga-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/icinga-users

DI (FH) Michael Friedrich

mail:     michael.friedrich at gmail.com
twitter:  https://twitter.com/dnsmichi
jabber:   dnsmichi at jabber.ccc.de
irc:      irc.freenode.net/icinga dnsmichi

icinga open source monitoring
position: lead core developer
url:      https://www.icinga.org

More information about the icinga-users mailing list