[icinga-users] organizing remote passive checks?
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
> 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
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
- 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.
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
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)...
> 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.
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> icinga-users mailing list
> icinga-users at lists.sourceforge.net
DI (FH) Michael Friedrich
mail: michael.friedrich at gmail.com
jabber: dnsmichi at jabber.ccc.de
irc: irc.freenode.net/icinga dnsmichi
icinga open source monitoring
position: lead core developer
More information about the icinga-users