+Yaniv Dary <[email protected]> can you help with a gap analysis to understand what values we expecet as RAW and not supplied by collectd?
On Mon, Mar 13, 2017 at 9:45 AM Francesco Romani <[email protected]> wrote: > 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 <+972%209-769-2306> > 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-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 > > > > > -- > Francesco Romani > Red Hat Engineering Virtualization R & D > IRC: fromani > > _______________________________________________ > Devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
