[ovirt-devel] [monitoring][collectd] the collectd virt plugin is now on par with Vdsm needs

[Yaniv Dary]

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: ydary at redhat.com
IRC : ydary


On Tue, Feb 28, 2017 at 4:17 PM, Yaniv Dary <ydary at redhat.com> 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: ydary at redhat.com
> IRC : ydary
>
>
> On Tue, Feb 28, 2017 at 4:06 PM, Francesco Romani <fromani at 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-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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170312/62c2cb0a/attachment-0001.html>