Action Profiles

Typically, actions are some form of notification that a test result has crossed a defined threshold into OK, WARNING, CRITICAL or UNKNOWN status. An Action Profile is a list of up to five actions, allowing the user to define multiple notification recipients and specific notification rules for each recipient.

Action profiles are configured using the Administration > Actions link. Once the action profile is created, they can be subsequently assigned to existing tests using the Administration > Actions > Assign to Tests and Assigns to Events links.

Action profiles can be created by either end users or an administrator to notify up to five separate recipients when a test status changes, or when a test status has been in a particular state for a predetermined number of test cycles. After defining an action profile, you apply it to individual tests or containers.

• Action profiles configured by administrators are associated with a user-class and test-type. Department users assigned the same combination of user-class and test, will see an asterisk next to the name of the action profile identifying it was created by an administrator.
• Department users can also created their own action profiles.

For each action, you select the notification type, using the Notify Using drop-down list, and the recipient. This can be an email address, phone number or other parameter depending on the notification type selected.

You can then select when you get notified. You can be notified immediately when a particular state is entered, or wait for 1 or more polling intervals or minutes before being notified. This can be very useful to avoid getting alarms for transient conditions such as high CPU or high memory by setting to 2 polling intervals (as an example), while still getting immediate alerts for important devices and tests. Note that the status change is always recorded in Traverse for reports.

Finally, you can setup whether this action should be repeated or not. If so, how often the action should be repeated? For traps and messages, this field should always be set to a non-zero value for subsequent similar traps to trigger the action. The device IP, rule definition and rule source are used to determine if a repeat notification should be triggered.

IMPORTANT: This repeat feature as well as the delayed notification feature is not available for containers and devices. Notifications on containers and devices is immediate.

Example: Action

Using these fields, you can setup an action as follows:

• If a test goes into Critical state, do not email right away but wait until 2 polling intervals have passed and it is still in Critical.
• After the first notification, if test stays in Critical, then keep sending me a reminder email every 30 minutes.
• (Using Schedules) Do email notification during normal business hours, but page me after hours.

Example: Escalation

In a typical escalation scenario, you can setup multiple actions within an action profile so that:

• When the Ping RTT test on a Windows server reaches a WARNING status, the NOC receives an email notification of the problem.
• If the test crosses the upper threshold to CRITICAL status, the NOC Manager is notified and keeps getting an email every hour.
• Once the test has remained in CRITICAL status for over an hour, the senior management is notified via an email.