As part of my evaluation of PRTG as my organization's future network monitor I am using the web interface on PRTG version 16.2(the new trial version) to try to determine the downtime of some network interfaces and I'm unsure how to interpret the results I am seeing.

On one hand I have log messages that are printed with specific timestamps and the status of the sensor. See this info below.

5/5/2016 3:04:08 PM Up

5/5/2016 3:03:23 PM Down

5/5/2016 3:02:23 PM Warning

On the other hand I go to the historic data and for the same sensor and the same time period the information is as follows:

SENSOR STATUS HISTORY

Up - 5/5/2016 1:24:53 PM - 5/5/2016 3:07:38 PM (=1 h 42 m)

In other words the historic data seems to show that there was not a Down event in the same time period that log messages were recorded showing the same sensor being down.

I can certify that the sensor was down because I disconnected the cable from the physical device.

Log messages show the sensor as being down for at least 45 seconds from 5/5/2016 3:03:23 PM to 5/5/2016 3:04:08 PM.

My questions are:

Why doesn't the event show in the historic data report generated in HTML format?

Am I missing something?

Is there a minimum time threshold that an event needs to pass before being reported as a true down event?

if so, what is that time interval for a sensor of type SNMP Traffic 64bit sensor?

Thanks in advance,

Dan.

Article Comments

Hello,

Thank you very much for your support ticket. Please bear in mind, downtime is only accounted, if at least two consecutive down scans happened. This means you need to take the scanning interval into account here. The historic data report does not look at single down scans in that sense, to see them as downtime. Only proper downtimes will be shown in the Sensor Status History, meaning two or more consecutive down scans.
What further complicates the matter, is that the SNMP Traffic Sensors are delta type sensors. So a first scan after a downtime (or after adding a sensor completely new), will get a raw value from the device. As the sensor is a difference (delta) sensor though, it needs to get a second raw value to produce the difference, which then only turns up as a sensor value in the interface. Technically the sensor is already up though after the first raw value (which you do not see in the interface though).

best regards.


May, 2016 - Permalink

Thanks for the reply. This info is really useful to understand what is happening behind the scene.


May, 2016 - Permalink