Building flexible email notifications
By default, in default IPNetwork installation the simplest email notification is used. While it’s suitable for most small or testing setups, more complex notifications may be required for real-life monitoring setups.
By means of inheritance and composite alerts, notification system can be made quite flexible: small changes may be required to handle typical use cases. Let’s mention several pieces of advice to control notifications with less efforts.
Use schedules to switch notifications on an off
Schedules are used to control both maintenance windows and simple action execution. By default, the schedule named “Always” is used for actions that should run at any time. Composite alerts can combine the same simple actions with different schedules, which makes it easy to route notifications differently during work hours, after hours, or maintenance periods.
Open “Settings > Schedules”, create a new schedule named “Never” and save it without entering any data. Such a schedule can be used to disable a simple actions by default. For example, if complex alerts are defined, this can be used to debug their execution.
To illustrate: proceed to “Settings > Alerts”, create new alert, add new “Send mail” simple action (by default, to $AdminMail) and use “Never” schedule for it.
By default, such an alert will never send notifications to administrator’s (default) email. In case you need to make sure alerts are sent as expected, edit that simple action and change “Never” schedule to “Always” (default one). After that, you can run test alerts and be sure a copy will always be sent to administrator’s mailbox – to study whether entire alerting is set up correctly.
Note: the above change will affect all the alerts using the affected simple action.
Use composite alerts
A typical alerting setup may require sending notifications to one group during business hours and to a different group after hours.
Create several “Send mail” simple actions and combine them into one or more alerts with different schedules. Composite alerts are designed exactly for this: they combine multiple simple actions with optional schedules, while the alerting rule decides when those alerts should be executed on Down, Warning, recovery, or escalation.
If redundancy is required, add other simple actions as well — for example pop-up, push notification, HTTP(S) request, or script-based actions. Since alerts and simple actions are reusable, one change in a shared action can affect every alert that uses it, which is convenient but worth remembering when editing production notifications.
Use primary and alternate SMTP servers
You need to set up a proper SMTP server in “Settings > Email Settings” to make e-mail notifications work. In most cases, a corporate mail relay or external SMTP service is used.
Current versions of IPNetwork Monitor support both a Primary mail server (SMTP) and an Alternate mail server (SMTP). If the alternate server is configured, it is used automatically when the primary one fails to send a message. This is a more practical built-in fallback mechanism than relying on a separate backup mail collection setup alone.
It is also worth using the Send test email alert button after every SMTP change. The test window shows the actual SMTP conversation log, which makes authentication, connection, and delivery problems much easier to diagnose. Custom “From” and “Reply To” addresses are also supported for both primary and alternate SMTP settings.
Use inheritance and host groups
By default, inheritance is enabled for alerting rules. This means that changing an alerting rule higher in the hierarchy can affect all child nodes below it, starting from “All Agents”. Each new monitor normally inherits its alerting rule from its parent by default.
By creating carefully placed host groups, possibly nested, and assigning named alerting rules to them, one can adjust alerting for all hosts and monitors within that subgroup at once. This is especially convenient when different teams or on-call groups should receive notifications for different parts of the infrastructure. Named rules can also be partially disabled or overridden on a specific node when needed, without changing the rule globally.
Do you have an idea of your own, on how to fine tune IPNetwork alerting? Please let us know by either sending us a message.