Action Groups

Action Groups

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.
The action group target

Action groups are run against the host device that the failing check is assigned to. This means that alert notifications and macros are relative to that host, and command methods from the action group are run on that host.

See, How to Create an Action Group

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.

Configuration

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.

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.

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.

See, How to Add an Action to 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.

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

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.

See, How to Add a Method to an Action

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.

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.

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

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

Command Behaviors

There are also several styles of command behaviors that can be selected:

  • Webhook
    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.
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 December 10, 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

Comments

    1. The macro list links have been fixed. Thanks, Glenn. Good spotting.

Leave a Reply