• About schedule.cf
• Schedules
  • About Schedules
  • Dependencies
  • Schedule Stanza Keywords
  • Examples
• Alert Plans
  • About Alert Plans
  • Dependencies
  • Alert Plan Stanza Keywords
  • Examples
• Alert Plan Aliases
  • About Alert Plan Aliases
  • Dependencies
  • Alert Plan Alias Stanza Keywords
  • Examples
• Return Groups
  • About Return Groups
  • Dependencies
  • Return Group Stanza Keywords
  • Examples
• Alert Throttle
  • About Alert Throttle
  • Dependencies
  • Alert Throttle Stanza Keywords
  • Examples
• Alert Shift
  • About Alert Shift
  • Dependencies
  • Alert Shift Stanza Keywords
  • Examples

     <day> : "sunday" | "monday" | "tuesday" | "wednesday" | "thursday" |
                "friday" | "saturday"
     <name> : [a-zA-Z0-9\.+%@_-]+
     <number> : [0-9]+
     <interval> : <number> "second[s]"|"minute[s]"|"hour[s]"|"day[s]"|"week[s]"
     <time> : [<day>] [0-2][0-9]:[0-5][0-9]
  

schedule.cf defines Schedules, which define periods of time and intervals for that period of time, Alert Plans, which define behaviors for when a Check returns an error, Alert Plan Aliases, which allow Alert Plans to be reused with a different Call List, Return Groups, which group together return codes for easier reference, Alert Throttle, which restricts the number of alert notifications that can be queued for transmission at one time, and Alert Shift, which offsets the times in a Schedule definition for use with Alert Plans.

     schedule <name> {
         ([from <time> until <time>] (every <interval> | never) |
	  at { <time> ... })
         [...]
     }
 

About Schedules

If more than one time period/frequency pair is specified in a Schedule, the first time period matched will be used.

Schedules are used to determine when Checks are executed, form the building blocks of Alert Plans, and serve some other purposes.

Dependencies

• None.

Schedule Stanza Keywords

Examples

1. First, some example time periods. These would be specified within a Schedule definition, examples of which appear below.
   • from 08:30 until 16:59
     The time period from 8:30am through (and including) 4:59pm every day.

   • from monday 08:00 until friday 16:59
     The time period from 8:00am on Monday through 4:59pm on Friday. Inverting the order is a useful way to specify weekends.

   • from friday 17:00 until monday 07:59
     The time period from 5:00pm Friday through 7:59am Monday. The reason to end at 7:59 is that the Schedule is in effect through the end of the time specified, in this case 7:59:59. This allows another time period to be specified beginning at 08:00 without conflicting.

2. Next, some example frequencies. These would be specified within a Schedule definition, examples of which follow.
   • every 30 minutes
   • every hour
   • never

3. A Schedule defining a frequency of every hour from 8:00am until 9:59pm. A Schedule like this can be used to specify when a Check runs, or it can be used within part of an Alert Plan to determine how often alert notifications should be transmitted.

        schedule sample1 {
          from 22:00 until 07:59 never
          from 08:00 until 21:59 every hour
        }
        

4. A Schedule defining a frequency of every 15 minutes at all times weekdays, and every 30 minutes on weekends.

        schedules sample2 {
          from saturday 00:00 until sunday 23:59 every 30 minutes
          every 15 minutes
        }
        

5. A Schedule defining an explicit time (an at Schedule) with an implied frequency of once. A Check using the following Schedule would execute Mondays at 9:30am and every day at 5:30pm.

        schedule sample3 {
          at { monday 09:30 }
          at { 17:30 }
        }
        

6. A Schedule to define nights and weekends.

        schedule sample4 {
          from friday 22:00 until monday 07:59 every hour
          from 22:00 until 07:59 every hour
        }
        

     alertplan <name> {
         (on return value[s] <number> [...] |
	  on returngroup <name> |
	  default) {
	     [after <number> check failure[s]]
	     using <name> schedule {
	         try [<number> time[s]] {
		     [allow <number> failed host[s] [during <name> schedule]]
		     (alert <name>
		      [...]
		     |attempt fix [if defined]
		      [tell <name>
		       [...]])
		     [flag escalated]
		 }
		 [...]
	     }
	 }
         [...]
	 [notify [using <name> schedule] on clear | do not notify on clear]
	 [do not clear state on return values { <number> [...] }
	 |always clear state]
	 [clear state honors returngroups { <name> [...] }
	 |clear state honors all returngroups
	 |clear state ignores returngroups]
     }
 

About Alert Plans

Dependencies

• The Call List specified by the alert or tell keywords must be defined in calllist.cf.
• The Schedule specified by the using keyword must be defined by a schedule stanza before the Alert Plan that uses it is defined.

