Automated alert grouping

  • Release version: Xanadu
  • Updated August 1, 2024
  • 3 minutes to read
  • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Automated alert grouping

    Automated alert grouping in ServiceNow Event Management aggregates alerts into groups based on historical alert data to streamline issue identification and management. These groups appear in the Express List within the Service Operations Workspace, helping you efficiently monitor related alerts.

    Show full answer Show less

    To enable automated alert grouping, set the Enable alert aggregation for Automated, CMDB and Text based groups (saanalytics.aggregationenabled) property to true. If Domain Support is active, grouping patterns are built at a specified domain level, controlled by the saanalytics.agg.learnerdomainlevel property.

    Key Features

    • Pattern Identifiers: Alert grouping relies on pattern identifiers, which by default use the Metric Name. You can customize which alert fields define these identifiers through the Manage Pattern Identifier form. This flexibility allows grouping based on attributes most relevant to your environment.
    • Historical Alert Data: Grouping algorithms analyze alerts with the same Configuration Item (CI) and pattern identifier occurring repeatedly within a configurable timeframe (default 30 days, controlled by saanalytics.agg.learnerperioddays).
    • Effective Field Selection: To ensure meaningful groups, alert fields used in pattern identifiers must be sufficiently populated and neither too unique nor too common. You can create event rules to populate these fields and run jobs to update historical alert data accordingly.
    • Learned Patterns: Alerts matching the same pattern attributes form Learned Patterns, visible in reports, enabling you to recognize recurring issues.
    • Single Active Pattern Set: Only one set of pattern identifier attributes can be active at a time and must be explicitly deployed to take effect.
    • Grouping Without CI: Alerts lacking a CI can still be grouped as Text-based or CI-based groups by treating a node as the CI. Enable this via the saanalytics.enablenocigrouping property.
    • Custom Grouping: You can configure grouping based on specific CI fields (e.g., Location) using the saanalytics.agg.learnergroupbyproperty property to create more targeted alert groups.

    Practical Benefits for ServiceNow Customers

    • Automated alert grouping reduces noise by consolidating related alerts, making it easier to identify and remediate recurring issues.
    • Customization of pattern identifiers allows tailoring alert groups to your organization's unique infrastructure and monitoring needs.
    • Integration with domain support ensures alert grouping respects organizational boundaries and domains.
    • Visibility into learned patterns supports proactive incident management and trend analysis.
    • Enables grouping even for alerts without direct CI references, increasing coverage and detection capabilities.

    Event Management alert aggregation aggregates alerts into automated alert groups based on historical alert data. Automated alert groups are displayed in the Express List in the Service Operations Workspace.

    Enable creating automated alert groups by setting the Enable alert aggregation for Automated, CMDB and Text based groups (sa_analytics.aggregation_enabled) property to true.

    If the Domain Support - Domain Extensions Installer is activated, then alert aggregation patterns are built according to the domain level that is specified in the sa_analytics.agg.learner_domain_level property. By default, the domain level is set to two, which is the second domain level in the domain hierarchy. See Domain separation and Event Management.

    To create automated alert groups, aggregation algorithms rely on historical alerts with the same alert identifier (CI and metric identifier) and which occurred multiple times in the same time frame.

    About Pattern Identifiers

    The default pattern identifier is defined as Metric Name. In the Manage Pattern Identifier form you can which alert fields are currently used for the pattern identifier. You can choose a different set of alert fields to deploy, or define a new set of fields for the pattern identifier.
    Note:
    A set of alert fields used for pattern identifier is also referred as Feature Identifier Attributes or attributes.
    To ensure that the specified alert fields in the pattern identifier are effective, a sufficient number of alerts must have the respective populated fields. Therefore, if you specify a new set of alert fields in the pattern identifier, do the following to ensure meaningful analysis:
    • Create an event rule that populates the respective alert fields.
    • If a large number of existing alerts don’t have values for the new set of alert fields used in the pattern identifier, ensure to run the Service Analytics Attribute Populator for Historical Alerts job that uses the appropriate event rule to populate alert fields from historical alerts. Properties originating from the CMDB CI using dot-walking aren’t populated.
    • Choose effective identifiers:
      • Ensure that the set of alert fields in the pattern identifier isn’t too unique (for example, the date field is unique for every alert), because it is impossible to identify any pattern.
      • Ensure that the set of alert fields in the pattern identifier isn’t too common, because it won’t be possible to create distinct groups, as everything would be included in the same group.

    When an alert pattern is discovered based on a set of alert fields, the alerts are considered to be related to each other and therefore are grouped into a Learned Pattern. For example, if you configure identifier attributes to create a pattern based on alerts with the same Priority Group and Resource, if a group of alerts match those attributes, they’re grouped into a pattern that displays on the Learned Patterns report (Event Management > Administration > Learned Patterns).

    Only one set of pattern identifier attributes can be active at a time. A new set of pattern identifier attributes isn’t automatically implemented until you deploy it. When you deploy a new set of attributes, the current set of attributes that is in effect becomes inactive. Subsequent queries use the active pattern identifier attributes to perform alert aggregation.

    The major purpose of this pattern based alert aggregation is to find patterns of issues that occurred during last 30 days. The number of days is controlled by the sa_analytics.agg.learner_period_days parameter. To identify an issue, the system uses a combination of Configuration Items (CIs) and Pattern Identifiers (sometime called Feature Identifiers). A Pattern Identifier, by default, is defined as Metric Name, but it may be modified. Two alerts are similar if they have the same CI and Pattern Identifier. However, Source, Severity, Description, and other alert fields may differ. For more information, see Specify and manage pattern identifier attributes for alert aggregation.
    Note:
    The Alert Aggregation Learner also learns the patterns of alerts in manual alert groups.

    In some cases you can build patterns from alerts whose CIs have the same value in a selected field. For example, to build patterns from alerts that have the same CI Location field, enter 'location' in the sa_analytics.agg.learner_group_by_property property. For more information, see Configure scheduled job-based alert grouping.

    Alerts that don't contain a CI can still be grouped together as Text-based or CI-based alert groups. In this case, a node is considered as a CI. To enable this functionality, set the sa_analytics.enable_no_ci_grouping property to true. When working with CI-based groups, ensure that the Feature Identifier includes both the node and metric name. For details on configuring the feature identifier, see Learned Patterns report.