On 25.10.2012 16:51, Chris Wood wrote:
> Hi everyone,
>
> I'm new to this list, but I'm a long time user of nagios and now icinga.
> Over the years I've set up some reasonably large instances (hundreds
> of hosts, thousands of services)
>
> I'm in the process of overhauling an old nagios setup to icinga
> (nominally 1.7.1 as that is what is currently packaged for Debian).
during the freeze of wheezy, backports might not get updated. have a
peek at debmon.org as well then.
> I'm using what I've learned over the years to try and make the best
> use of the the nagios/icinga config file template and inheritance
> properties, to simplify my life in what will end up a system with over
> 200 hosts and perhaps 4000 services.
>
> I have hit an unexpected problem. It feels to me like the issue is
> with the parsing of the config files and how the inheritance is
> applied, but I don't rule out it actually being caused by some
> misunderstanding on my part.
>
> Want a challenge? Take a look at the config below and see if you can
> shed any light on why it doesn't work.
> Note - there are lots of words in this email - I've tried to be
> concise, but at the same time, I clearly need to explain my thinking,
> and what I have done.
> If you do choose to look, then I thank you in advance for your time
> and patience.
>
> [...]
>
> Having done the above, I ran a check on the config, confident that it
> would all work nicely.
> It did! erm, and it didn't.
> The config is parsed, and no errors are found.
> However, no services are defined against host_z any more.
> None at all.
Guess I am the only one who could follow here.
>
>
> So - to try and summarise the above in a few words:
> 1) If I include the hostgroups directly in my host they are correctly
> parsed, and my services exist
that's expected behaviour.
> 2) If I include those same hostgroups in another hostgroup via
> hostgroup_members, and then use that new hostgroup in my host, my
> services vanish, but icinga sees the config as valid (note I have
> allow_empty_hostgroup_assignment=1, and without this enabled, the
> parser decides the config has errors, due to hostgroups with no members)
the allow_empty_hostgroup_assignment config option was added on purpose
of allowing templates among distributed hosts, where you do not
necessarily have hosts assigned to those groups (think of the master
having them, the slaves do not have all assigned). this actually allows
you keep the same config templates over all instances, without having to
worry about those missing assignments during the config parsing on startup.
# ALLOW EMPTY HOSTGROUP ASSIGMENT FOR SERVICES
# This boolean option determines whether services assigned to empty
# host groups (host groups with no host members) will cause Icinga to
# exit with error on start up (or during a configuration check) or not.
# It's useful to be able to assign services to empty hostgroups when
# configuration files or pre-cached object files are distributed to
# various pollers, or when the process of generating Icinga config is
# automated, or when a set of services is slowly being phased out but
# should be kept around.
# The default behavior if the option is not present in the main
# configuration file is for Icinga to exit with error if services are
# associated with host groups that have no hosts associated with them.
#allow_empty_hostgroup_assignment=0
>
> From my reading of the documentation, it seems to me like what I'm
> trying should work.
> Am I wrong?
> Is the Icinga config parser wrong?
Basically you are trying to use one of the object tricks, adding
services to your hostgroups, then adding hosts to those groups, letting
them inherit all the services attached to that hostgroup. that actually
works, and is documented.
In the last call, you are trying to chain/nest hostgroups into a "super"
hostgroup, hoping that hostgroups inherit their attributes from each
other (namely all your services attached to g:host:passive:core:disk:1
and so on, which should then be inherited via hostgroup_members to the
super hostgroup g:host:passive:core:1 where you put host_z into).
That does not work, as hostgroups do not exchange/inherit attributes
from each other. So you are missing the bit in that one.
Can you point to the exact location in the documentation which did bring
you to that believe?
>
> One final note:
> I have worked around the issue for now
> Instead of my g:host:passive:core:1 hostgroup that contains all the
> priority 1 hostgroups, I have come up with another trick.
> I have set use_regexp_matching=1
> and now my host definition reads:
> define host{
> host_name host_z
> display_name some details here
> address 10.99.99.1
> hostgroups g:host:passive:core:.*:1
> use t:host:server,t:host:priority:1
> }
>
> This works a treat!
regex within the config are dangerous, and may break more than they are
helpful with. I'd rather go the option of config generators or tools,
like Markus mentioned LConf already - letting the tools figure the
chaining, and creation of many templates, interhits, and so on.
--
DI (FH) Michael Friedrich
mail: michael.friedr...@gmail.com
twitter: https://twitter.com/dnsmichi
jabber: dnsmi...@jabber.ccc.de
irc: irc.freenode.net/icinga dnsmichi
icinga open source monitoring
position: lead core developer
url: https://www.icinga.org
------------------------------------------------------------------------------
WINDOWS 8 is here.
Millions of people. Your app in 30 days.
Visit The Windows 8 Center at Sourceforge for all your go to resources.
http://windows8center.sourceforge.net/
join-generation-app-and-make-money-coding-fast/
_______________________________________________
icinga-users mailing list
icinga-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/icinga-users
