Alert Intelligence Policies

Alert Intelligence is a crucial process that involves various policies to optimize the management and analysis of alerts. This process includes deduplication, enrichment, and aggregation of data to provide a more coherent and actionable view of alerts.

In large IT environments where systems can generate thousands of alerts every day, many notifications are often repetitive or low priority, making it difficult for teams to focus on what truly matters. Alert Intelligence helps reduce this noise by filtering out duplicate alerts so that unique and meaningful issues surface. It also adds valuable context by attaching relevant details to each alert, enabling you to quickly understand the cause. By connecting related alerts and showing how they are linked,

You can view and manage your policies directly in the Virtana Global View. Perform the following steps to open the Alert Intelligence:

Log in to the Virtana Platform and navigate to Global View.
Click Governance and select Alert Intelligence.
An Alert Intelligence page opens.

Use this table to assess the details of governance policies in one place. You can view key information, such as the name of the user who last edited the policy, when they edited it, and the policy's current state. This centralized view allows you to efficiently monitor, manage, and adjust governance policies as needed.

Table 18.

Column name	Description
Policy Name	The unique name or identifier of the governance policy. It must be the same in System and custom policies.
Priority	The priority column in the governance tab indicates the relative importance or urgency of each policy. In this system, a higher number indicates a lower priority, while a lower number signifies a higher priority.
Description	A brief description explaining the purpose or focus of the policy
Policy Type	The type or category of the policy, for example, Deduplication, Correlation, Enrichment, Aggregate, and Suppression.
Edited By	The user or team that last edited or modified the policy.
Edit Date	The date and timestamp when the policy was last edited or updated.
State	Indicates the current status of the policy, for example, enable, disable.

Note

All the properties in the alert are accessible as variables with $alert.<property_name>. These names are available under the Properties tab on the Alert details page as raw key-value pairs, for example, $alert.entity_name, $alert.entity_type.

Policy types

All Alert Intelligence tasks fall under the Alert Handling category. It manages and responds to alerts, including categorizing, prioritizing, and taking appropriate actions to address or resolve the issues indicated by the alerts. This involves deduplication, enrichment, correlation, and aggregation of alerts to streamline and enhance the efficiency of incident response and system monitoring.

This category includes five main policy types:

Table 19.

Policy Types	Description
Aggregate	Groups related alerts into a single, comprehensive alert for simplified management.
Correlate	Identifies and links related alerts to show patterns, like parent, child, and peer relationships.
Deduplicate	Removes duplicate alerts to minimize noise and redundancy.
Enrichment	Adds context and metadata to alerts for a deeper understanding.
Suppression	This policy is designed to suppress informational severity alerts originating from external sources. It ensures that only critical and relevant alerts are prioritized for attention, reducing unnecessary notifications.

Deduplication: This policy involves identifying and removing duplicate alerts to ensure that unique alerts are processed and analyzed. This reduces noise and allows for more efficient handling of alert data.

name: "Bugbash_Dedup_Policy"
description: "Deduplicate External alerts."
criteria: "event_provider: Others AND -status: Closed AND entity_id: 110667"
precedence: 1
category: "alert_handling"
actions:
  - type: "dedup"
    criteria: "true"
    query: "event_provider: Others AND -status: Closed AND entity_name: BugBash AND entity_type: BugBash"
    set:
      severity: $alert.severity
      summary: $alert.entity_name

Enrichment: In this policy, additional context is added to the alerts. This may include appending relevant metadata, correlating alerts with known issues, or adding information from external sources to provide a comprehensive understanding of the alert.

name: "Enrichment policy"
description: "Enrich OC alerts."
criteria: "event_provider: OpsCruise AND -status: Closed AND related_entities.namespace: \"robot-shop\""
precedence: 1
category: "alert_handling"
actions:
  - type: enrich
    criteria: "status: Open"
    set:
      priority: "Low"
      description: "QA teamm modified it for testing"

Correlation: Correlation policies identify related alerts and link them together so you can understand the relationship between events and troubleshoot faster. In Alert Intelligence, correlation runs when an incoming alert matches the policy criteria. The policy then uses a query to find existing alerts to link with, and can optionally enrich either the incoming alert or the matched existing alerts.

You can use the following supported correlation link types:

Table 20.

Link type	Description
`parent`	Links the incoming alert to an existing alert as its parent.
`child`	Links the incoming alert to an existing alert as its child.
`peer`	Links alerts as peers (equals). Peer correlation correlates all alerts based on the same `entity_name`. The peer relationship is bidirectional ( for example, if A is a peer of B, then B is also a peer of A).

Correlation supports two enrichment blocks:

set: Enriches the incoming alert (existing behavior).
set_existing:: Enriches/updates the existing matched alerts returned by the correlation query. Use this when you want to update alerts that already exist in the system (for example, enrich all peers that were found).

Note

The new correlation policy enhancements introduce set_existing as a first-class clause and expand support for peer correlation.

name: "Peer_Correlation_Same_Entity_Name"
description: "Peer-correlate alerts that share the same entity_name and enrich both incoming and existing matched alerts."
criteria: "event_provider: OpsCruise AND -status: Closed"
precedence: 20
category: "alert_handling"
actions:
  - type: "correlate"
    criteria: "true"
    linkType: "peer"
    query: "status: Open AND entity_type: host AND entity_name: $alert.entity_name"
    batchSize: 100    
    set:
      description: "This alert was peer-correlated by entity_name."
    set_existing:
      description: "A peer alert was linked to this alert based on entity_name."

Aggregation: Aggregation policies group related events and alerts, identifying relationships between them. This helps in consolidating multiple alerts into a single, more meaningful alert, simplifying the alert management process.

