Overriding notification contacts

J.M. jm+nagios-users at roth.lu
Wed Sep 1 14:31:03 CEST 2010


Assaf Flatto <nagios <at> flatto.net> writes:

> > [ wildcard def here ]
>>
> > Now suppose there are services for a few hosts that would need to have a
> > different check_period (they have, in hosts.cfg).
> >
> > What would be the most elegant way to accomplish that without adding too 
> >many new services?
>>
>> Would/could the check_period maybe be inherited from the host? 
>> Don't think so.
>>
>> As far as I can see, just adding the concerned services with a specific host
>> will only result in duplicate service definition warnings. Unless one would 
>> have to remember removing those specific hosts from the wildcard service 
>> while
>> defining the more specific service. In that scenario some kind of override
>> would
>> be cool.
>>
>>
> An alternate template with the changed parameter could do the trick .
> 
> this will mean you build another template with another time period for 
> the check and use that template for the services you need.
> 
> Since the service in your example is a template and not and active one - 
> there should be no conflicts .
> 

Hi,

Can you elaborate or maybe show an example taking the above as a basis?

The problem I have is that I can't leave the "host_name *" definition which is
nice to have (no hosts are ever forgotten).

Since in the example above, I inherit the wildcard in "std_ping" from "std", 
I'm not sure what easy way there would be to define exceptions....

JM


------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
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





More information about the Users mailing list