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

[Francesco Romani]

No updates yet. I'll move forward filing a github issue, hoping to
gather more feedback.


Bests,


On 03/12/2017 03:38 PM, Yaniv Dary wrote:
> 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 <mailto:ydary at redhat.com> IRC
> : ydary
>
> On Tue, Feb 28, 2017 at 4:17 PM, Yaniv Dary <ydary at redhat.com
> <mailto: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 <tel:+972%209-769-2306> 8272306 Email:
>     ydary at redhat.com <mailto:ydary at redhat.com> IRC : ydary
>
>
>     On Tue, Feb 28, 2017 at 4:06 PM, Francesco Romani
>     <fromani at redhat.com <mailto: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
>         <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
>     <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
>
>
>

-- 
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/20170313/3b3ecaf0/attachment.html>