Hi Martin,
The escalation_options don't take the state into consideration during the
notification count. So if you have an escalate rule on the 4th notification
and only escalate on Critical in the escalation_options then following
scenario is can occur:
You have 3 warning notifications and the 4th is Critical then it will
escalate as there have been 4 notifications and a Critical. I posted a help
request on this issue a week or two ago and would really like this to be
patched or built into the next update.
http://article.gmane.org/gmane.network.nagios.user/64997/match=escalation+state
Cheers,
Neil
On Sat, Nov 7, 2009 at 12:56 AM, Martin Melin <mme...@gmail.com> wrote:
> The existing escalation_options directive in escalation definitions will
> likely get you this behavior without the need for a patch.
>
> http://nagios.sourceforge.net/docs/3_0/escalations.html - see the very
> bottom of this page as well as the object definition documentation for
> escalation_options.
>
> Regards,
> Martin Melin
>
>
> On Fri, Nov 6, 2009 at 3:49 AM, Mark Gius <mg...@createspace.com> wrote:
>
>> Currently, service notifications contain "first/last_notification"
>> directives, that specify the range of notifications that the escalation
>> should apply to. This method of escalation has a weakness however.
>>
>> At my work, we let warnings go to the default contact (which happens to
>> be email), and escalate to a pager chain on critical. However, if a
>> service sits in WARNING for a length of time (which is likely to happen
>> in the middle of the night), by the time the service enters a CRITICAL
>> state the notification count exceeds our highest escalation, and our
>> entire team gets paged immediately.
>>
>> What I'd like to see is the ability to distinguish between a WARNING
>> notification and a CRITICAL notification in the escalation, and set up
>> escalation chains that work based on the number of CRITICAL's that have
>> been sent, as opposed to the total number of notifications.
>>
>> I am planning on patching nagios to support this behavior if there isn't
>> a way to achieve this behavior with the current implementation. My plan
>> is to add a warning/critical count to service, add a first/last
>> warning/critical state to service escalations, and add the directives
>> "(first|last)_(warning|critical)_notification" to the service escalation
>> configs. The idea is also to keep the current behavior
>> (notification_count and first/last_notification would still be present),
>> but allow finer grained control over when escalations are sent out.
>> This way if somebody didn't want to use the finer grained control their
>> behavior would stay the same. My current plan is to match the
>> escalation if _any_ of the 3 notification ranges match
>> (all/warning/critical).
>>
>> Any advice on making this behavior happen with Nagios as-is, or
>> suggestions/advice on the implementation are welcome.
>>
>> -Gius
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Nagios-users mailing list
>> Nagios-users@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
>>
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Nagios-users mailing list
> Nagios-users@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
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Nagios-users mailing list
Nagios-users@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
