Non-standard monitoring use cases
In most cases, monitoring is viewed as a fairly simple alarm system built to notify you when something goes wrong. However, there are also situations where monitoring software can be used in less obvious ways, or where non-standard settings help solve a task more elegantly.
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 case, template variables can help make the setup reusable rather than configuring every mailbox monitor separately. IPNetwork Monitor supports variables in alert message templates and in other action parameters, which makes this kind of pattern practical, not just theoretical. 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 and only change its name to create a quota monitor for another mailbox. This is one of the simpler examples of turning a single monitor/action pair into a reusable template-like pattern.
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 for the backup service (such as PING or TCP) and configure it so it is polled only when the primary service is no longer in OK state
- make the remaining backup-service monitors depend on that general check
In current dependency settings, this is exactly the kind of case where reverse dependency logic is useful: a monitor can be checked only when the selected dependency monitor is not in OK state.
In such a case, while the primary service is healthy, the backup service stays out of the normal monitoring path. As soon as the primary service leaves OK state, IPNetwork Monitor starts checking the backup service and can notify you if it is not ready to take over.
Launching external actions from alerts
Alerts are often expected to send notifications, but in practice they can do much more. IPNetwork Monitor supports several action types that are useful for automation as well as messaging: running a local program or script, running a command remotely via SSH, setting an SNMP value, and sending an HTTP(S) request to an external service. These same actions are also used for integrations such as Slack, Microsoft Teams, and Telegram.
In other words, simple actions let monitoring react to a state change, not just describe it. That makes them useful for temporary remediation, escalation, logging, and integration with other systems. 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)
Because such actions can change external systems, they should always be tested from the alerting workflow before being relied on in production.
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. In current versions, these kinds of reusable alerting and monitor patterns can also be inspected and configured through the MCP API, which makes advanced setups easier to document and automate.