Action groups are containers for “actions,” which are themselves containers for “methods,” which are discreet pieces of automated behavior. (Actions and methods are explained further down.)
Action groups are assigned to OmniCenter checks in the check configuration settings. They are then run by the incident opened as a result of that check failing and entering an alarm state. Action groups are how alert notifications get sent out, and how commands are run against a host in response to the failure in question. Action groups consist of three parts: The action group itself, one or more actions contained within the group, and all the methods contained within those actions.
Action groups are essentially named containers. They are a way of organizing automated behaviors that you want to happen when a problem occurs. Action groups are created and managed on the Actions Administration page (Administration → Alerts → Actions).
How Action Groups Work
When an OmniCenter check fails and enters an alarm state, the alarm opens a new incident. That incident will run all the action groups selected in the ACTION GROUP field of the failing check’s configuration settings.
An open incident will run all of the above mentioned action groups repeatedly according to a schedule determined by the RENOTIFICATION INTERVAL field specified in the failing check’s configuration settings.
Most checks also allow you to select additional action groups in an ESCALATION GROUP field. If an open incident fails to be acknowledged for longer than the ESCALATE AT field specifies, the incident will then begin running the escalation action groups along with the primary action groups. (Escalation action groups are typically used to send alert notifications to management or senior support staff.) Escalation groups are optional, so they are not required when configuring a check.
Action groups have two configurable parameters:
- GROUP NAME
When creating action groups, try to give them descriptive names representative of their desired functions, such as “Alert Bob K and Restart Service.”
- MANUAL ALERT ACCESS LEVEL
Action groups can also be run manually from within the Incident View dashboard of an incident. The selected user access level will prevent any users below this level from running that action group manually (that is, only users of the selected access level or higher may run that action group manually). Selecting “None” prevents the group from being manually run by any user, regardless of access level. Manually running an action group from the Incident View dashboard ignores the NOTIFY HOURS setting of any methods within the group.
If all you want is to be alerted about a problem, you can create an action group whose actions contain only notification methods. Similarly, if you want to only run commands against a failed host (restart, etc.), without needing to hear about it, you can create an action group whose actions contain only command methods.
“Actions” are an organizational component of an OmniCenter action group.
An action is simply a named container for methods. It serves as nothing more than an organizational element for an action group.
Actions are created within action groups and managed on the Actions Administration page (Administration → Alerts → Actions).
Since they are nothing more than a container, actions have only one configurable setting:
- ACTION DESCRIPTION
This is where you will “name” your action. When creating actions, try to give them descriptive names representative of their desired functions, such as “Management Contacts” or “Service Restart Commands.”
A “method” is the behavioral component of an OmniCenter action group.
A method’s behavior is executed when the action group it belongs to is run. Method’s can do one of two things: Send a message or send a command. Whichever it does, a method always executes its behavior in relation to a specific OmniCenter incident. Methods are created within actions and managed on the Actions Administration page (Administration → Alerts → Actions).
Each method type will have appropriate configuration settings for its behavior (see below), but there are two settings that all methods include:
ACTION METHOD TYPE
This field selects the desired behavior from the list of types above. It only appears when you first add a method to an action. Once a method type has been selected and the method saved, it can’t be changed.
This field allows you to select from a preconfigured list of time frames that restrict when the method may be executed automatically. When action groups are run by an incident, a method will not execute its behavior outside of the time frame selected. This is useful for creating groups of methods within an action that can perform alternative behaviors at different times. Be aware, however, that methods executed by a user manually running an action group from within an incident ignore this setting.
Some behavior types are classified as “active response.” These methods will only execute automatically once, when an incident is first opened. They will never execute again for the same incident when action groups are run automatically. However, when an action group is run manually (from the Incident View dashboard of an incident), active response methods will execute every time. So, be cautious when manually running action groups that contain active response methods.
Any combination of method types can be added to a single action. As can multiple instances of each type.
There are six styles of notification behaviors that can be selected:
- Email alert
Email-based notification about an incident sent to an address specified in the method’s configuration.
- SMS text alert
Also via email, and configured the same way.
- Mobile alert
Cloud-based notification about an incident sent via Netreo Cloud Services to a connected OmniCenter mobile application. (Very handy if your email system is down along with your network.) Mobile alert methods are added to all newly created actions by default, but can easily be deleted, if desired.
Used to send messages about an incident to an external API, such as a ticketing or alternative alerting system. Cannot exceed 1,020 characters in length.
- Active Response Webhook
As above, except whereas normal webhook methods send their message every time the action group is run, active response webhook methods send their message only one time—when the incident first opens. They will not automatically execute again for the same incident. Cannot exceed 1,020 characters in length.
- SNMP Trap
Used to broadcast messages about an incident to devices set up to receive traps from OmniCenter. Cannot exceed 1,020 characters in length.
There are two styles of command behaviors that can be selected:
- Active Response Windows
Used to send PowerShell commands to Windows devices. Due to limitations in OmniCenter, only simple commands should be sent (restart, etc.). If you wish to run complex commands, it’s better to write a script on the target device, and then simply call the script through this command method. Active response command methods only execute one time—when an incident first opens. They will not automatically execute again for the same incident. Cannot exceed 1,020 characters in length.
- Active Response SSH
As above, but uses SSH to send commands to non-Windows devices.
Commands sent to devices to which they do not apply will simply be ignored. So, it is safe to bulk assign actions containing command methods to devices through device templates.
When using the webhook, trap and command behaviors, you can also include macros from OmniCenter’s macro list to access a wide variety of information about the associated incident.