mod_notifs

This module listens in on the incoming vital updates and watches for changes in status. When a vital does change state, then the first thing mod_notifs does is grab the configuration for the task that the vital is being updated under. From this configuration, the Notification Type's configuration is retrieved, and the fun begins. These are the steps that mod_notifs takes when first noticing a vital changed status:

  1. Retrieve the notification type configuration from primary configuration file using the NotifType attribute associated with the running task.

  2. Check to see if the Ignore attribute is set to a boolean true value, and if so, the notification is discarded and processing stops.

  3. Record the notification in the pending notifications table, along with its timing information and the notification type. Execution of the vitals update then continues, leaving the nofication waiting until the notification thread can take care of her.

Every few seconds, the notification thread wakes up and checks for pending notifications. Then, for every pending notification the following series of steps is executed:

  1. See if this notification is new and has yet to be handled, if so we continue on. If it's been handled, we check to see if it's time for processing again, because its update interval has passed. If the update interval hasn't passed, then we move on to the next pending notification.

  2. Look for this pending notification in our collection of secondary notifications. This collection stores all notifications that are of lower priority than others because they are less severe. A node going down and it's PING vital failing is of higher priority than a service on that node becoming less healthy. If so, it's ignored.

  3. If we're a recovery notification, then delete any older, pending notifications for the vital that is recovering. This keeps those failure messages from continuing after the vital as recovered.

  4. See if the node that this notification is closer too is suspended, if so, delete and ignore the notification.

  5. Grab all of the pending notifications that are above this notification in our dependency tree and all of them that are below us. Check to see if all of the vitals above us are updated and newer than the vital for the notification being investigated. This means we know it's the extent of the problem. Otherwise, we stop processing and wait for the vitals we depend on to be updated.

  6. If we don't depend on any vitals, or all the vitals we do depend on have been updated since the notification was created, then we execute our notification type's script.

As you can see, notifications are pretty hairy creatures. Once all this is done, then the cool, fun stuff happens. Each Notification Type has a simple script that determines what happens when we're executing the notification. It is here where things get pretty interesting. A script is just a simple collection of XML tags that have specific meanings to mod_notifs:

EMail

Invokes a special signal that is created and hooked by mod_mail that sends an e-mail to the specified individuals. This is actually a special tag because it's never actually handled by mod_notifs. Because no matching tag can be found, it's treated as something implemented in another module and so a signal is emitted with the same name as the tag. This means it is very simple for people to add more actions and tags to the notification process.

After

A specially defined condition that causes the insides of the After block to be executed when the given duration of time has elapsed. This way notifications can do different things after a specified period of time. You can have any number of these conditional blocks, giving you a great deal of flexibility.

Delete

Deletes the notification. This is necessary, otherwise notifications would continue on and on forever until they recovered, unless of course that is what you'd like. It's most useful when used in an After block.

There you have your friendly household notification system. Please see the example notification configurations provided for more details and examples of how to construct useful notification types and use them in practice.