What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

HTTP transaction sensor downtime calculation - how?

Votes:

0

I have an HTTP transaction sensor checking a series of 5 URL's every 10 minutes in PRTG Network Monitor 7.3.3.5611. For a particular period I have the following results in the Log:

14/09/2010 16:19:36	
TMS Transaction - Down - URL #1: HTTP/1.1 500 Internal Server Error
14/09/2010 15:59:36	
TMS Transaction - Up	3,266 msec
14/09/2010 15:39:33
TMS Transaction - Warning	- URL #2: HTTP/1.1 500 Internal Server Error
14/09/2010 15:39:33	
TMS Transaction - Down - URL #2: HTTP/1.1 500 Internal Server Error
14/09/2010 15:29:38	
TMS Transaction - Up	- 3,765 msec
14/09/2010 15:19:34	
TMS Transaction - Warning	- URL #1: HTTP/1.1 500 Internal Server Error
14/09/2010 15:19:34	
TMS Transaction - Down - URL #1: HTTP/1.1 500 Internal Server Error
09/09/2010 05:49:25	
TMS Transaction - Up - 5,549 msec

So between 15:00-16:00 on 14/09/2010, six polling attempts (assuming Coverage is 100% (which it is reported as)) will have been made with two responses being warning/down. Two out of six is 33%.

If I run a Historic Data Report for this sensor for that day, with Average Interval of 1 hour and Percentile Results set to Off, downtime is shown as: 14/09/2010 15:00:00 - 16:00:00 4,757 msec 20 % 100 %

What I'm struggling with is how the 20% downtime figure is calculated. Can someone explain?

Thanks,

Phil

Yet

calculation downtime percentage

Created on Sep 17, 2010 11:44:49 AM

Last change on Sep 20, 2010 7:55:26 AM by Daniel Zobel [Product Manager]



3 Replies

Votes:

0

Dear Phil,

please be aware that downtime for PRTG is the time between at least two "DOWN"-Conditions. So if the next scan after the "first Down-Scan" results in an UP-State of a sensor, then this will not be accounted as downtime. Furthermore, the log only shows status-changes, but probably there were more requests being made. You could check the Historic Data (with RAW Data), to see how many requests exactly failed and how long the sensor was down.

Best Regards.

Created on Sep 20, 2010 4:09:59 PM by Torsten Lindner [Paessler Support]



Votes:

0

Thanks for that. So an example scenario:

  • Polling interval - 10 mins
  • First poll at 13:10 - result is Up
  • Monitored item goes down at 13:11
  • Second poll at 13:20 - result is Down
  • Monitored item comes back Up at 13:29
  • Third poll at 13:30 - result is Up

In the above, although the system was actually down between 13:11 and 13:29, because only one poll (and not the two consecutive down polls implied by your reply), no downtime will be recorded?

Just trying to understand a bit more about how downtime is calculated/shown - thanks for your help.

Created on Sep 21, 2010 8:09:55 AM

Last change on Sep 21, 2010 2:44:58 PM by Torsten Lindner [Paessler Support]



Votes:

0

Dear Phil,

yes exactly. PRTG only counts downtimes between at least two following Down-Conditions. This is, of course, a bit of a 'philosophical discussion' if already one Down-Scan should be accounted as downtime. But then you can't say with certainty how long this downtime then was or how long it should be accounted, as PRTG doesn't know when the target actually went down and then up again.

Best Regards.

Created on Sep 21, 2010 2:48:29 PM by Torsten Lindner [Paessler Support]




Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.