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" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/rrd-developers WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
