Expand service group error in 43 line test config (why?)

[Paul M. Dubuc]

Eric B. wrote:
> My real problem I think is that I 'whittled' it down in the wrong way
> (thanks for the help, everyone). Below is what I was hoping to do, but
> realize that b/c I HAVE to define a host w/ the escalation, I have to
> retool how my monster config is done (which will really suck). Here's
> what I was hoping to accomplish:
>
> 1) Create a generic service template that all service checks inherit
> that adds them to the 'all-services' group.
> 2) Create escalation rules that apply to the 'all-services' group.
>
> This worked (basically a more complicated example of  the config I gave)
> until I added a 'all-services-foo' group (same method mentioned in #1
> and #2) with different escalations.
>
>  From a design perspective, I know Nagios does a great job w/
> templating, and object inheritance, but it really sucks that I have to
> specify a host; that just increased the amount of objects easily by an
> order or so of magnitude.
>

I don't see why.  All services have to be assigned to hosts anyway.  You can 
specify a comma separated list of hosts in your escalation or use hostgroups.
I think you only need 2 additional objects to do what you want:  A hostgroup 
that consists of all hosts with services assigned and a host template to 
assign hosts to that group.  There's an example that might help here:

http://sourceforge.net/mailarchive/message.php?msg_id=27615125


------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null