The include directive provides an easy and powerful way to reuse settings that are common to many events. What follows are some simple ways to leverage the include directive with a number of benefits:
- Reduce boilerplate settings.
- Make wholesale updates trivial.
- Add clarity to certain kinds of events.
For the purposes of this article, many of the includeable events will be anchored under in the events tree at
Then, to include in an event file:
One of the most common uses of failover events is to send notifications. But, if there are problems going on, perhaps across multiple hosts, it is critical that the host on which the failover event is run is reliable. If a single failover event is being used, then the
host setting can be set to the reliable host. But, if multiple failover events are being used, it may be preferable to have a basic failover event be defined which can be included by the others:
This can then be used by the various failover events:
An alternative would be to use a variable in an event file:
and include it and reference the variable:
In an environment running parallel systems: development and production, there are times when the production system becomes unavailable because of planned maintenance or unplanned events such as power failure or hardware failures. Being able to deal with such situations easily and quickly may be required to meet critical needs.
One way to handle this is to encode a host name in the event name. For example, if an event is defined at
hosta can be used as:
and when/if a switchover is needed, a simple rename and reload would be done:
Alternatively, the include directive can be used. Starting with an includeable event:
it can be included as:
and a switchover be done by changing the
/includes/runhost event and a reload:
Each method has its pros and cons. The main pro for using an include file is that the event tree does not need to be changed, only the include file.
Advanced and Easy Switchover
Unlike the event name method, the include file method can be extended to handle many hosts by using variable names:
and for the various suite event files:
Then the settings in the
/includes/runhosts event can be updated as needed to deal with maintenance, outages, or relocation of systems:
Variations and combinations of the above are also possible.
In an enterprise context, it is not unusual for email to be sent as notification when an event fails. If there are a lot of events, then the recipient must be specified in each. As well, there may be different recipients for different kinds of failures. This can be easily handled using include events.
To handle situations that need the attention of the person on pager a dedicated pager email is often set up. An alternative is to set up a includeable event snippet with the setting:
Suppose a suite of events can fail with a variety of severity levels: warning, serious, emergency.
In each case, a different recipient is specified and a different message is specified.
Times, Days, and Dates
There are a handful of standard
when_* settings that many events use:
- every minute
- every hour
- every day
These can be set up as:
A notification event using one of these:
If one of the settings is not suitable, it can be overridden (e.g., at the 30m mark is preferred over the 0m mark) :