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