Interpolation of integers (in UI and storage) should be optional

[niko]

It feels weird when integers get interpolated. In our case we're monitoring listeners on a streaming server and "5203.167466666667 listeners" just feels plain wrong. IMHO either the interpolation should be somewhat clever and round floats to ints if the input is always ints or it should be optional in the js consoles library and the backend storage.

[brian-brazil]

This interpolation is in the /query_range endpoint, and we've discussed having an endpoint that doesn't do interpolation (though it can't evaluate expressions then either).

If you're using the console templates and associated graph library, you can configure how you want to values rendered such as the humanize function.

[juliusv]

Yeah, what's important to understand is that values are stored exactly as they are exposed, and only interpolated when doing a query. The historical reason for this was that to support aggregations like sum, avg, etc., we have to pick predetermined timestamps at which to sample all the existing time series, so that they're all aligned for aggregation. That naturally requires some form of interpolation. But for the special case of not doing any aggregations, it could be possible to not do any interpolation in the queries. It's just that this code is not there yet.

[beorn7]

Should we file an issue about the non-interpolation endpoint?

I'd be strongly opposed to "interpolation of integers only to integers". That would mathematically make no sense. The expectation value has nothing to do with the most likely value. (The expectation value of rolling a die is 3.5, although a die will never ever actual give you 3.5 as a result. That doesn't make 4 the better expectation value.)

[juliusv]

There's even a problem for non-aggregated time series though: the graphing libraries expect series to be time-aligned, especially for features such as stacking a graph. We'd have to experiment with that.

I filed #571

[juliusv]

Closing this in favor of #571

[juliusv]

@niko I think we neglected the last part of your suggestion though: offering controls over rounding in PromDash or the query language. Perhaps file another ticket in https://github.com/prometheus/promdash if you feel that's still missing?

Just in case it already helps, you can round values via the round(), floor(), and ceil() functions. E.g. http://prometheus.io/docs/querying/functions/#round(). If you wrap that around an entire expression, you should get only integers out.

[niko]

Thanks for the fast reply. Makes completely sense when I think about it. Will try round() et.all.

Thanks for the great project in general. I love it! :)

[juliusv]

Excellent, thanks! :)

On Mon, Mar 2, 2015 at 4:18 PM, Niko Dittmann notifications@github.com
wrote:

Thanks for the fast reply. Makes completely sense when I think about it.
Will try round() et.all.

Thanks for the great project in general. I love it! :)

—
Reply to this email directly or view it on GitHub
#570 (comment)
.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.