Come join our live training webinar every other Wednesday at 11am PST and hear LogicMonitor experts explain best practices and answer common questions. We understand these are uncertain times, and we are here to help!
Rolling out through the end of November, LogicMonitor v.128 brings phase one of LogicMonitor’s AIOps early warning system. New monitoring for Cisco VoIP server/client traffic comes with v.128 as well, along with a new remote support access status display that indicates whether LogicMonitor support is able to access your platform for troubleshooting purposes.
IN THIS RELEASE:
Several of LogicMonitor’s ongoing AIOps initiatives are converging in v.128 to provide sophisticated alert intelligence that reduces alert noise and brings into sharp focus those alerts that require action.
These new features represent phase one of LogicMonitor’s early warning system, which will ultimately serve to proactively warn engineers and IT operations teams before issues occur, and provide a platform to prevent failures.
Note: Root cause analysis and dynamic thresholds will be activated for customer portals after v.128 has been fully rolled out. (**Update: As of 12/6, root cause analysis was fully rolled out and, as of 12/13, dynamic thresholds were fully rolled out.) These AIOps features are available to users of LogicMonitor Enterprise; however, initially, all portals will have access to them on a trial period basis through January 15, 2020. To ensure full functionality, we strongly recommend you use the new Alerts page in conjunction with these new AIOps features.
Root cause analysis leverages the auto-discovered relationships among your monitored resources (as discovered by LogicMonitor’s topology mapping feature) to determine the root cause of an incident that is impacting dependent resources.
When enabled for your alerting operations, root cause analysis highlights the originating cause of the incident, while optionally suppressing notification routing for those alerts determined to be dependent on the originating alert. This significantly reduces alert noise, allowing you to quickly identify root cause.
▲ Alerts that undergo root cause analysis are assigned additional data, including whether the alert is an originating or dependent alert, if its notification was suppressed due to being deemed dependent, and the number of dependent alerts, if any, that occurred downstream from it. The Alerts page can be filtered based on this dependency data to help you focus in on actionable alerts.
Root cause analysis is triggered when a resource goes down or becomes unreachable, as determined by the PingLossPercent or idleInterval datapoints, which are associated with the Ping and HostStatus DataSources respectively.
For more details and setup instructions, see Enabling Root Cause Analysis.
Note: Topology mapping is the backbone of root cause analysis. As discussed in the
Release Highlight: Ongoing Topology Mapping Enhancements section of these release notes, ensure your portal uses the most recent topology-related LogicModules.
Built upon LogicMonitor’s anomaly detection visualization AIOps feature, which was released earlier this year, dynamic thresholds represent the bounds of an expected data range for a particular datapoint. These thresholds are based on anomaly detection algorithms that evaluate the three days of historical data immediately preceding.
When enabled for your alerting operations, dynamic thresholds are evaluated to determine whether a particular alert represents anomalous data (i.e. data that falls outside of the bounds of the expected data range) or non-anomalous data. If the data is determined to be anomalous, the subsequent alert notification is routed; if it is determined to be non-anomalous, the subsequent alert notification is suppressed.
▲ In this anomaly detection graph, the static threshold for the datapoint is set at >100,000,000 nanoseconds. Although many values exceed this threshold over the course of the 20 hours depicted here, the majority of them still fall within the expected range, which is shaded in blue. If dynamic thresholds were enabled for this datapoint, only those alerts triggered by the red values (i.e. those values surpassing the upper bounds of the expected range) would have their notifications routed; all other alert notifications would be suppressed.
The goal of dynamic thresholds is to filter routed alert notifications to just those that represent anomalous data, thus reducing alert noise and ensuring that only those issues truly requiring attention are being sent out to your team. Regardless of whether alert notifications are routed or suppressed based on dynamic thresholds, the alert always displays within the LogicMonitor interface.
For more details and setup instructions, see Enabling Dynamic Thresholds for Datapoints.
Significant enhancements have been made to the methods used by topology mapping to establish relationships among devices. These new methods are extensible, allowing topology mapping coverage to grow in a more predictable and scalable manner. Extending coverage is a primary focus of our development efforts and we will continue to add coverage via new and updated LogicModules (i.e. TopologySources, DataSources, and PropertySources).
Over the past couple of releases, we have also delivered several solutions to address the issue that was causing the wrong devices to be displayed on topology maps. Many of these solutions are implemented within topology-related LogicModules. For this reason, it is important that all topology-related LogicModules in your platform are up to date, including:
Updating to the latest LogicModules will temporarily remove all topology connections while new keys and connections are generated—this is expected behavior. After all DataSources, PropertySources, and TopologySources have had a chance to run, any remaining issues should be referred to support for investigation and resolution. For more information, see Topology Mapping Overview.
Upon your account’s upgrade to v.128, import our new and updated LogicModules from the LogicMonitor repository to expand and enhance your monitoring coverage.
Important: Upon update, customers that have been using these DataSources can safely delete any files in the [collector install folder]/bin/tmp directory whose names begin with “RGLog-” or “RGData-“. These files were created by the old collection method and and are no longer needed.
As part of LogicMonitor’s ongoing UI initiative, we’ll soon be launching a brand new interface for the management of LogicModules. This new interface, called the Integrations page, will provide a centralized view into all LogicModule integrations (e.g. DataSources, PropertySources, EventSources, etc.) that are available for use in your monitoring activities.
▲ The new Integrations page brings the LogicMonitor repository right into the platform. Using the LM Exchange tab, you can easily browse, search, and import new and updated LogicModules—whether published by LogicMonitor or by a member of the LogicMonitor user community. (UI image captured from alpha version; subject to change.)
In This Article