Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109

Tel : +972 (9) 7692306
        8272306
Email: ydary@redhat.com
IRC : ydary

On Tue, Feb 28, 2017 at 4:06 PM, Francesco Romani <fromani@redhat.com> wrote:

On 02/28/2017 12:24 PM, Yaniv Dary wrote:
> We need good answers from them to why they do not support this use case.
> Maybe a github issue on the use case would get more attention. They
> should allow us to choose how to present and collect the data.
> Can you open one?
>

I can, and I will if I get no answer in few more days.
Meantime, among other things, I'm doing my homework to understand why
they do like that.

This is the best source of information I found so far (please check the
whole thread, it's pretty short):

https://mailman.verplant.org/pipermail/collectd/2013-September/005924.html

Quoting part of the email

"""

We only came up with one use case where having the raw counter values is
beneficial: If you want to calculate the average rate over arbitrary
time spans, it's easier to look up the raw counter values for those
points in time and go from there. However, you can also sum up the
individual rates to reach the same result. Finally, when handling
counter resets / overflows within this interval, integrating over /
summing rates is trivial by comparison.

Do you have any other use-case for raw counter values?

Pro:

  * Handling of values becomes easier.
  * The rate is calculated only once, in contrast to potentially several
    times, which might be more efficient (currently each rate conversion
    involves a lookup call).
  * Together with (1), this removes the need for having the "types.db",
    which could be removed then. We were in wild agreement that this
    would be a worthwhile goal.

Not for adding units:

https://github.com/collectd/collectd/issues/2047

 

Contra:

  * Original raw value is lost. It can be reconstructed except for a
    (more or less) constant offset, though.

How is this done?

 

"""


Looks like this change was intentional and implemented after some
discussion.

I understand this, but most monitoring system will not know what to do with this value.

 

Bests,

--
Francesco Romani
Red Hat Engineering Virtualization R & D
IRC: fromani