[rrd-developers] Modify step size of existing RRD
peter at stamfest.at
Sat Mar 8 13:38:50 CET 2014
Am 2014-03-08 11:34, schrieb Peter Stamfest:
> Dear List!
> I have just pushed a new version of my rrd modify work to
> https://github.com/stamfest/rrdtool-1.x in branch rrdmodify-master.
Which brings me to a very important point I am pondering over for some
time now: should I integrate the experimental modify command into
rrdtune? This would especially mean that all the language bindings that
use the argv based interface would work out of the box... This only
really has to be decided before releasing a new version, but the earlier
the better. Tobi?
> This is the first "public" version to have support for a reduction of
> the basic RRD step size. Note that there are restrictions about the
> possible new step size: The current step size must be a whole-number
> multiple of the new step size. The modification works by recording the
> new step size and adjusting the pdp count of all existing RRAs. This
> also means, that reducing the step size will most likely only make sense
> if you add a new RRA with a pdp count of 1 so you can take advantage of
> the then higher resolution.
> Given in.rra with step size 300 and initial RRA definitions of
> RRA:AVERAGE:0.5:1:100 and RRA:MAX:0.5:6:1000 the command
> rrdtool modify -s 60 in.rrd out.rrd RRA:AVERAGE:0.5:1:250
> should result in out.rrd having 3 RRAs with definitions of
> RRA:AVERAGE:0.5:1:250 (just added) and RRA:AVERAGE:0.5:5:100 and
> RRA:MAX:0.5:30:1000. In addition, the new RRA will have been populated
> using data from the pre-existing AVERAGE RRA.
> It is not (yet?) possible to increase the step size, mostly because the
> use case is not entirely clear and additional requirements regarding the
> old and new step sizes have to be met.
> Tobi: This should be pull-able... although the travis integration still
> does not work as it should.
> All others: Feedback would be extremely welcome both on bugs and the
> proposed commandline syntax. What other structural modifications would
> anybody be interested in? Also, somebody might have a look at supporting
> the more esoteric CFs within rrd_modify.c
More information about the rrd-developers