# Sample schedule.cf file

# The first item in this file restricts the number of messages
# that can be transmitted each minute.  This helps to reduce
# runaway paging.  After the maximum throttle value has been
# reached, any remaining alerts are queued until the next
# pass (about a minute).  The default value is 10.  A value of
# 0 indicates no throttling.

throttle 5

# The alert shift value is a useful way to avoid some confusing
# situations regarding schedules.  If a check and an alertplan
# both use a schedule that runs from 08:30 until 17:59, it is
# possible that at 08:30 an alert will be sent out before a
# check runs that would clear out that state (ie: the alert is
# sent out at 08:30:03 but the check is run at 08:30:25).
# The alert shift simply adjusts the times for schedules when
# they are used in an alertplan.  In the above example, the
# check would still run from 08:30 until 17:59, but the
# alertplan would be in effect from 08:32 until 18:01.

alert shift 2 minutes

# Some sample schedules.  A schedule is used to determine
# when to execute a check, and is incorporated into alertplan
# definitions for determining when to execute alerts.

schedule critical {
  every 15 minutes
}

schedule standard {
  from friday 22:00 until monday 07:59 every 2 hours  # weekends
  from 22:00 until 07:59 every hour		      # weeknights
  every 30 minutes				      # weekdays
}

schedule workday {
  from 18:00 until 08:29 never
  from monday 08:30 until friday 17:59 every hour
  # since saturday and sunday 08:30 until 17:59 is not defined,
  # these times count as "never"
}

schedule daytime {
  from 06:30 until 21:59 every 30 minutes
}

schedule overnight {
  from 22:00 until 06:29 every 30 minutes
}

# This is a schedule like all the ones defined above, except
# that it will be used to specify when notify on clear is in
# effect for all services.  When it is not in effect, any
# local notify on clears will still be in effect.  The "every
# hour" is ignored by the scheduler for notify on clear, but
# would be honored if this schedule were used elsewhere.

schedule upalert {
  from 09:30 until 21:30 every hour
}

# This schedule is used in calllist.cf

schedule rotation {
  at {
    monday 12:00
  }
}

# Now specify notify on clear for all services, during the day.
# This default will apply from this point in the file until
# changed again or until the end of the file.  The default can
# be overridden within each alertplan.  To subsequently disable
# notify on clear, use "do not notify on clear".

default notify using upalert schedule on clear

# Next, some alert plans will be defined.  Alert plans are
# defined in terms of return codes generated by check modules.
# Some of these return codes mean more or less the same things
# as far as sending out alerts, and returngroups allows these
# return codes to be grouped together to simplify alert plan
# specifications.

# 1 is MODEXEC_PROBLEM, 5 is MODEXEC_TIMEDOUT
returngroup problem { 1 5 }

# 2 is MODEXEC_WARNING, 3 is MODEXEC_NOTICE
returngroup warning { 2 3 }

# This first example alertplan is a sample for noncritical
# services.  Anytime two or more consecutive check failures
# occur, an alert will be sent to the sysadmins.
# The calllist must be defined in calllist.cf.  The schedule
# must be defined above, in this file.

alertplan noncritical {
  default {
    after 2 check failures
    using workday schedule {
      try { alert sysadmins }
    }
  }
}

# Since we're going to be using 2 check failures as the
# basis for the rest of the alertplans here, we'll set it
# as the default, which would otherwise be 1.  This default
# can be overridden within the alertplan (as the noncritical
# example does, above), or changed later by adding another
# of these lines with the appropriate value.

default after 2 check failures

# This next example is a sample for critical services.  When an error
# in the returngroup problem (MODEXEC_PROBLEM or MODEXEC_TIMEDOUT) is
# generated two or more times, up to five alerts are sent to the
# oncall list, according to the critical schedule.  If the problem is
# not resolved or acknowledged then the problem will escalate to the
# managers, with the oncall group still receiving notification.  If
# the error is not a problem, it will go to the sysadmins.

alertplan critical {
  on returngroup problem {
    using critical schedule {
      try 5 times {
        alert oncall
      }
      try {
        alert oncall
	alert managers
      }
    }
  }
  default {
    using standard schedule {
      try { alert sysadmins }
    }
  }
}

# The next example is useful for a service where a single
# host can fail in the middle of the night and not affect
# service.  No alerts would be sent overnight unless a
# second host failed.

alertplan replicated {
  on returngroup problem {
    using standard schedule {
      try {
        allow 1 failed host during overnight schedule
        alert oncall
      }
    }
  }
  default {
    using standard schedule {
      try { alert sysadmins }
    }
  }
}

# This is a slightly more complicated replicated alertplan.  "degraded
# mode" is again only used at night, but additionally escalations will
# not happen overnight either.  During the day, a single failure would
# generate an alert.

alertplan replicated2 {
  on returngroup problem {
    using daytime schedule {
      try 5 times {
        alert oncall
      }
      try {
        alert oncall
	alert managers
      }
    }
    using overnight schedule {
      try {
        # We don't need to specify a schedule for degraded mode since
	# this block will only apply during the overnight schedule anyway.
        allow 1 failure
        alert oncall
      }
      # Don't escalate at night
    }
  }
  default {
    using standard schedule {
      try { alert sysadmins }
    }
  }
}

# This is a simple alertplan that executes fixes.  Fixes can, of
# course, be incorporated into more complex alertplans.  "tell"
# essentially means the same thing as "alert", but the two cannot be
# used interchangeably.

alertplan simplefix {
  default {
    using standard schedule {
      try 1 time {
        attempt fix
	tell oncall
      }
      try {
        alert oncall
      }
    }
  }
}
