Auto-Response & Alerts

Auto-Response is your Opengear device's integrated alert notification and automation system.

The Auto-Response framework allows you to configure scenarios where:

1. The Opengear device monitors for a Check Condition being met (e.g. managed UPS device has gone onto battery power)
2. In response it runs one or more Trigger Actions (e.g. send a "power offline" SMS to a designated number)
3. When the Check Condition has cleared (resolved), it runs optional Resolve Actions (e.g. send a "back online" SMS when mains power is restored)

Note: Some Check Conditions such as Serial Login/Logout are by their nature "non-resolvable" so Resolve Actions are not run, these are noted in the UI.

Built-in check conditions and actions are summarized in the tables at the end of this article.  Some conditions and actions have specific articles with further details, links are provided in the tables for convenience.

Configuring an Auto-Response

• Login to the Opengear web UI as root or an admin group user
• Click Alerts & Logging -> Auto-Response
• Configure the general settings that apply to all Auto-Responses:
• Check Log Events to log Auto-Response state and events to the Auto-Response logfile (/var/mnt/storage.*/autoresponse.log in the filesystem)
• Enter a Delay after boot in seconds to prevent spurious alerts shortly after boots, e.g. when monitoring network interface state
• Click Save Settings
• Click New Auto-Response
• Enter a descriptive Name for the new Auto-Response
• The following optional settings tune the behavior of this Auto-Response:
• Enter a Reset Timeout to prevent the Auto-Response being triggered too frequently (e.g. only power cycle a PDU outlet every 5 minutes to give the powered system time to boot)
• Check Repeat Trigger Action to repeat trigger actions every Repeat Trigger Action Delay seconds until the check has resolved (e.g. send an SMS every 5 minutes until the main router is back online)
• Check Disable Auto-Response then select Disable Auto-Response between the following times (e.g. disable DIO door open alerts until during hours)
• Select and configure a Check Condition and one or more Trigger Actions and optionally Resolve Actions, refer to the tables below for a summary
• Click Save Auto-Response then Return to Auto-Response List

Check Conditions

Check Condition	Summary	Example use case
Environmental	Monitor temperature via internal sensor or temperature and humidity via external EMD5000 module's sensor	Detect HVAC failure
Digital I/O Input	Monitor contact state of TTL via integrated DIO ports or external EMD5000 module	Detect water leak
UPS/Power Supply	Monitor various status including load and voltage of select internal PSUs, managed UPS and PDU devices	Detect power usage spike
UPS Status	Monitor whether a UPS is on line, battery or low battery power	Detect power outage
Serial Login/Logout	Monitor pmshell connection and disconnection events from RS-232 and USB console ports	Detect user access to managed router out of hours
Serial Signal	Monitor managed serial devices' RS-232 signal (CTS, DCD, DSR) status	Detect a serial console cable being unplugged
Serial Pattern	Monitor matching strings generated by a connected user or managed devices using regular expressions	Detect kernel panic on legacy server console
USB Console Status	Monitor whether USB ports have something physically connected to it and powered on	Detect a USB console cable being unplugged
ICMP Ping	Monitor ping response from an arbitrary network address via a specific Opengear network interface	Detect network infrastructure misconfiguration or failure
Cellular Data	Monitor total cellular data usage (RX + TX) over a rolling time period	Detect possible cellular plan data overage
Custom Check	Monitor return code from user-installed bash script	Automate administration tasks
SMS Command	Monitor for matching string received from one or more trusted phone numbers	Emergency contingency commands when network connectivity is unavailable
WebUI Authentication Event	Monitor login, logout and failed login of Opengear web UI	Detect access to Opengear configuration interface
Interface Event Check	Monitor Opengear network interface status (starting, up, stopping, down)	Dynamically start and stop IPsec VPN to restore private network routes via a public failover network
Routed Data	Monitor data activity over time of a host routing via the Opengear device	Detect F2C failover and fail forward by downstream router

Trigger & Resolve Actions

Action	Summary	Example use case
Send Email	Send email to specific email address via external SMTP server, email content may include Auto-Response macros	Raise trouble ticket
Send SMS	Send SMS to one or more phone numbers via internal cellular modem or external email to SMS gateway, SMS content may include Auto-Response macros	Send SMS to alert network administrator of issue
Switch DIO Line	Open or close a DIO or HVDO port	Power relay to activate a siren
Perform RPC Action	Power PDU outlet on, off, or power cycle off and then on	Reboot unresponsive network switch
Run Custom Script	Execute user-installed bash script	Automate administration tasks
Send SNMP Trap	Send trap to primary and optionally secondary SNMP servers	Update alert status in SNMP-based Network Monitoring System
Send Nagios Event	Send NRPE or NSCA alert to Nagios server	Update alert status in Nagios-based Network Monitoring System
Perform Interface Action	Monitor whether USB ports have something physically connected and powered on	Dynamically start and stop IPsec VPN to restore private network routes via a public failover network

When adding Trigger and Resolve actions, you can add an Action Delay time. This is particularly useful with trigger actions, as it lets you define a set of actions to take if the alert condition does not get resolved. For example, If you're performing a ping check in a link that may occasionally go down, you may only want to know if the link is down for more than 10 minutes. In that case, you can set a 10 minute delay on your trigger action to notify you (by email or SMS for example). If the ping check resolves itself before that 10 minute delay is up, the action will not be performed.

This allows you to define a list of actions to undertake to try and resolve the condition. Using the previous example, the link being pinged could be a cable internet link, with the CPE powered via an RPC that you control. You could add an action that after 30 minutes, cycles the power on that CPE to try and reset the link.