[rrd-developers] Re: Future RRD Framework Requirements

[Stanislav Sinyagin]

Hi Jake and all, 

some parts of your message will be mixed:

> Glad to see you are interested in development work.

> 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.

I would say, it's not that I wanted to create something great
(though I wouldn't reject a bit of fame), but rather 
the conditions made me think in that direction. What's already there 
is either unapplicable, or needs too much adjustments to meet our needs.

I tried to combine the data that we collect by means of FlowScan
with a nice graphing engine with monitoring capabilities. 
Actually, there's no alternative to Cricket to do that. 

> 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). 

I have no complains about RRDTool. 

Cricket uses ds0,ds1... datasource naming. First I hacked 
the grapher a bit, then I discovered a bug and a patch... opened
more than 2 years ago, with little progress. 

And there are other opened bugs, hanging open for ages.
So, one of the weaknesses is lack of support. I can't say if I'm able 
to give support better than that. But I try to create something 
easily extendable, so that the others could develop it too.

The other weakness is common among the frontends: they are all 
data collection oriented. They are designed to collect some specific data, 
and they manage to display it. Once you have some data out of their context, 
it becomes too difficult to adaptate the tools. 
What I target, is context-independent data processing. That's why I 
don't even bother about data collection in the beginning stage. 

Also, I don't like the views concept in Cricket: if you want to 
see Holt-Winters forecast data, you have to name the view as "Holt-Winters".
Which is not very convinient and looks odd in the directory HTMLs.

And, you can't easily view data from different RRD files in one graph.
You remember, we discussed if it's possible to extent or replace the 
Holt-Winters method for aberrant detection. The easiest way for experiments 
is to store the auxiliary data in a parallel RRD file. But then you spend 
another effort in displaying that. RRGrapher.cgi solves that more or less, 
but it's just a raw viewer, not very convinient for data analysis and management.
I didn't give up with those ideas, just more urgent things came up...
 
> 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....

that would be great, but it does not solve any of the major (from my point of view)
weaknesses of Cricket. 

> 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.

I don't think I'd devote much time to developing a system with that many 
unsolved bugs. It doesn't make sence to proceed before all old problems are 
solved. 

With regards and thanks, 

Stan


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-developers
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi