Alert Enrichment
How it Works, Viewing Enriched Attributes
Last updated
How it Works, Viewing Enriched Attributes
Last updated
Raw alert data contains very limited information, often consisting of id, severity, message/description, rule name and asset IP/host name. This information doesn't provide enough service context (application or service name, environment, machine-type etc.) or support ability context (NOC id, site-id, department, support-group etc.) which are essential data for efficient correlation of alerts. OIA performs automated alert data enrichment using a combination of following approaches
ACE (Automated Context Extraction): Using this method, it extracts useful information like IP Address, DNS name and certain identifyable attributes from the source alert's payload. This doesn't require any external integrations, however, in majority of the scenarios, this may not be sufficient for alert correlation.
External source lookup: This process looks up information related to the incoming alerts in an external data source (ex: CMDB or Inventory system, CSV etc...) and then adds them as enriched alert attributes. Enriched attributed presents more contextual information to the IT Operations user and also will be used to correlate the alerts.
Below flow illustrates different stages of Alert processing from ingestion, alert attributes mappings, alert enrichment, correlation/suppression and persisting into the system's database.
Alert enrichment pipeline has two configuration blocks.
Querying external datasource (like CMDB, Nagios, vROps etc) and save enriched attributes into a dataset (CSV style table)
Define condition(s) or filter(s) rule to lookup, by taking one or more alert’s payload attributes (Ex: assetname / assetipaddress etc) and query additional attributes for a matched record from the saved dataset of an external datasource
Below are few key alert attributes which can be used for alert enrichment attributes from the saved dataset that was created from external datasource integration.
assetName
assetIpAddress
componentName
Below screen shows a sample enrichment pipeline extracting additional attributes from 'Nagios' monitoring tool and configuring the system to use it as part of alert enrichment process.
Enrichment conditions / filters examples:
In the below example, the saved dataset is from VMware vROps, i.e vrops-resource-properties
As a condition rule, multiple attributes are used for a lookup from the above saved dataset for enriched attributes.
Condition-1: identifier == '$assetId' ('identifier' is a column within the saved dataset from vROps, $assetId is the alert attribute which was mapped from the source alert using alert mapping process). Check if 'assetId' attribute from Alert payload matches 'identifier' within the saved dataset.
Condition-2: vmw_name == '$assetName' ('vmw_name' is a column within the saved dataset from vROps, $assetName is the alert attribute which was mapped from the source alert using alert mapping process). Check if 'assetName' attribute from Alert payload matches 'vmw_name' within the saved dataset.
Condition-3: vmw_guest_ipaddress == '$assetIpAddress' ('vmw_guest_ipaddress' is a column within the saved dataset from vROps, $assetIpAddress is the alert attribute which was mapped from the source alert using alert mapping process). Check if 'assetIpAddress' attribute from Alert payload matches 'vmw_guest_ipaddress' within the saved dataset.
enrichcolumns: vmw_name, vmw_parent_vcenter, vmw_powerstate, vmw_accessible_status
Condition operator for all of the above condition: OR (which means, extract enriched attributes if any of them find a matching record within the saved dataset from vROps
Below are some of the supported operators which can be used while querying the saved dataset of an external source using conditions.
== (equals)
!= (not equals)
or
and
Alert enrichment provides additional context to alerts for effective correlation. The user can view enriched attributes by selecting 'View Enriched Attributes' on context menu of the alert as shown.
The alert's payload attributes should be CFX alert attributes which are mapped using alert mapping configuration. For more information, please refer ''
Any attribute which is speficied with $ represents alert payload's mapped attribute. For more information, please refer ''
