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

[Yaniv Dary]

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: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-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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170228/b3681510/attachment.html>