Governance

Alert governance refers to the establishment and enforcement of policies and practices aimed at managing and optimizing the alert lifecycle. This includes deduplication, correlation, enrichment, and other strategies to ensure that the right alerts are presented to IT operators at the right time, reducing noise and improving incident response efficiency.

Use Cases for Policies:

Deduplication and Correlation: Alert Governance employs sophisticated mechanisms for deduplicating and correlating events. This strategic approach minimizes redundancy.
Enrichment: Adding relevant information to alerts to enhance their context, making it easier for IT operators to understand and respond to them.
Enhanced Comprehension: Through deduplication and correlation, Alert Governance enhances comprehension by eliminating superfluous alerts.
Efficient Response Mechanisms: The primary objective of Alert Governance is to optimize response mechanisms. By streamlining the alert process, it reduces delays in identification and resolution, fostering operational efficiency.

Custom and System Policies Overview

Custom Policies : Custom policies are user-defined configurations that enable organizations to tailor alert management to their specific needs. These policies encompass various functionalities to optimize the alert lifecycle:

Deduplication: Custom policies can identify and eliminate duplicate alerts, reducing noise and focusing attention on unique incidents.
Enrichment: Enriching alerts with additional context, such as relevant metrics or historical data, helps in better understanding and prioritizing issues.
Correlation: Correlating related events and alerts to identify patterns or underlying causes, improving the accuracy and speed of root cause analysis.

System Policies: System policies are pre-defined configurations provided by the platform to facilitate standardized and automated alert responses. These policies primarily focus on communication and automation:

Actions by Communication Tools:
- Email: System policies can automatically send alert notifications via email to designated recipients.
- Slack: Integration with Slack allows for real-time alert notifications and collaboration within Slack channels.
- Teams: Microsoft Teams integration enables alert notifications and discussions within Teams channels.
Automation and Orchestration:
- StackStorm: System policies can leverage StackStorm for automation and orchestration, enabling complex workflows to be triggered in response to specific alerts.

Navigating the Custom Dashboard:

You can explore details of policies, user activities, and leverage visualizations for quick insights. This tabular representation allows to quickly assess the details of various governance policies in one centralized view. It provides essential information such as the policy's purpose, type, last editor, edit date, and its current state. This enables efficient monitoring, management, and adjustment of governance policies as needed.

Policy Name: The unique name or identifier of the governance policy.
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 (e.g., Deduplication, Correlation, Enrichment).
Edited By: The user or team who 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 (e.g., enable, disable).

What is YAML?

YAML serves as a flexible and human-readable data serialization format that plays a pivotal role in configuring and defining policies. It empowers users to express complex configurations and settings clearly and concisely, facilitating the seamless integration of governance rules within Global View environments.

Creating a New Policy

To create a new policy, follow these steps:

Click New Policy.
Upload YAML File Select the YAML file intended for the policy and upload it using the provided upload function.

Configuring Alert Correlation Policy Using YAML

Section 1: Creating YAML-format Configuration

Duplicate the "alert-policy.yaml" File Make a copy of the existing "alert-policy.yaml" file.
Edit the Configuration: Modify the duplicated file to configure the integration as required for your setup.
Upload the Configured File Use the provided upload feature to submit the edited YAML file containing the policy logic.

Section 2: Adding General Information

Enter the following details:

Policy Name and Description Provide a name and a description of the policy. For client-specific policies, include relevant tenant organisation names. It is not mandatory to have a Tenant ID.

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

Section 3: Add Alert Criteria

Filter the type of alerts which 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"

Section 4: Add Actions

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 examle"

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"

Section 5: Upload configured YAML-file with the policy

Examples:

Type: 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"

Type: Enrichment

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

Type: Aggregate

name: "Parent Creator Rule"
description: "Create new parent alert if it doesnt 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"

Type: Action

name: "Test_slack_action_policy"
description: "Sample action policy"
criteria: "event_provider: \"Virtana IPM\" AND -status: Closed AND severity: Critical"
category: "alert_response"
precedence: 1
actions:
  - type: "action"
    criteria: "true"
    action_type: "slack"
    action_name: "Slack_Notification"
    parameters:
      webhook_url: "https://hooks.slack.com/services/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"
      message: "Received alert with entity_name - $alert.entity_name , key - $alert.key , summary - $alert.summary and severity - $alert.severity"

Table 5. For Policies

Field	Mandatory	Details
name	Yes	Name of the alert policy.
description	No	Specifics regarding the policy, its execution timeline, and the actions it entails.
criteria	No	Key rules at the top, checked for every new alert. If they match, the policy's "actions" are carried out.

Table 6. Type: Correlation

Field	Possible Values	Details
type	correlate	Mandatory field, represents type of the policy.
description	(User can define their own values)	Short description of the correlate policy.
criteria	User configured criteria such as Alert Severity,Event Type,Custom Tags, location and so on.	When this condition is satisfied, new alerts will be compared with previously received ones using the specified query criteria.
linkType	parent/child	If the link type is 'parent,' the policy retrieves previously received alerts and connects the incoming alert to them as a parent. If the link type is 'child,' the policy fetches prior alerts and creates a child relationship with each one.
query	(User can define their own values)	Solr query to fetch the ingested alerts.
size	Default: 1	Retrieve and correlate the incoming alert with the count of alerts fetched using a Solr query.

Table 7. Type: Suppression (For suppression policy, the default ( and mandatory ) action is to drop the incoming alerts if the criteria match, this helps to reduce noise by suppressing the unwanted alerts.)

Field	Possible Values	Details
type	Drop	Mandatory field, represents type of the policy.
description	(User can define their own values)	Short description of the suppression policy.
criteria	User configured criteria	If this criteria meets, incoming alerts will be dropped.

Table 8. Type: Enrichment

Field	Possible Values	Details
type	Enrich	Mandatory field, represents type of the policy.
description	(User can define their own values)	Short description of the enrichment policy.
criteria	User Configured Criteria	If this criteria meets, fields from the incoming alert will be enriched as per the assignments configured in this policy.
set	(User can define their own values)	This is a keyword, followed by the name and value of fields from the alert which should get enriched if the policy criteria matches.

Upload Configured YAML-file

Upload the edited YAML file containing the configured policy through the provided upload functionality.

Viewing Policy List

Access the Governance Dashboard: Navigate to the Governance Dashboard interface.
View Policies: From the dashboard, access the list of created policies.
Policy Details
1. Click on a Policy: Review the policy details, including its enabled or disabled status.
2. View Syntax: Explore the policy syntax to understand its structure and rules.
3. Upload Another YAML File: Replace or upload a different YAML file associated with the policy.

Modifying Policies

Upload/Replace YAML File: Click "Upload Another File". Use this option to upload a new YAML file or replace the existing one linked to the policy.
Deleting a Policy: Choose this option to permanently remove the policy from the system.

Note

If want to apply policy on specific type of alerts, then the policy criteria need to have condition added with appropriate value.

If you want to apply the policy on Virtana IPM alerts, then the policy can have one of the criteria as - event_provider: VirtualWisdom
If you want to apply the policy on OpsCruise / Application Monitoring alerts, then the policy can have one of the criteria as - event_provider: OpsCruise
If you want to apply the policy on external alerts only, then the policy can have one of the criteria as - event_provider: Others

In this section: