New host/service properties for return_code modulation

[Thomas Guyot-Sionnest]

On 29/12/09 02:21 AM, nap wrote:
> On Sat, Dec 19, 2009 at 7:15 AM, Thomas Guyot-Sionnest <dermoth at aei.ca> wrote:
>> On 18/12/09 09:47 AM, nap wrote:
>>> But It need 2 times checks and 2 times services too. I think we can
>>> nearly divide by 2 the number of services with a new host/service
>> I solved this with custom macros. In your root service template, add a
>> blank macro called _NEGATE, then whenever you need to negate a service
>> set _NEGATE to the full path and command to "negate" and arguments
>> (Note: macros aren't enabled there).
>>
>> Then in your command definition, before the actual command add
>> $_SERVICENEGATE$. This actually give more flexibility as sometimes you
>> need different negate options.
> Isn't it more simple to explain to a new user that it's qualification
> environment can be set with critical_is_warning = 1 instead of a
> custom macro (quite an advance topic)?

While this is true, over time you may end up with so many "custom" 
options users will get lost anyway. That's why IMHO Nagios should favour 
generic, flexible methods of doing customizations over specific 
inflexible ones. OTOH we should include some "Nagios recipes" in the 
documentation explaining exactly how these specific tasks can be 
achieved using current methods.

>>> property : critical_is_warning. For the host, the only interest is to
>>> be inherited by the service (an host DOWN is always important, no 2->
>>> 1 here). And in a qualification host, nearly all services are in low
>>> priority (max = Warning), but some can be still Critical (like
>>> security services). So this property need to be add to the host for
>>> service implicit inheritance (default = 0) and to service (default =0
>>> too) to be set at 1 for trully important services.
>>>
>>> The hot_period can be add in host and service too (same for implicit
>>> inheritance). the idea is to "tag" low priority host with
>>> critical_is_warning. But some hosts are production just in some
>>> periods (like at the end of the month for financial servers). So you
>>> put hot_period in host (or service) and in this period critical is
>>> still critical. So In all the other times, this low level host is a
>>> low level host. If not specified, there is no hot_period (so always
>>> low level).
>> I'm not necessarily arguing against this one, but IMHO time periods
>> cover this pretty much. Using service escalations in conjunction with
>> timeperiods allow you sending alerts to different places (ex pager vs.
>> email) depending on time/date. Furthermore changing the returned result
>> of a plugin based on date/time might be more confusing as when a state
>> change occur you'd normally assume that the checked item actually changed.
>>
> You speak about notifications, I speak about alerts. Try to explain to
> a manager seeing a red alert in the console that the problem is not so
> important because in this period it's not important. He will say :
> "so, why isn't it a warning?" But we must think about the impact on
> the notifications.
> 
> It's not so confusing IMHO with the name : hot_period mean what it mean.

Then maybe we should find a more generic way... some kind of state 
modifier objects: you'd give the target state, the substitution state 
and a timeperiod for it. This would be much more useful as where would 
be many other things you'd be able to do with them.


Another more hacky solution (in the mean time) would be changing plugin 
parameters on-the-fly. Nagios-plugins extra-opts can be very useful for 
that - just swap a specific plugin configuration file whenever you need 
different settings.

-- 
Thomas

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev