Insights in LM Dexda are intelligent alert groups sharing one or more relationships. LM Dexda reduces alert noise by de-duplicating alerts and then grouping and prioritizing them into actionable quality insights. Through these insights, IT professionals can more quickly find resolutions and have fewer issues to manage.
Events collected from monitored sources are observed changes to the normal behavior of a system, environment, process, or workflow. For example, router ACLs were updated, a firewall policy was pushed, or a threshold breach occured. Events are typically identified or reported by a monitoring tool. Events can also be created directly by an application or a service, or by a Configuration Item (CI) such as an IoT device or its management platform.
Events from different source formats are normalised and restructured into a homogeneous form –Common Event Format (CEF). This enables LM Dexda to analyze and process events in the same way, regardless of their origin. Incoming events are analyzed, monitored and de-duplicated, whereby a repeated series of a single event instance are stored into a single alert record.
An alert instance is a single de-duplicated record for a series of repeating events for the same object and measure. For example, a monitoring solution may update an alert each time it records that a filesystem is over a utilisation threshold (80% full, 90% full, 95% full, and so on).
LM Dexda receives each alert update as an event and processes them into a single de-duplicated alert instance, thus avoiding repeat escalations. When LM Dexda receives an event it creates a new alert record if no open alert can be found. However if an open alert exists, LM Dexda increments the existing alert’s de-duplication counter and adds the event to the alert. For more information, see Events to Alerts Flow.
Depending on the results of machine learning applied to each new alert, an alert is either correlated with other alerts to form an insight, or if no correation can be found, it will exist as singleton. Singletons are alerts that could not be correlated and have passed the maximum timeout for correlation to occur. Singleton alerts are escalated as individual alerts.
An insight is a record of a collection of alerts. Using a set of specialized algorithms, LM Dexda identifies hidden patterns within the text features of alert data. LM Dexda analyses both feature and temporal aspects of alerts to dynamically manage their clustering. You can create additional models targeting specific alert fields that hold business value. For example, a CMDB enrichment that contains application or business service context. For more information, see Alerts to Insights Flow.
Alert Processing and Escalations
New alerts and their updates are the output of LogicMonitor’s Alert Evaluation processing phase. Each alert transaction (creation, upgrade, downgrade, closure) resulting from that phase is processed as a separate event in LM Dexda.
Alerts in LM Dexda have their own lifecycle represented in a series of escalation states from new through to closed. When an LM Dexda alert is in an open state, any reoccurrence of a LogicMonitor alert instance will de-duplicate under the open alert. This ensures that alert state is accurately reflected in LM Dexda, and provides a point of control for correlation and escalation.
Severity levels in LM Dexda range from 0 (Clear) to 5 (Critical). Severity level 1 (Indeterminate) is applied to events received with an SDT (Scheduled Down Time) flag. According to the logic in the action groups for alert processing and correlation, the severity of the alert must reach 1 or greater for the alert or insight to escalate to an incident. For an insight, the highest severity across all alerts must be greater than 1. If an alert or insight stays at level 1 an incident is never created.
Alerts are closed when their lifecycles are considered complete:
- An insight record is closed. Insight closure automatically closes its collection of correlated alerts.
- The alert is closed by an automation,for example a related ServiceNow Incident moving to a Resolved state.
- The alert is closed from the user interface through an Operator Action.
For more information on how to manage alerts and insights, see Using Dashboards.