<div dir="ltr"><br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><pre cols="72"><span style="font-family:arial,helvetica,sans-serif">Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra&#39;anana, Israel 4350109

Tel : +972 (9) 7692306
        8272306
Email: <a href="mailto:ydary@redhat.com" target="_blank">ydary@redhat.com</a>
IRC : ydary</span></pre>
</div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Feb 28, 2017 at 4:06 PM, Francesco Romani <span dir="ltr">&lt;<a href="mailto:fromani@redhat.com" target="_blank">fromani@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
On 02/28/2017 12:24 PM, Yaniv Dary wrote:<br>
&gt; We need good answers from them to why they do not support this use case.<br>
&gt; Maybe a github issue on the use case would get more attention. They<br>
&gt; should allow us to choose how to present and collect the data.<br>
&gt; Can you open one?<br>
&gt;<br>
<br>
</span>I can, and I will if I get no answer in few more days.<br>
Meantime, among other things, I&#39;m doing my homework to understand why<br>
they do like that.<br>
<br>
This is the best source of information I found so far (please check the<br>
whole thread, it&#39;s pretty short):<br>
<br>
<a href="https://mailman.verplant.org/pipermail/collectd/2013-September/005924.html" rel="noreferrer" target="_blank">https://mailman.verplant.org/<wbr>pipermail/collectd/2013-<wbr>September/005924.html</a><br>
<br>
Quoting part of the email<br>
<br>
&quot;&quot;&quot;<br>
<br>
We only came up with one use case where having the raw counter values is<br>
beneficial: If you want to calculate the average rate over arbitrary<br>
time spans, it&#39;s easier to look up the raw counter values for those<br>
points in time and go from there. However, you can also sum up the<br>
individual rates to reach the same result. Finally, when handling<br>
counter resets / overflows within this interval, integrating over /<br>
summing rates is trivial by comparison.<br>
<br>
Do you have any other use-case for raw counter values?<br>
<br>
Pro:<br>
<br>
  * Handling of values becomes easier.<br>
  * The rate is calculated only once, in contrast to potentially several<br>
    times, which might be more efficient (currently each rate conversion<br>
    involves a lookup call).<br>
  * Together with (1), this removes the need for having the &quot;types.db&quot;,<br>
    which could be removed then. We were in wild agreement that this<br>
    would be a worthwhile goal.<br></blockquote><div><br></div><div>Not for adding units:</div><div><a href="https://github.com/collectd/collectd/issues/2047">https://github.com/collectd/collectd/issues/2047</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Contra:<br>
<br>
  * Original raw value is lost. It can be reconstructed except for a<br>
    (more or less) constant offset, though.<br></blockquote><div><br></div><div>How is this done?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&quot;&quot;&quot;<br>
<br>
<br>
Looks like this change was intentional and implemented after some<br>
discussion.<br></blockquote><div><br></div><div>I understand this, but most monitoring system will not know what to do with this value.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Bests,<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
--<br>
Francesco Romani<br>
Red Hat Engineering Virtualization R &amp; D<br>
IRC: fromani<br>
<br>
</div></div></blockquote></div><br></div></div>