Any updates on the usage of collectd with rates?
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: [email protected]
IRC : ydary
On Tue, Feb 28, 2017 at 4:17 PM, Yaniv Dary <[email protected]> wrote:
>
>
> Yaniv Dary
> Technical Product Manager
> Red Hat Israel Ltd.
> 34 Jerusalem Road
> Building A, 4th floor
> Ra'anana, Israel 4350109
>
> Tel : +972 (9) 7692306 <+972%209-769-2306>
> 8272306
> Email: [email protected]
> IRC : ydary
>
>
> On Tue, Feb 28, 2017 at 4:06 PM, Francesco Romani <[email protected]>
> 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-Septemb
>> er/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
>>
>>
>
_______________________________________________
Devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel
