[rrd-developers] Re: Future RRD Framework Requirements -every frontend has valueab le/special features
ssinyagin at yahoo.com
Sat Jun 22 17:59:27 MEST 2002
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.
> 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 :)
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
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