Alert Plan Stanza Keywords

 # Require all Checks to fail twice before any Alert Plan does anything.
 default after 2 check failures

 alertplan sample1c {
   on return values 1 5 {
     using sample1 schedule {
       ...
     }
   }
   default {
     using sample1 schedule {
       ...
     }
   }
 }
 

 # Notify on clear for all subsequent alertplans
 default notify using sample1 schedule on clear
 

 alertplan sample1d {
   default {
     ...
   }
   do not notify on clear
 }
 
 # Or turn it off for all subsequent Alert Plans
 default do not notify on clear
 

 # Don't clear state if a module is misconfigured
 default do not clear state on return values { 4 }
 

 alertplan sample1e {
   default {
     ...
   }
   always clear state
 }
 
 # Or always clear state for all subsequent Alert Plans
 default always clear state
 

 # define a returngroup
 returngroup problem { 1 5 }
 
 # PROBLEM and TIMEDOUT are basically the same, so don't clear state
 # if the return code swaps between them
 default clear state honors returngroups { problem }
 

 default clear state honors all returngroups
 

 alertplan sample1f {
   default {
     ...
   }
   clear state ignores returngroups
 }
 
 # Or always clear state for all subsequent alertplans
 default clear state ignores returngroups
 

Examples

1. First, the basic structure of an Alert Plan consists of one or more return value stanzas, which define actions according to the return values obtained from the Check modules. In the following example, three different return values stanzas are specified: one for return values 1 and 5 (generally interpreted as PROBLEM and TIMED OUT), one for return value 4 (MISCONFIGURATION), and one for any other return value:

        alertplan sample1 {
          on return values 1 5 {
            ...
          }
          on return value 4 {
            ...
          }
          default {
            ...
          }
        }
        

2. Notification on clear is also set at the top level of an Alert Plan. In this example, when this Alert Plan is used and when the sample1 Schedule is in effect, notification will be sent when a problem clears:

        alertplan sample2 {
          on return values 1 5 {
            ...
          }
          default {
            ...
          }
          notify using sample1 schedule on clear
        }
        

3. Each return value stanza holds instructions on when to transmit alert notifications. In this example, two consecutive Check failures are required before any requested alert actions are taken, and then only if the sample1 Schedule is in effect.

        alertplan sample3 {
          on return values 1 5 {
            after 2 check failures
   
   	 using sample1 schedule {
   	   ...
   	 }
          }
          default {
            after 2 check failures
   
   	 using sample1 schedule {
   	   ...
   	 }
          }
        }
        

4. This next example illustrates the use of multiple try stanzas to handle escalations:

        alertplan sample4 {
          default {
            using sample1 schedule {
   	   try 2 times {
   	     # Alert the first level response list not more than two times
   	     # after the check has failed twice during the sample1 schedule.
   	     alert oncall-list
   	   }
   	   try 2 times {
   	     # Consider the alert escalated and alert the second level
   	     # response list not more than two times since the first level
   	     # response list has not cleared the problem.
   	     alert backup-list
   	     alert oncall-list
   	   }
   	   try {
   	     # Consider the alert escalated and alert the oncall managers
   	     # until the problem clears.
   	     alert oncall-list
   	     alert backup-list
   	     alert managers
   	     flag escalated
   	   }
   	 }
          }
        }
        

5. This example tries the predefined Fix before escalating:

        alertplan sample5 {
          default {
            using sample1 schedule {
   	   try 1 time {
   	     attempt fix
   	     tell oncall-list
   	   }
   	   try {
   	     alert oncall-list
   	   }
   	 }
          }
        }
        

     alias <name> to <name> (replacing <name> with <name>
                            |adding <name>)
 

About Alert Plan Aliases

Dependencies

• An Alert Plan must be defined before it can be aliased.

Alert Plan Alias Stanza Keywords

Examples

1. In this example, the sample4 Alert Plan defined above is reused, but net-oncall becomes the first Call List, instead of oncall-list.

        alias sample4 to sample6 replacing oncall-list with net-oncall
        

2. In this example, net-oncall is added in addition to oncall-list (and all the others) rather than replacing it.

        alias sample4 to sample7 adding net-oncall
        

     returngroup <name> { <number> ... }
 

About Return Groups

Dependencies

• None.

Return Group Keywords

Examples

1. In this example, return codes 1 and 5 are defined into one Return Group, which is then used in a simple Alert Plan.

        returngroup problem { 1 5 }
   
        alertplan simple {
          on returngroup problem {
            using halfhourly schedule
   	 try { alert rotating }
          }
        }
        

     throttle <number>
 

About Alert Throttle

If the throttle keyword is not specified in schedule.cf, the default value of 10 will be used.

If an Alert Plan specified that two or more Call Lists are to be notified, that is considered one "logical" alert notification for purposes of calculating the Alert Throttle.

If a clear alert notification is not queued because the Alert Throttle has been reached, that alert will not be requeued because the no longer valid alert state must be cleared by the scheduler.

Dependencies

• None.

Alert Throttle Keywords

Examples

1. In this example, no more than two alert notifications per minute are permitted:

        throttle 2
        

     alert shift <number> <interval>
 

About Alert Shift

Dependencies

• None.

Alert Shift Keywords

Examples

1. In this example, Checks using the sample1 Schedule will execute at 9:30am, while Alert Plans using the same Schedule will execute at 9:32am.

        alert shift 2 minutes
        
        schedule sample1 {
          at { 09:30 }
        }
        

Next: host.cf