Action groups are essentially named containers for “actions,” which are themselves containers for “methods,” which are discreet pieces of automated behavior. (Actions and methods are explained further down.) They are a way of organizing automated behaviors that you want to happen when a problem occurs.
Action groups, actions and methods are created and managed in Actions Administration (Administration → Alerts → Actions). Only users with Admin or SuperAdmin privileges may create and edit action groups, actions and methods.
OmniCenter checks may have action groups assigned to them in their configuration settings when you wish for some automated behavior to occur if the check fails. The incident opened as a result of that check failing and generating an alarm will then run all action groups assigned to the check. This is how alert notifications get sent out, and how commands are run against a host in response to the failure in question.
Action groups consist entirely of the three parts mentioned above:
- The action group itself (a contained with properties).
- One or more actions contained within that group (also containers).
- One or more methods contained within each action.
How Action Groups Work
When an OmniCenter check fails and generates an alarm, that alarm opens a new incident. That incident will then immediately run all of the action groups assigned to that check. The incident will then repeatedly run all of the assigned action groups according to the schedule configured in the check settings.
Most checks also allow you to select additional action groups as escalation groups. If an open incident fails to be acknowledged for longer than a specified time, 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.)
Both the base and escalation action groups are optional, and so are not required when configuring a check.
Action groups have two configurable properties:
- 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 unique to the action groups they are created within. You cannot reuse actions between action groups. A separate action must be created for each action group you wish to use it in.
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.”
Methods are the behavioral components 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 unique to the action they are created within. You cannot reuse methods between actions or action groups. A separate method must be created and configured for each action you wish to use it in.
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 below. 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.
- NOTIFY HOURS
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 several 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.
- 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 also several styles of command behaviors that can be selected:
Used to send commands 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 commands every time the action group containing the method is run, active response webhook methods send their commands only one time—when its associated incident first opens. They will never automatically execute again for the same incident. Cannot exceed 1,020 characters in length.
- 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 its associated incident first opens. They will never automatically execute again for the same incident. Cannot exceed 1,020 characters in length.
- Active Response SSH
As Active Response Windows 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.