Non-standard monitoring use cases

In most cases, monitoring is often viewed as pretty dumb alarm system – built to notify if something goes wrong. However, there could be cases when monitoring software can be used not so straightforward, or apply non-obvious settings or means to handle the task.

Some of them are listed below. If you can think of any other case, please let us know in the comments form in the bottom.

Mail boxes size

Mailboxes can grow indefinitely, as time goes. Is there a simple way to notify the mailbox owners approaching or coming over quota of this event?

In this given case, template variables can be of help. Mailbox size is most probably measured on mail server. Thus, we need to create a generic means to notify mailbox owner with as little effort as possible.

In more or less simple case when certain string (“user name”) can identify both mailbox folder and user email, the solution can be simple:

• assign monitor name equal to user name part (e.g., set it to “user” for user@example.com mailbox)
• use that $MonitorName in monitor definition, when folder/file size is checked
• use the same $MonitorName in alert’s simple action, in To/Cc address, as part of email address (e.g. $MonitorName@example.com)

After that you can duplicate the monitor; by changing its name, you will be creating mailbox quota monitor for another mailbox – just adjust the monitor name.

Fallback services monitoring

Under certain circumstances, service can be in need of monitoring only if another service is not in good shape. For example, fallback (backup) service, that can be as well turned off when everything works normally. Keeping this monitor active would bring the entire monitoring setup to “worst of all” state of such a monitor (“Down” or “Warning”).

Using proper dependency can allow more elegant solution:

• create a “general check” monitor for backup service (such as PING), that depends on primary service being in “not OK” state
• make other monitors of backup service depending on its PING monitor

In such a case, while primary service is up and running, backup service doesn’t show on radars. As soon as primary service leaves “OK” state, IPHost will begin watching the backup service and notifying about its problem.

Launching external actions from alerts

Alerts are expected to send notifications. IPHost provides tools to post messages to any external messaging service offering an API or other integration tools (Slack, Telegram, Microsoft Teams etc), beyond typical actions like sending email or SMS.

However, simple actions allow executing any possible action in response to a monitor going down. That opens many new possibilities, to list a few:

• run “SNMP set” simple action, to alter primary network interface when current one stops responding; that can be used to automatically switch to a backup Internet service provider
• in response to a site going down, initiate launch of a virtual machine that will try to analyze the situation and provide a failover version of the site (or restore it from last known backup)
• when temperature sensors show ambient temperature well above optimal value, script can trigger a smart socket and start air conditioner (or initiate all running servers/other devices’ shutdown)

Monitoring can’t replace a human operator intervention, but it can provide a temporary solution, while human operator looks for more permanent one.

Conclusion

Monitoring software may provide enough tools and features to serve not only as alarm clock, but as emergency (temporary) solution. However, such solutions should always be tested in real life, to ensure they do not donate to the problem.