<html><head></head><body>Excellent summary Simon.<br>
<br>
Eric, check out Zabbix. I use MRTG, rrdtool and Zabbix in different circumstances.<br><br><div style='font-size:10.0pt;font-family:"Tahoma","sans-serif";padding:3.0pt 0in 0in 0in'>
<hr style='border:none;border-top:solid #E1E1E1 1.0pt'>
<b>From:</b> Simon Hobson <linux@thehobsons.co.uk><br>
<b>Sent:</b> 19 February 2014 01:41:33 GMT+11:00<br>
<b>To:</b> "rrd-users@lists.oetiker.ch" <rrd-users@lists.oetiker.ch><br>
<b>Subject:</b> Re: [rrd-users] Input values normalization<br>
</div>
<br>
<pre class="k9mail">"ENTRESSANGLE, ERIC (ERIC)" <eric.entressangle@alcatel-lucent.com> wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> I think I understood that rrdtool works with rates (through counter, derive, absolute types), and that in this case, the “normalization” step can make sense.<br /> <br /> But I’m more doubtful about the “normalization” for gauge type, for example when I graph a plain temperature, because it means that the temperature on my graph is never exactly the real input value, unless data source step and cacti’s poller are perfectly synchronized, but it is impossible when there are a lot of counters to retrieve.<br /></blockquote><br />Short answer - RRD does not store anything but rates, in particular it does not store temperatures or gauge values.<br />Longer answer - RRD is optimised to store rates with defined retention periods. That is the be all
and end all of it's existence, having come out of the MRTG project. Now, many of the concepts used in storing rates are usful with other data types, and so it's been forced to accept gauge type values. But, internally these are still stored with the same processes.<br /><br />I'd argue that it's no less valid to normalise (say) temperature data than traffic flows.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> The solution I found is to set a data source step to 1 second to avoid normalization, but this produces big rrd files with a lot of redundant information.<br /> <br /> I did not find a satisfactory solution up to now, thanks for any hint.<br /></blockquote><br />Then RRD isn't the right tool for you. It's a bit like complaining that this oxy-acetalyne torch doesn't cut a very neat hole in the car panel I'm trying to drill. Wrong tool, if you need a precision hole cut then use a tool designed
for that.<br />If you need precision storage of arbitrary data points then use a different database. If you want efficient storage and aggregation, but not precision storage of individual readings, then use RRD.<br /><br /><hr /><br />rrd-users mailing list<br />rrd-users@lists.oetiker.ch<br /><a href="https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users">https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users</a><br /></pre></body></html>