I need more information on how these graphs / indicators are computed, ideally on the basis of a specific example.
This article applies to PRTG Network Monitor 19 or later
How does PRTG compute CPU Index, Traffic Index, and Response Time Index?
To provide graphs that show a quick status overview of your complete network (or a part of it) PRTG computes so-called "Index" values based on the measurements of a selection of sensors. The "Index" graphs are synthetic values ranging from 0% and 100% based on current sensor measurements and their historic peak values. The index calculation works similarly to a stock index, which is the computed mean value of a stock selection.
For each group and device, PRTG shows four values in a graph.
They are based on the measurements of a selection of sensors in that group (or device). The "Alarms" graph simply shows the number of alarms at a given moment in history. Then there are three index values:
- Response Time Index
- CPU Load Index
- Traffic Index
A CPU Load Index value of 10% for a group means that the average CPU load for a selection of CPU sensors of this group is currently at 10% of the CPU peak (historic maximum) of that group. Usually, for response times the historic maximums are much higher than the average value. For example, for pings in a LAN, a "normal" time might be 2-10ms while a maximum of several hundred milliseconds is not unusual. For this reason, most Response Time Index readings are usually between 10% and 20%.
The following two charts show the traffic index for two switches within a 48-hour time span:
The upper graph shows the traffic on one of our workstation switches. During the night the graph drops to a flat zero line—nobody was in the office. The lower graph shows the traffic on our core network switch. It was busy all day and all night because we run a lot of backup tasks during the night.
How does it work?
- During the regular network monitoring process, PRTG records the highest value ever measured for each sensor
- The currently measured value is weighted against this upper liminal value to compute an index value for a sensor between 0% and 100%
- For each device, the index values for CPU load sensors, traffic sensors, and sensors that measure response times are combined
- For each group, the index values of all devices are combined
Keep in mind that changing the sensor setup (the number and types of sensors) will also inevitably change the index values because the numerical base for the calculation changes. This means that values before and after a configuration change may not be comparable at all. The same applies to situations where one or more sensors cannot be monitored (for example, when a probe is disconnected).
By the logic of the measurement of index values, historical peak is used. What happens when the current peak exceeds historic peak? Ideally at the moment past breach is broken, the index should cross 100% until the current peak replaces the past one.
The other way to look at this is at the moment the historical peak is breached the current peak becomes the new norm with index showing 100%.
When we say historical peak, how old that peak can be? Are the current data points getting more weightage leading to recent lower peaks replacing the past peaks as they fade into history.
If a value is recorded that is higher then the previous maximum value, then this new value becomes the new maximum. The maximum values should be stored as long as the sensor data is stored (per default 1 year). For more information about how long data is being stored, please see our manual about Historic Data Purging.