Hi there,
Metrics collection, analysis and anomaly detection are part of "Operational Intelligence".
When you configure a pull connector for metrics, the mid server will be able to fetch metrics from the datasource at regular intervals configured at the connector instance level. This data will be stored on a time-series database on the servicenow platform called MetricBase (this plugin must be enabled in order to use Operational Intelligence).
Data will be baselined so that "normal" behavior of every metric can be analysed and baselines used to understand when a value deviates from usual points at given point in times and generate anomalies when needed. Anomalies are special kind of alerts and have a confidence score that basically tells "how confident" the algorithm is that the value is anomalous.
In the picture above the colored line shows the anomaly score which went up to 9.012 in case of the anomaly shown there.
Anomalies can be promoted to alerts and used to proactively work on things that could become issues so you could potentially open an incident to fix things before the anomaly turns into an actual problem.
Example:
Observing a metric like response time, it will be possible to determine that it has normally a value of 0.5 seconds between midnight and 4 am, 1 second between 4am and 6am, 1.5 seconds between 6am and 9am, etc.
Now with a traditional approach:
- a static threshold would be used
- it would be set at the highest acceptable value, like 1.5
- this means that if at 2am a 1 second response time is measured then no alert would be generated even though that's twice the normal value at that point in time
Operational Intelligence can
- detect seasonal behaviors like the one described above
- so if a response time, a cpu load, the number of concurrent sessions of some application component should ever be significantly anomalous at a specific point in time an anomaly would be generated automatically.
- According to our example, by generating an anomaly when the metric (response time) is at 1 second at 2am (so still below out hypothetic 1.5 se static threshold) it show that the slower than usual response time could be a sign of a problem that could actually impact end users when it's "rush hour" and the most of the users are connected and experience unacceptably slow response times.
Pull connectors for metrics (like SCOM, Zabbix, AWS, Azure, Nagios, etc.) allow to feed OI with metrics from these tools and apply on those what described above. OI provides an agnostic approach meaning that the capabilities described above would apply to any metric ingested (OS capacity metrics, users, business KPI like number of orders placed in a system, number of new contracts in the last 10 minutes, etc.)
OI provides also visual tools like "Insights Explorer" (IE). IE allows to drag and drop metrics on a dashboard to visually correlate them and to easily share the findings with other users.
I hope this gives you a better understanding of what can be done when pulling metrics with connectors or pushing metrics directly into OI.
Gp
