Service metrics
The NetProfiler provides analytics for monitoring service performance metrics. Service policies generate an alert and a notification when the value of a metric differs from its normal (baselined) value by more than a specified tolerance.
Each service policy can alert on either a spike (an INCREASE in the value of a metric from what has been baselined) or a dip (a DECREASE in the value of a metric from what has been baselined). The table below lists the metrics, whether they are enabled or disabled by default, and, if they are enabled by default, whether their service policies alert on a spike or a dip by default. You can choose which metrics to monitor, and subsequently choose whether to alert based upon a spike or dip in the value of the metric.
Metric Category |
Metric |
Monitoring |
Alerts on |
Connectivity (Conn) | Active Connections |
Enabled |
Spikes |
Bandwidth |
Disabled |
Dips |
|
New Connections |
Disabled |
Spikes |
|
Efficiency (Effncy) | Number of TCP Resets |
Enabled |
Spikes |
TCP Retransmission Bandwidth |
Enabled |
Spikes |
|
User Experience (UserEx) | Average Application Throughput per Connection |
Disabled |
Dips |
Average Connection Duration |
Disabled |
Spikes |
|
Response Time |
Enabled |
Spikes |
|
Voice over IP (VoIP) | Jitter |
Disabled |
Spikes |
MOS |
Disabled |
Dips |
|
Packet Loss |
Disabled |
Spikes |
|
Percent Packet Loss |
Disabled |
Spikes |
|
R-Factor |
Disabled |
Dips |
Note that monitoring the metrics that are enabled by default, as noted above, works well for the majority of applications. The other metrics work well for some applications, but may not work as well for others. Additionally, some metrics work better after traffic has been collected for a long enough time (three weeks) to learn about periodic variations. For example, times of low application activity, such as weekends, might be interpreted as a dip, and trigger an alert until the metric has been tracked long enough for the system to recognize that low activity on weekends is normal.