Policy editor

Policy details and Execution order

The first two sections of the policy editor are Policy details and Execution order. Here you name (or rename) the policy and add a description. To set the execution order for the policy, use the slider or enter a value between 1-100. Policies with a lower number are processed first. Preset policies that handle system needs are executed before or after those with a value of 1-100. User-created suppression policies are always executed first. The order is set to 0 and cannot be changed.

To see how your current policies are set, click on the following number of policies listed for each range.

Policy triggers

With the exception of suppression policies, all other policy types have a triggers section. These policies are triggered when an alert is created, updated, or both. Updated means the alert state changes. For example, if an alert changes from Severity 1 to Severity 5. If the policy is triggered by the alert create or update, then the conditions are consulted.

If you select After an alert has been updated, alert properties can be specified in the policy trigger. As with condition sets, when alert.details is selected you can specify a singular key within the alert's details to minimize the scope of the policy trigger. You must enter a string value that matches a key from an alert's details. If the Details name input is left empty, all of the details and the details' names are searched.

With type 'string' alert custom properties, you can access additional properties of alert.sender, alert.resouce, and alert.type by typing your custom property (for example, alert.type.customProperty) and selecting the "Value of: alert.type.customProperty" option. Details name cannot contain spaces, double quotes, backslash, or square brackets. The supported special characters are "-" (dash) and "_" (underscore). There is a character limit of 255.

In the Invoke an IBM Tivoli Netcool/Impact policy, you can select either Alert or Incident properties in the trigger section. You can also select Use default trigger condition for the trigger entity. The default trigger condition is a pre-defined template that excludes clear, closed, or suppressed alerts from the policy.

Condition sets

In a Condition set you configure the conditions that alerts must meet. For new policies, start by adding a condition set. At least one is required. Condition sets are created based on alert properties and Cloud Pak for AIOps alert insights. Click Add condition to select a new condition type from the drop-down menu.

Choose from the following condition types:

• Alert properties: Alert attributes that are predefined for IBM Cloud Pak for AIOps and common to most alerts. For more information, see Alert details.

  • When alert.details is selected in the property field or the value field, a secondary input box is displayed underneath. The Details name field is an optional input where you can minimize the scope to a singular key within the alert's details. For example, if you enter specificKey in the Details name field, it is understood as alert.details.specificKey. If the Details name input is left empty, all of the details and the details' names are searched and operators of contains, does not contain, is empty and not empty are the most useful. The Details name field does not provide suggestions for possible keys. You must enter a string value that matches a key from an alert's details. Details name if provided cannot contain spaces, double quotes, backslash, or square brackets.

  • With type 'string' alert custom properties, you can access additional properties of alert.sender, alert.resouce, and alert.type that are not in the default alert schema. Type your custom property (for example, alert.type.customProperty) and select the "Value of: alert.type.customProperty" option. The supported special characters are "-" (dash) and "_" (underscore). There is a character limit of 255.

  
  

• Alert insights:

  • Anomaly: Log anomaly and metric anomaly attributes that are predefined for IBM Cloud Pak for AIOps. For more information, see Supported Anomaly insights.
  • Business criticality: Set in Resource management to define the importance of an application, resource group, or resource to the business. For more information, see Defining business criticality.
  • Golden signal: Select from predefined golden signal labels and types.
    • Labels: traffic, latency, error, saturation, availability, information.
    • Types: effect, cause, none.
  • Seasonal: Alerts that occur within a seasonal time window.

For more information, see Examples of policy conditions mapped to alert JSON.

Note: Schema descriptions for both Alert properties and Alert insights are displayed on the UI. Click anywhere in Property field and move the cursor over the properties to display the descriptions.

Schema descriptions

When adding conditions, you can join multiple condition types by using the AND and OR operators. The AND operator means that alerts are matched only if all of the individual conditions are true. The OR operator means that alerts are matched if any of the individual conditions are true.

In the fields provided, select the Property, Operator, Matches, and Value for the new condition. Setting a Value field to the value of another property allows you to compare the value of one property to one or more other properties. Click anywhere in the Value field and scroll the tree-view to select from the available options. You can also enter the last part of the fully qualified tree-view name to see and select the tree-view "value of" alert or insight field. To enter a string value, type the string (e.g. "Error") in the Value field and then select String: Error from the drop-down. If you enter a fully qualified tree-view value, you can save it as a string versus the "value of". To enter a numerical value, type the number (e.g. "10") in the Value field and then select Number: 10 from the drop-down. Note, negative values are also supported for type Number fields.

If you need more than one condition set, click Add condition set. Alternatively, to copy and paste an existing condition set click Copy condition set. To rename a condition set, point the cursor over the condition set name and click Edit . You can use the sidebar to navigate a policy's condition sets and actions. To remove a condition set, click Delete. At least one condition set is required.

Notes:

• Suppression policies contain only one condition set. You cannot add or copy condition sets in these policies.

• Some information icons in the Policy editor are activated by hover-over, others are activated by clicking. This depends on nearby controls and groups on the UI. Some pages can contain a mixture of hover-over and clickable information icons.

• Unlike Alert details properties, Alert insights conditions like Business criticality and Anomaly conditions cannot evaluate true where Business criticality or Anomaly insights contain no value. For these two property types, Cloud Pak for AIOps checks first for a value, and if it is not present, false is returned. If the value is present, the condition that is assigned by the user is evaluated, and true or false is returned as determined. Therefore, it is a best practice to avoid use of the negative Operator property "not equal to" when you use Business criticality and Anomaly insights properties.

Actions

Actions are where you specify what is triggered when the policy conditions are met:

• Suppression policies: the action is always to suppress the alerts described in the condition sets.

• Scope-based policies: the action that is taken is defined by alert properties and strings to create the ScopeID for a group. These properties define the scope for how the alerts are grouped.

• Runbook policies: choose one or more runbooks to assign when the policy conditions are met, and select how parameters are passed.

• Incident policies: the action is the creation of an incident with a specified priority level (example below). You can optionally delay the creation of an incident by setting a hold off time, select how you want to be notified about the incident, open a ticket (GitHub or ServiveNow), and assign a user group and owner.

• Invoke an IBM Tivoli Netcool/Impact policy: enable Cloud Pak for AIOps to invoke an IBM Tivoli Netcool/Impact policy that will take actions on your alerts.

Example

In the following example, a condition is added to an existing policy so that the policy applies only to alerts that have a prefix of either "Error" or "Warning" in their Summary field.

1. Click the navigation icon in the toolbar to go to the main navigation menu.

2. In the main navigation menu, click Operate > Automations.

3. In the table row of the policy that you want to edit, click the menu overflow icon (the three dots at the end of the row) to and select Edit policy.

4. Click Add condition and select Alert property.

   1. From the Property drop-down list, select alert.summary. You can type "sum" and the system will show in the property drop-down list all alert properties that contain the text "sum", which in this case is only alert.summary.
   2. From the Operator drop-down list, select Contains.
   3. From the Matches drop-down list, select any of.
   4. In the Values field, type Error and then click String:Error in the pop-up. In the same field, type Warning and click String:Warning.

   

5. Click Save to save your changes.

   If the save button is not active, one or more items might be missing in the conditions or runbook parameter sections. If clicking save fails to exit the edit session, again, check that no required details are missing.

Note: New and updated policies can take up to 2 minutes to take effect.

IBM Cloud Pak® for AIOps determines which of your alerts were caused by the same problem. If an active incident exists for a given problem, a new incident is not created.

For more information about creating policies, see the following topics:

• Suppress alerts
• Group alerts based on scope
• Assign a runbook to alerts
• Promote alerts to an incident