Use alerts to initiate external actions
Monitoring is often viewed as an informational service: when a problem arises, messages are sent to alert the people responsible.
However, IPNetwork Monitor also supports composite alerts built from reusable simple actions, optionally with schedules. These actions can be used not only to inform about a problem, but also to trigger a practical response to it.
We provide several sample scenarios below.
Switching to backup Internet connection
Many network devices are SNMP-enabled, and IPNetwork Monitor can use SNMP both for status checks and for corrective actions.
When creating an SNMP monitor to check upstream connectivity, you can pair it with an SNMP set simple action to switch or enable an alternate router, interface, or similar backup path. If such a setup is used in production, encrypted or otherwise better-protected management access is preferable; for SNMP specifically, SNMPv3 is the safer choice where supported.
If an intermediate device such as a software router or firewall is involved, a remote command may still be required on that system — for example, to change a default route or restart a service. In that case, a program or script run via SSH is usually the more flexible option.
Starting a failover service
In many a case, critical services have backup (failover) counterparts on the net. However, there could be cases, when keeping failover service constantly running can’t be possible.
IPNetwork Monitor allows you to launch a failover service if the primary one remains Down long enough. A local program/script action, an SSH-based action, or even an HTTP(S) request to an external automation endpoint can be used, depending on how the failover system is controlled. This makes the approach suitable not only for local services, but also for cloud APIs, service orchestrators, or internal remediation endpoints.
Starting a remote VM
Most cloud and hosting platforms expose APIs for starting, stopping, or reconfiguring services.
That can be used to start a normally offline virtual machine or service. For example, a remote VM can be launched to bring up backup services, perform a controlled restart, or trigger an emergency workflow. In practice, this kind of integration is often implemented through a script or through the “Send HTTP(S) request” simple action, depending on whether the provider expects a local command-line client or a direct API call.
Similarly, an alert executed when monitor returns to normal can remote stop such services, once they are not necessary anymore.
Enabling emergency procedures
When there’s power/other types of failures, it could often be required to keep track of events within certain area.
A monitor can be created to intercept a power failure event from an UPS; in response, surveillance hardware (such as cameras, proximity and other sensors) can be started to watch the affected areas (and keep the records for later study).
Similarly, that can be used to trigger automated (pre-recorded) audio notifications (e.g. when a fire is detected).
Because these actions can change external systems rather than only notify people, they should always be tested from the alerting workflow before being relied on in production. IPNetwork Monitor supports immediate alert testing and shows execution logs, which makes it much easier to verify scripts, HTTP(S) requests, SSH commands, and message delivery paths.
Conclusion
Do you use your IPNetwork installation to provide active response to monitoring events? If affirmative, we would like to know your story – contact us directly.