name: "Parent Creator Rule"
description: "Create new parent alert if it doesn't exist or correlate incoming alerts with existing parent alert."
criteria: "event_provider: Others AND -status: Closed AND entity_type: WAN_TEST"
precedence: 10
category: "alert_handling"
actions:
  - type: "aggregate"
    query: "event_provider: Others"
    criteria: "summary: \"WAN TEST\""
    parentAlert: 
      fields: 
        severity: "Major"
      matchFields: 
        summary: "parent alert created"
        entity_type: "WAN_TEST"
        entity_id: "TEST0000006"

Suppression: This policy is designed to manage alert notifications by suppressing informational severity alerts that originate from external sources. The policy ensures that non-critical alerts do not overwhelm the system, allowing users to focus on more urgent events.
```
name: "Suppress_Info_Alerts"
description: "Suppress Info severity alerts coming from external sources"
criteria: "event_provider: Others AND severity: Info"
precedence: 10
category: "alert_handling"
actions:
  - type: "suppression"
```

Note

Special characters are not supported in policy criteria.

Note

The LuceneMemoryIndex class uses a slightly different query syntax than Solr, which affects how we evaluate "Criteria" for each phase/policy. For instance, using the criteria source: EventService AND -entity_type: (pod container) still matches pods and containers. To prevent this, you need to include OR explicitly, like -entity_type: (pod OR container).

By implementing these enrichment policies, organizations can enhance their ability to monitor and respond to critical issues, ensuring a more streamlined and effective alert management system.

Configuring Alert Correlation Policy Using YAML

You configure Alert Intelligence policies using a YAML configuration file, typically named alert-policy.yaml.

Step 1: Creating YAML-format Configuration

Use this step to create a working copy of the policy file that you can safely modify for your environment.

Duplicate the alert-policy.yaml file.
Modify the duplicated file to configure the integration as required for your setup.
Use the provided upload feature to submit the edited YAML file, which contains the policy logic.

Step 2: Adding General Information

Provide a clear name and description of the policy. For client-specific policies, include relevant tenant or organization names. A Tenant ID is not mandatory.

policy: 
    name: "Same Application Correlation"
    description: "Correlation activated because alerts were generated from the same application."
    precedence: 1 
    category: "alert_handling"

Step 3: Add Alert Criteria

You must define the alert criteria to define which alerts the policy should apply to by setting conditions based on alert attributes.

Filter the type of alerts that occur on the selected resources. If no conditions are defined in this section, all alerts on the selected resources will match this policy.

 criteria: "event_provider: OpsCruise AND -status: Closed"

Step 4: Add Actions

Specify the action to enable policy should take with the matching alerts, such as deduplicating, enriching, correlating, or aggregating them.

Deduplicate: Removes duplicate alerts to minimize noise and redundancy.

actions: 
- type: "dedup" 
  criteria: "status: Open AND priority: Highest" 
  query: "event_provider: Others AND entity_id: $alert.entity_id AND entity_type: $alert.entity_type" 
  set: 
    severity: $alert.severity 
    summary: $alert.entity_name

Enrichment: Adds context and metadata to alerts for a deeper understanding.

actions: 
- type: enrich 
  criteria: "status: Open" 
  set: 
    priority: "Low" 
    description: "Alert enrichment example"

Correlate: Identifies and links related alerts to reveal underlying patterns.

actions: 
- type: "correlate" 
  criteria: "true" 
  elementType: "host" 
  linkType: "parent" 
  query: "status: Open AND entity_type: host AND entity_name: $alert.related_entities.host"

Aggregate: Groups related alerts into a single, comprehensive alert for simplified management.

actions: 
- type: "aggregate" 
  query: "event_provider: Others" 
  criteria: "summary: "WAN TEST"" 
  parentAlert: 
  fields: 
  severity: "Major" 
  matchFields: 
  summary: "parent alert created" 
  entity_type: "WAN_TEST" 
  entity_id: "TEST0000006"

Step 5: Upload the configured YAML file with the policy

After defining the policy in YAML, upload the configured alert-policy.yaml file through the Alert Intelligence UI so the system can validate it and enforce the policy during alert processing. You can view a few following types:

Correlation

name: "Aditya_Test_Policy"
description: "Correlate incoming deployment alerts with other alerts."
criteria: "event_provider: OpsCruise AND -status: Closed AND entity_type: deployment"
precedence: 1
category: "alert_handling"
actions:
  - type: "correlate"
    criteria: "summary: \"Available replicas\""
    elementType: "container"
    linkType: "child"
    query: "event_provider: OpsCruise AND status: Open AND entity_type: container AND related_entities.deployment_name: $alert.entity_name AND related_entities.namespace: $alert.related_entities.namespace"
    batchSize: 100    

  - type: "correlate"
    criteria: "summary: \"Available replicas\""
    elementType: "pod"
    linkType: "child"
    query: "event_provider: OpsCruise AND status: Open AND entity_type: pod AND related_entities.deployment_name: $alert.entity_name AND related_entities.namespace: $alert.related_entities.namespace"

Enrichment

name: "Enrichment policy"
description: "Enrich OC alerts."
criteria: "event_provider: OpsCruise AND -status: Closed AND related_entities.namespace: \"robot-shop\""
precedence: 1
category: "alert_handling"
actions:
  - type: enrich
    criteria: "status: Open"
    set:
      priority: "Low"
      description: "QA teamm modified it for testing"

In this section:

Alert Intelligence Policies

Note

Policy types

Note

Note

Note

Configuring Alert Correlation Policy Using YAML

Step 1: Creating YAML-format Configuration

Step 2: Adding General Information

Step 3: Add Alert Criteria

Step 4: Add Actions

Step 5: Upload the configured YAML file with the policy

Search results