[rrd-developers] Re: Future RRD Framework Requirements
jakeb at microsoft.com
Thu Jun 20 18:28:37 MEST 2002
Glad to see you are interested in development work.
I wonder if I might persuade you to take a second look at an idea I've
proposed before. As I understand it, you've outlined a proposal to
improve RRDtool and create a new front end for it. You think Cricket has
some good ideas, but it also has some weaknesses (and I concur). Rather
than an entirely new design, could some of your aims be achieved by
working with the existing software (RRDTool and Cricket).
For example, as we've discussed, the monitor-thresholds implementation
in Cricket is inefficient and not very scalable. But if there was an
alternative interface to RRDtool update that always returned an array of
the most recent CDP values of the lowest resolution RRA, monitoring in
Cricket could occur in the same pass as data collection. This could be a
significant performance win. I am not certain of the details. There
would have to be a mechanism to handle the fact that a CDP is not always
generated on an update call. Perhaps returning the last CDP or unknown
value (as obtaining the last CDP might require additional disk access
during the update pass) or even PDP might work.
I've discussed primarily RRDTool details here, but obviously this idea
would require some changes to Cricket code as well. I think this would
be a great project for someone like you who has a broad perspective
spanning RRDTool and Cricket. Why don't I do this myself? Maybe at I
some point I will, when I have the time.
Well, there's my pitch. Maybe this pitch reflects my work experience in
operations. Software developers are always eager to build something new
with the latest and greatest. In operations, we usually have to work
with what's already there.
TV Services -- Network Operations
Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
More information about the rrd-developers