"ENTRESSANGLE, ERIC (ERIC)" <[email protected]> wrote:
> 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. > > 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. Short answer - RRD does not store anything but rates, in particular it does not store temperatures or gauge values. 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. I'd argue that it's no less valid to normalise (say) temperature data than traffic flows. > 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. > > I did not find a satisfactory solution up to now, thanks for any hint. 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. 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. _______________________________________________ rrd-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
