Creating different notification periods for warning/unknown vs critical.

Jim.Melin at co.hennepin.mn.us Jim.Melin at co.hennepin.mn.us
Thu Jan 17 15:48:41 CET 2008


define service{
        name                            clam-AV-service
        use                             generic-service
        check_period                    24x7
        max_check_attempts              3
        normal_check_interval           90
        retry_check_interval            90
        contact_groups                  Clam_AV, operators
        notification_options            w,u,c,r
        notification_interval           90
        notification_period             24x7
        register                        0
        }

I have the above service template. Sometimes the AV scans take longer than 4.5 hours to run and nagios sends an e-mail when one of the services is in
an unknown status (this is coming from a custom check script I wrote, that interfaces with the output of a clam-AV front end I also wrote).

We really only care to notify about warning and unknown status from the service checks that use this template between the hours of 6 am and 6, but we
care about critical alerts (it found a virus or scan hasn't run in x datys or freshclam has not run in y days) 24x7.

Is there a way to do mixed notifications so that warnings/unknown use time period 'workhours' and criticals/recovery use '24x7' in the same service
template?

Otherwise my choices are increase the check attempts or not notify between 6pm and 6am for everything.

Any input greatly welcome.

-J


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
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