Analytics Configuration Sections

This topic describes the four sections on the Analytics & Threshold Configuration page and the metrics available in each. Use it to see which policies apply to which entity Things deployed in the customer environment that are needed to run the business, such as applications, devices, interfaces, and locations. types and how each metric is evaluated (the algorithm in brackets). The sections mirror the way IQ Ops groups network devices, interfaces An entity type representing network interfaces on devices that are monitored for performance metrics and anomalies., and applications so you can control when indicators An observed change in a specific metric stream that is recognized as being outside of an expected model. Indicators are correlated into triggers, and one or more triggers are grouped into incidents. are generated for each kind of entity. For why algorithms matter and how to work with them, see Analytics algorithms overview. For how to open the page and change settings, see Analytics & Threshold Configuration.

Network devices

The Network devices section lists policies that apply to each network device as a whole. These metrics drive incidents A collection of one or more related triggers. Relationships that cause triggers to be combined into incidents include application, location, operating system, or a trigger by itself. when a device goes down, comes back up, or resets (e.g. uptime counter resets after a reboot). Enabling or disabling a row affects all devices of that type. Both algorithms in this section are non-configurable. You can only turn the policy on or off.

Device Status [Status Change].
Device Uptime [Up Time Reset].

Network interfaces

The Network interfaces section lists policies that apply to each interface An entity type representing network interfaces on devices that are monitored for performance metrics and anomalies. on your devices. The metrics cover status, utilization, and packet drops or errors. They support capacity and fault monitoring:

You can raise incidents when an interface goes down.
When utilization or error rates exceed your thresholds.
When values deviate from a learned baseline.

Some metrics appear twice because they have both a threshold-based policy and a baseline-based policy. You can enable one or both depending on how you want to detect anomalies.

Interface Status [Status Change].
In Packet Drops Rate [Baselining].
In Packet Error Rate [Baselining].
In Utilization [Baselining].
In Utilization [Threshold].
Out Packet Drops Rate [Threshold].
Out Packet Error Rate [Threshold].
Out Utilization [Baselining].
Out Utilization [Threshold].

Applications (application + location)

The UI may label this section Applications. The section applies to application + location: a specific application An entity type representing software applications deployed in the customer environment that are monitored for performance and anomalies. in a specific location An entity type representing physical or logical locations in the customer environment where entities are deployed and monitored. (e.g. MS-Exchange in Branch Office Denver). The metrics cover performance (response time, network time, MOS (Mean Opinion Score), retransmissions, failed connections), VoIP (Voice over IP) throughput, and health events from Aternity. Enabling and tuning these policies lets you raise incidents when application experience degrades or when health event counts are anomalous. For the two Aternity health event metrics, see Aternity health event metrics for how they work and how to investigate related incidents.

Activity Network Time [Dynamic Threshold].
Activity Response Time [Dynamic Threshold].
% Failed Connections [Threshold].
MOS [Threshold].
Page Load Network Time [Dynamic Threshold].
% Total Retrans [Threshold].
Throughput (VoIP) [Baselining].
User Response Time [Baselining].
Unique Critical Health Events [Baselining].
Unique Major Health Events [Baselining].
% Hang Time [Bounded Dynamic Threshold].

Application activities

The Application activities section lists policies that apply to a named activity within an application at a location (e.g. a specific activity in EFSO - EMEA Reporting Library at a client location). This entity type is more granular than application + location alone. Currently the section includes one metric, Activity Response Time, so you can raise incidents when response time for a specific activity is anomalous. Enabling or disabling the policy affects all application-activity-location combinations.

Activity Response Time [Dynamic Threshold].

Multiple policies for the same metric

Some metrics appear as two or more rows on the page. Different policies can apply to different scopes (e.g. all application locations vs. a subset of applications). The following cases are the main ones.

Activity Response Time: One policy applies to application + location. The other applies to application activity + location. They are separate because the entity types differ.
User Response Time: One default policy covers all application + location objects. A second policy applies only to ICMP (Internet Control Message Protocol), SNMP (Simple Network Management Protocol), TCP_Unknown, and UDP_Unknown. The product disables it by default and it overrides the first for those applications when enabled. The UI does not currently distinguish the two policies by scope, so use the configuration dialog or default vs. custom state to tell them apart.