New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

300.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


Historicdata report details

Votes:

0

Your Vote:

Up

Down

Hi guys,

While building some availability reports we ran into a couple of unclarities. The general idea is that we need to know coverage and downtime data up to minute intervals.

In order to do this, we first make a request for a sensor for a whole day, divided in 1-hour intervals. Iterating on these hourly items we check if any of them has coverage < 100 or downtime > 0, case in which we make a request for that hour interval, with one minute granularity.

In one of the responses that we analysed, the hourly intervals was as follows: 11.07.2018 18:00:00 - 19:00:00; item.coverage: 33; item.downtime: 79;

The minutely API calls return some values that we find strange:

11.07.2018 18:00:00 - 18:01:00; item.coverage: 0; item.downtime: 0; 11.07.2018 18:01:00 - 18:02:00; item.coverage: 100; item.downtime: 100; 11.07.2018 18:02:00 - 18:03:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:03:00 - 18:04:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:04:00 - 18:05:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:05:00 - 18:06:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:06:00 - 18:07:00; item.coverage: 100; item.downtime: 100; 11.07.2018 18:07:00 - 18:08:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:08:00 - 18:09:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:09:00 - 18:10:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:10:00 - 18:11:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:11:00 - 18:12:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:12:00 - 18:13:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:13:00 - 18:14:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:14:00 - 18:15:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:15:00 - 18:16:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:16:00 - 18:17:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:17:00 - 18:18:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:18:00 - 18:19:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:19:00 - 18:20:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:20:00 - 18:21:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:21:00 - 18:22:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:22:00 - 18:23:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:23:00 - 18:24:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:24:00 - 18:25:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:25:00 - 18:26:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:26:00 - 18:27:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:27:00 - 18:28:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:28:00 - 18:29:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:29:00 - 18:30:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:30:00 - 18:31:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:31:00 - 18:32:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:32:00 - 18:33:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:33:00 - 18:34:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:34:00 - 18:35:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:35:00 - 18:36:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:36:00 - 18:37:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:37:00 - 18:38:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:38:00 - 18:39:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:39:00 - 18:40:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:40:00 - 18:41:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:41:00 - 18:42:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:42:00 - 18:43:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:43:00 - 18:44:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:44:00 - 18:45:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:45:00 - 18:46:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:46:00 - 18:47:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:47:00 - 18:48:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:48:00 - 18:49:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:49:00 - 18:50:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:50:00 - 18:51:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:51:00 - 18:52:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:52:00 - 18:53:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:53:00 - 18:54:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:54:00 - 18:55:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:55:00 - 18:56:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:56:00 - 18:57:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:57:00 - 18:58:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:58:00 - 18:59:00; item.coverage: 0; item.downtime: 100; 11.07.2018 18:59:00 - 19:00:00; item.coverage: 0; item.downtime: 100;

I'll elaborate the unclarities:

The hourly average shows 33% coverage, but out of the 60 intervals, only 2 have 100% coverage, the rest of them have 0%(it would then make sense, from our point of view, that the coverage for the sensor is ~ 3.33%). The hourly downtime shows 79%, but all the minutes in that hour have 100% downtime. What's the difference between 100%coverage-100%downtime entries and the 0%coverage-100%downtime ones(How can a sensor have downtime if it was not covered)?

Maybe we're missing the coverage/downtime concepts, if so: could you please shed some light on the whole concept(browsing the documentation we didn't find any details, any links to answers are appreciated)? Any other consistent methods using APIs through which we could reach our goal?

Thank you for the time, Andrei

api availability coverage downtime

Created on Jul 24, 2018 12:00:17 PM by  barabas_a (0) 2



6 Replies

Votes:

0

Your Vote:

Up

Down

Hi Andrei,

Thank you for your message.

When using intervals, rounding inaccuracy must of course always be taken into account.

I'd recommend to use the RAW values without the calculation of intervals if you want to process data further.

Please let me know about the results when using RAW values.


Andreas Günther
Tech Support, Paessler AG

Created on Jul 25, 2018 3:17:45 PM by  Andreas Günther [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello Andreas,

The raw values are the same as the decimal ones.

For a clarification of the issue, may I just underline this part: "The hourly downtime shows 79%, but all the minutes in that hour(except the first one) have 100% downtime."

Created on Jul 26, 2018 7:26:31 AM by  barabas_a (0) 2

Last change on Jul 26, 2018 8:29:22 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi Barabas,

I kindly ask you to provide me with the API call you're using here?

Thank you in advance!


Andreas Günther
Tech Support, Paessler AG

Created on Jul 27, 2018 9:24:07 AM by  Andreas Günther [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello,

I'm using

  • Day overview: {server}/api/historicdata.xml?id={sensorId}&avg=3600&sdate=2018-07-11-00-00-00&edate=2018-07-12-00-00-00
  • More granular request for the hour's outage details: {server}/api/historicdata.xml?id={sensorId}&avg=60&sdate=2018-07-11-18-00-00&edate=2018-07-11-19-00-00

Thank you,
Andrei

Created on Jul 27, 2018 9:34:50 AM by  barabas_a (0) 2



Votes:

0

Your Vote:

Up

Down

Hi Andrei,

Thank you for your answer.

The output from your first post differs when I repeat the API call on my machine. Are you using a script or something to create the list?

I'd like to continue in a support ticket with your inquiry.

Please send me an output of the Historic Data from this sensor as html page to the mail: [email protected] for further analysis. Please refer to the ticket "PAE1070057" in the subject.

Thank you!


Andreas Günther
Tech Support, Paessler AG

Created on Jul 30, 2018 7:29:09 PM by  Andreas Günther [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello,
Thanks for the support and for opening the ticket, I'll contact the team with the needed info.

Best regards,
Andrei

Created on Jul 31, 2018 7:20:36 AM by  barabas_a (0) 2



Please log in or register to enter your reply.


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.