Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Inconsistencies with the Measurements API when using Newts

Description

IMPORTANT: THE FOLLOWING WON'T HAPPEN WHEN USING RRDTOOL.

The following was verified with latest foundation-2016 and latest snapshot for Meridian-2016.1.0:

1) When using MIN or MAX as the aggregation function when calling the following ReST end-point, weird values are returned:

Here are examples:

/rest/measurements/nodeSource%5BKME:OI-68EFE924426240239D42BE1F053AD80D%5D.nodeSnmp%5B%5D/avgBusy5?start=-200000&step=30000&aggregation=MAX

rest/measurements/nodeSource%5BKME:OI-68EFE924426240239D42BE1F053AD80D%5D.nodeSnmp%5B%5D/avgBusy5?start=-100000&step=1&aggregation=MIN

2) According with the documentation, step=1 means:

Requested time interval between rows. Actual step may differ. Set to 1 for maximum accuracy.

When using Newts, it uses whatever value is configured for org.opennms.newts.query.minimum_step in opennms.properties instead the configured step on collectd-configuration.xml. This is kind of confusing as this is not the case when using RRDtool.

For now, you have to provide a more precise step, which is problematic if you have different collection step for different devices on collectd-configuration.xml, specially when the final user of this ReST end point doesn't know the collection interval for a given device.

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Show:

Jesse White November 7, 2016 at 12:19 PM

Alejandro Galue June 14, 2016 at 7:32 AM
Edited

both sounds good to me.

We should definitively work on the docs to eliminate (or try harder to minimize) the wrong assumptions (and assumptions in general), and make sure that what we say there is true.

That being said, we can keep the default (which doesn't make sense to me, because 1ms is a valid number even if it is not real in practice, so 0 should be: maximum accuracy). Then, we should say that RRDtool knows by design the value of the maximum step for any given time range, which is impossible to know in Newts as you said. Also, we should make minimum_step to be consistent with the default values in collectd-configuration.xml, because if eliminating assumptions is important, eliminating unexpected surprises for the user is even more important. For 90% of the installation (at least) the users use 5 minutes for data collection, so if I query Newts with the Measurements API to get the last 5 samples, and I got 50 (because minimum_step is 30sec) that will give me a first impression that something is wrong because I'm not collecting any data at 30 seconds, and (as expected) every 10 samples will have the same value.

Makes sense ? That should be the fix for this issue.

Jesse White June 13, 2016 at 3:55 PM

For 1), see .

For 2), we can update the docs to help make the behavior more clear, but there are currently no means of automatically deducing the collection step.

Fixed

Details

Assignee

Reporter

Labels

Components

Sprint

Fix versions

Affects versions

Priority

PagerDuty

Created June 13, 2016 at 3:28 PM
Updated November 9, 2016 at 6:39 PM
Resolved November 9, 2016 at 1:39 PM