[rrd-users] How to get MAX/MIN of non-rates?
tony at mountifield.org
Tue Apr 2 19:27:30 CEST 2013
Thanks for your help!
In article <57A1D4E203734E218387B2DC65C8FAF5 at DESK>,
Alex van den Bogaerdt <alex at vandenbogaerdt.nl> wrote:
> >> > > It appears the CF for MAX doesn't apply to values within a period,
> >> > > but
> >> > > only
> >> > > when periods are consolidated into longer periods.
> CF stands for Consolidation Function, so it makes sense it applies when
> consolidating the data.
> >> > In other words: instead of step==300 and steps_per_CDP==1, you set
> >> > step==1
> >> > and steps_per_CDP==300.
> > I've just tried it in a test setup, and it works perfectly. Of course,
> > I also needed to scale up the steps per CDP by 300 for the longer-term
> > RRAs in the file too.
> And you will probably have different RRAs which span the same amount of time
> at the same resolution, but with different CFs. (If not: you should.) These
> also need to be scaled to span the same amount of time per row.
> > One question, just out of interest: when an RRD file is defined with
> > multiple
> > RRAs of different resolutions and time durations, are the lower-resolution
> > RRAs calculated using the data from the higher-resolution ones, or are all
> > of them calculated independently, from just the input values as they
> > arrive?
> Short answer: the latter.
> Long answer:
> It has been a while since I looked at this, but I seem to remember the
> Data comes from your input and is transformed into a rate. If the data type
> is GAUGE, you are already giving it rates, so this part will be a no-op.
> Then the rate is normalized, so that it fits inside a standard timeslot. You
> have set that timeslot to 1 second now. I'm not sure what happens with time
> "N" in relation to sub-second precision; if so desired you could use
> timestamps such as "1364918323" and then normalizing will also be a no-op
> for sure.
> Then each of the RRAs gets a copy of this normalized timeslot, or timeslots
> if your update spans more than one update period. This is where the CDP_PREP
> area comes into play. As soon as there are enough updates received, thus as
> soon as one (or more) CDP timeslot can be filled, it happens.
> Each RRA has its own preparation area. When you changed step==300 into
> step==1, RRDtool does need to do more work, for each of the RRAs (300 times,
> and again multiplied by the number of RRAs). This is the price to pay. If
> performance is seriously harmed by this (I doubt it, unless you have a very
> large number of RRDs with many RRAs) then the solution will be more or
> faster hardware, or reconsider your change.
> rrd-users mailing list
> rrd-users at lists.oetiker.ch
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org
More information about the rrd-users