New host/service properties for return_code modulation

[nap]

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:
>> There are some proposal of new properties for hosts/services:
>> *critical_is_warning (host, service, implicit inheritance from host to service)
>> *hot_period (host, service, implicit inheritance from host to service)
>> and:
>> *inverse_ok_critical (service only).
>>
>> Theses properties are used for no production hosts.
>>
>> == Qualification and developement hosts ==
>> There something I use to do : the Critical state is for Production
>> only. When someone see the Nagios web site, a red mean : "to do now".
>> Orange is "must be done". But a Red in a qualification host can be
>> less important than a warning in a production server.
>>
>> That why all my checks are double :
>> normal command :
>> $USER1$/check_blabla -h $HOSTADRESS$
>>
>> qualification command:
>> $USER1$/nocritical.sh "$USER1$/check_blabla -h $HOSTADRESS$"
>>
>> nocritical.sh is a dumb script that launch $1 and if return_code == 2
>> -> return_code =1.
>
> You should use "negate" - it comes with the official plugins and was
> written specifically for this. Newer versions are more customisable and
> can even change the status text as well.
>
>> 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)?

>
>> 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.

> --
> 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
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>

------------------------------------------------------------------------------
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