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
Article Comments
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."
Jul, 2018 - Permalink
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
Jul, 2018 - Permalink
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
Jul, 2018 - Permalink
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: support@paessler.com for further analysis. Please refer to the ticket "PAE1070057" in the subject.
Thank you!
Andreas Günther
Tech Support, Paessler AG
Jul, 2018 - Permalink
Hello,
Thanks for the support and for opening the ticket, I'll contact the team with the needed info.
Best regards,
Andrei
Jul, 2018 - Permalink
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
Jul, 2018 - Permalink