notification_interval < normal_check_interval

[Mike Chesnut]

On 04/18/2011 12:08 PM, Paul M. Dubuc wrote:
>
> Mike Chesnut wrote:
>> I have a check that I only want to occur once a day, so I do this in the
>> service definition:
>>
>>            normal_check_interval   1440
>>
>> However, when it fails, I want it to retry every 10 minutes, so I do this:
>>
>>            retry_check_interval    10
>>
>> My default notification_interval is set to 15.  When I run a pre-flight
>> check, I get this:
>>
>> Warning: Service '<service>' on host'<host>'  has a notification
>> interval less than its check interval!  Notifications are only re-sent
>> after checks are made, so the effective notification interval will be
>> that of the check interval.
>>
>> Is that warning telling me that notifications are only sent when a
>> normal check occurs?  What I want is for in the event of a failure,
>> notifications to continue to be sent (every 15 minutes) until the
>> service recovers.  Will that be the case?
>>
>> Thanks,
>> Mike
>>
>
> What is the value of max_check_attempts?  It's at the end of that number of
> checks that the service enters a hard state and a notification is sent.  If
> the value is 1, then the warning makes perfect sense because no retry checks
> will be done.

max_check_attempts is 2.  Is that a sensible number here?

Thanks,
Mike

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
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