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

[Shipley, Rob]

When looking over the documentation  about rrd's future framework, I think
that there are other issues to address:
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.
Cricket has too much perl code, in my opinion. This makes it hard to
customize. However, cricket does have a good concept on hierarchical
configuration.
2. The database scheme should not be based JUST on collections. We have
developed a rrdtool frontend for our organization that polls data from an
equipment inventory database - homegrown Access Database with forms. It
doesn't rely on someone changing sysLocation, sysContact etc on the
equipment. Wouldn't it be great if you could use the same database to store
and run reports on your equipment, interfaces, circuits, location, contacts
etc? Not just bragging, but we do. I highly doubt we could do that with
Berkeley DB as easily.
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.
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.
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.  
6. Distributed collection points. To reduce server cpu,memory usage, how
about using collection points that dump their data on the collection server
every 24 hours in a tftp directory? For example, clients that are collecting
application response data. The collection server updates the rrd databases
nightly. (This is just an idea to get away from the SNMP mentality) -
similar to remstats
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.
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. 
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.


-----Original Message-----
From: Jeremy Hinton [mailto:jgh at visi.net]
Sent: Thursday, June 20, 2002 8:58 PM
To: Bert Driehuis
Cc: RRD_DEVS (E-mail)
Subject: [rrd-developers] Re: Cricket issues [was: Future RRD Framework
Requirements]



On Fri, 21 Jun 2002, Bert Driehuis wrote:

> So, my request to the esteemed readership: if you have issues with
> Cricket, please follow up in cricket-users or cricket-developers (not
> both, please :-)  If you want to develop the kick-ass successor to
> Cricket, please do so -- you'll find that most Cricket developers will
> be happy to support you and probably even change over to your system
> when it's done.

I realize this is the RRD list, and not a cricket list, but...

HEAR HEAR! Cricket has issues, but it does do many things right, and has a
good potential for expandability. Reading through your ideas at your
project site (http://rrfw.sourceforge.net), alot it sounded almost like
ideas for cricket 1.1. jakes view patches are moves in the same direction,
and theres already been discussion of revamping the config tree internals.
If you feel that something new needs to be started, thats understandable,
but i think cricket is an excellent platform to build on.

-jeremy



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

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