[rrd-users] Re: New flame.

[Tobias Oetiker]

Today you sent me mail regarding New flame.:

*> Hi everybody,
*> 
*> Quite an interesting wave of discussions this morning. That's good.
*> Many people are using Tobi's tools (like MRTG, rrdtool,..) and they are
*> quite happy. Why? Because it simple to use for the specific tasks. 
*> SNMP, logs, etc.., are the best candidate for this tools.
*> 
*> But (there is always a "but"), from my experience with PM (performance
*> management) in GSM networks this tool can hardly face the needs. I'm
*> not talking about all specific hierarchy (this is not the job of
*> rrdtool)
*> an data types (which are OK) issues, but data collection, data
*> aggregation,
*> reporting and graphing.
*> 
*> 1. data collection. In GSM networks the equipment (BSC, BTS)
*> generates (according to its configuration) files with counters
*> observations. But this files can arrive sometimes out of order.
*> So no way to load not to old data.

if your data arrives out of order you have to sort it first ... if
you can't you have to use another tool ... this is at the core of
rrdtools way of operation ... 


*> 2. data aggregation. Some counters at some level of network
*> hierarchy must be aggregated from raw data to an consolidated
*> indicator. (EX. nb of call drop per set of cells). There is, let
*> say, a way to do that in the actual form of rrdtool. You can
*> report data form the graph command with a PRINT(?) statement and
*> then pipe it to another rrdtool instance.

so and what is the question ?

*> 
*> 3. reporting. A PM application must have a way to create text formatted
*> reports. rrdtool
*> has something like this, but it a collateral function.

rrdtool graph can create text reports beautifully ... just do not
list any graphically active functions ... like LINE or AREA


*> 4. graphing. The graphs that rrdtool are nice as long you graph
*> series of time data with trend lines (areas). But, for example,
*> what about maximum of drop calls for a day for set of cells. A
*> proper representation for this type of graphing is bar chart,
*> not trend lines.

only as long as you look at once day only ... once you look at a
week you have trend lines again ... probably a stacked view might
be interesting ... 

*> 
*> Theoretical solutions:
*> 
*> 1. There should be way to insert data in a rrdb for PDP data out of
*> order, but not is this
*> set of PDPs are not consolidated.
*>
*> 2. Data aggregation can be achieved by combining parts of update and
*> graph in one command.
*> 
*> 3. For reporting can be used the code from graph with some additions and
*> cleanings.
*> 
*> 4. For graphs should be used a library for graphs like gdchart
*> (http://www.fred.net/brv/chart/) and a new sintax for using all types of
*> charts and if it is possible, templates.
*> 
*> (For flammed comments please use my private address, don't overload the
*> mailing list.)
*> The comments and criticism are wellcomed.

no flaming necessary ... if you want to write a better rrdtool go
ahead ... you can also provide sensible patches to rrdtool and if
they fit with the general interface I will be more than happy to
integrate them ... 

cheers
tobi
 
*> Felix LUNGU
*> 

-- 
 ______    __   _
/_  __/_  / /  (_) Oetiker, Timelord & SysMgr @ EE-Dept ETH-Zurich
 / // _ \/ _ \/ / TEL: +41(0)1-6325286  FAX:...1517  ICQ: 10419518 
/_/ \.__/_.__/_/ oetiker at ee.ethz.ch http://ee-staff.ethz.ch/~oetiker


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