Action Group

Action Groups

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).

See, How to Create an Action Group

The actions and methods within an action group are specific to that action group, and may not be shared with any other action groups. You will need to recreate actions and methods in a different action group if you wish to duplicate functionality.

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.

Skipped Behaviors

Some methods may not execute when their action groups are automatically run. There are typically three reasons for this:

  1. Because their NOTIFY HOURS configuration setting has restricted the time at which they may execute.
  2. Because they are active response methods (which only run when an incident is first opened).
  3. Because they are trying to run a command against a host for which it is not applicable.

(See “Methods” below for more information)

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.

Configuration

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

“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).

See, How to Add an Action to an Action Group

Actions are specific to the action group within which they are created. You cannot share actions between action groups.

Configuration

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

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).

See, How to Add a Method to an Action

Methods are specific to the action within which they are created. You cannot share methods between actions or action groups.

Configuration

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.

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.

Behavior Types

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.

Notification Behaviors

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.
  • Webhook
    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.

Command Behaviors

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.
PowerShell Restarts

When using PowerShell active response methods to restart Windows services or servers, it is imperative to make use of maintenance windows when conducting upgrades or during planned outages, otherwise OmniCenter will attempt to restart the services or systems.

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.

Updated on May 13, 2019

Was this article helpful?

Need Support?
Can’t find the answer you’re looking for? Don’t worry we’re here to help!
Contact Support

Leave a Reply