[rrd-developers] Re: Future RRD Framework Requirements -every frontend has valueab le/special features

[Stanislav Sinyagin]

Thank you Rob for valuable comments (see my replies inline). 
Thanks to Cricket developers for their valuable critics too. 
I haven't yet decided if I try to base my work on Cricket, or start it anew. 

--- "Shipley, Rob" <rshipley at state.mt.us> wrote:
> 1. I think Berkeley DB is OK, but it is not intuitive. Even if accessing the
> key,values is fast, Cricket has proven that it doesn't really matter. For my
> installs, Cricket runs slower than MRTG which accesses ascii files.

I don't have much experience with large Cricket setups. What exactly 
runs slowly? Data collection or viewing?

> 2. The database scheme should not be based JUST on collections.

Please note that I proposed to use Berkeley DB only for storing the compiled 
configuration. It will be hidden by the Perl module, with XML as external 
interface, and Perl methods as internal one. 

> 3. Collections should be parallel or forked, but checked for validation
> previous to being collected. ie. smokeping the equipment, now you have
> collections for loss and delay, if it is reachable then collect via SNMP.

good ideas, I'll keep them till I'm busy with data collection. As I mentioned, 
at the moment the data colection is not the primary task.

> 4. Separate presentation and content. The power of XML is to provide a
> separation of how data is presented and how it is collected. 14all.cgi,
> grapher.cgi, indexmaker, are all static and excessive code. ie. I have 4
> small cgi scripts, but they don't have any embedded html code, they only
> generate a graph - the html code is generated dynamically using XML from our
> inventory database. Cricket embeds html and graphing code in the
> configuration, which I think needs to be separate.

I will think about that. In the first draft, I thought that would be user-defined 
HTML files with special keywords, like %SHORT_DESC%, which would be substituted.
Maybe XML/XSLT is even better. But I'm not sure about the speed. XSLT translation is 
quite slow (I use Gnome's libxml/libxslt, and they are great when using offline).


> 5. Should have plugins. A major problem with existing frontends is that to
> collect from a target that is not SNMP, you generally have to run an
> external script. 

right. 
 
> 6. Distributed collection points. 

good ideas, but again, data collection is not the urgent task. 

> 7. Provide historical and near-real time data. After collecting, near
> real-time data should be available and visible without generating a graph.
> If you see a problem, than you can take a look at the history. Our frontend
> provides near real-time data on availability, delay,loss, bandwidth. If any
> issues are spotted, then you can look at the graph - similar to NMIS.

Actually, I try to provide as much flexibility as possible. So, why not defining 
a view of textual output. 

> 8. Visibly appealing summary reports -daily,weekly,monthly. Provide monthly
> reports that provide statistics for the entire month. ie. With our
> collections, I am working on generating capacity planning reports for my
> managers using XML and GD:Graph3d. 

Well, that's a big issue how to present the tree. Maybe it's good to remember 
the type of view, and to try to use it when moving from one data source to another.

> To sum up, I would like to thank Tobi Oetiker for rrdtool. It is awesome,
> and has a lot of potential. I think that ALL the existing frontends have
> special features that are very valuable to providing a single framework.

you can say that again :)

With regards, 
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