CDEF's for RRa's

[matzmann]

Hi there,

first of all I must say that cacti is an absolutely great piece of work!
My compliments go to the author.

Secondly I got a question. I really don't know if it's a support question or a feature request (well more likely the latter one. That's why I'm posting it here.)

When monitoring 'counters', I recognized that very often you would like to have the consolidated data summed up rather than averaged (really a drawback of rrdtool not to provide such an update function, because I think you need it quite often (I'll post to Tobi Oetker)).
As I understand, it is nevertheless quite easily to circumvent this problem using CDEF's (just multiply by the number of points).

Ok, to the point:

In cacti you can only specify to use a CDEF for a graph item. But then this relates to all RRA's being used in that graph. But for the different consolidating time periods (week, month, etc.) you need different CDEF's if you want to sum up.
The problem could be solved if there was a possibility to add a CDEF function when defining a new RRA. For example, I would then define a 'Weekly (30min summed up)' RRA additionally to the 'Weekly (30min average)' RRA.
When adding a data source I could then choose 'Weekly (30min summed up)' instead of 'Weekly (30min average)'.
Also it would be intrinsically better to have the consolidated data CDEF'd and not only the graph.

This would be really great.

Probably it's a very easy hack, but I'm not so good in PHP and SQL to do it on my own.

Did I get something completely wrong and/or what could be the solution?

Your answers - my pleasure.

Thanks and greets.
Matthias

[raX]

Actually this is a really cool idea. Right now cacti does CDEF's on the graph-item level and I've heard suggestions to do it on the graph level, but never on the RRA level. This could potentially save users a lot of time though if this feature was needed. May I ask for sample CDEF function of this sort of idea in use? If I had that, I could probably go ahead and impliment it.

-Ian

[matzmann]

I thought about this one again and also read the rrdtool docu again, but I'm not sure if I'm getting it right.

Is it possible to use different CDEF's for the different RRA's of an RRD?
I think the answer is no.

So I cannot see an easy way of dealing with the problem because:
1. for multiplying you need a CDEF
2. you can only specify one CDEF when calling 'rrdtool graph', so this CDEF applies to all the RRA's in the RRD (sad).

The solution would be to use a variable in a CDEF call that does something like: CDEF:datasource,VAR,* where VAR is the number of points being consolidated BUT DIFFERENT FOR EVERY RRA.
This would have to be an rrdtool variable (not a cacti variable; am I right?) and if that doesn't exist then I can see no solution (but hopefully only my eyes are too bad to see it).

Maybe we should ask Tobi Oetiker to introduce such a variable in rrdtool?
But then certainly rax would have more persuasive potential in doing this than me;)

comments?

ps besides: the design and funcionality of the forum is really great!

[matzmann]

Hi again and good morning (to America).

my posting to the rrdtool mailing list has been worth the effort:)

It seems like the discussed feature is already being implemented in newer rrdtool versions. Until now I don't know exactly if it's only in the cvs-snap. Maybe it's even in the latest stable release.
At least in the docu of 1.0.37 you can read: "..consolidation
function (CF) (average,minimum,maximum,TOTAL,last)".
And this 'total' is said to be the totalled counter over an consolidation interval.
Using that you would only need to label the y-axes accordingly (scale changes from RRA to RRA).

I'll check this out.

Greets
Matthias

[gwynnebaer]

This would certainly be a welcome feature, and at the same time, I know how hard it must be, raX, to keep up with feature requests within your own product, and feature additions that go into rrdtool (and users of cacti want to immediately implement).

Any thoughts to objectifying the rrdtool calls to library calls perhaps? Might be too much effort portability-wise (libraries on multi-OSes), etc.

Just a thought.

-gwynnebaer