[rrd-developers] Re: rrdtool graph (fwd)

[Tobias Oetiker]

Today Alex van den Bogaerdt wrote:

 | Tobias Oetiker wrote:
 |
 | >  | Just as getting the numbers (snmp) is related to (but not built in to)
 | >  | rrdtool update, generating the graph should be related to rrdtool fetch.
 |
 | >  | rrdtool fetch could deliver the data in ascii format (and hopefully
 | >  | formatted to the users liking) or in binary format.  Just use a portion
 | >  | of the current rrdtool graph script language:
 |
 |
 | > Here I do not agree with you. Everybody (almost) who uses
 | > rrdtool needs the graphing part, so it makes no sense complicating
 | > everybodies lives by breaking it out of rrdtool into a seperate
 | > application.
 |
 | Sure, however also (almost) everybody needs to collect their data
 | using snmp and feed this to rrdtool update.  I don't think that should
 | go into rrdtool and in a similar way I try to make a point that the
 | grapher itself shouldn't be part of the executable.  This doesn't mean
 | that it shouldn't be part of the package.
 |
 | My goal is not to eliminate the grapher portion from the rrdtool package,
 | I'm merely suggesting it should not be integrated as tightly as it is
 | now inside the back-end part.

that is no problem ... as you know  the individual parts of the
rrdtool application can be linked standalone at a flick of your
finder ... rrdupdate already is, and so is rrdcgi ... the reason
for doing that would be faster load time where necessary ... this
does not apply for the grapher though as it is the heavy weight
itself and thus does not profit from loosing the other parts of
rrdtool as they are not big ...

but as I said, it does not matter, all function modules of rrdtool
are already quite independant fromeach other ... its just a matter
of linking them in different ways ...

As for snmp, if someone steps up and creates the all dancing,
singing snmp data cqusition tool and donetes it to rrdtool, that
would be great ...

then the frontends could realy concentrate on configuration and
presentation ...

 |
 | > I do agree that other parts of rrdtool can and will profit from
 | > having the data massaging facilities available in a module separate
 | > from rrdtool graph, but at the same moment I do not see why this
 | > would require rrdtool graph and a potential rrdtool report to be
 | > removed from the main body of the application ...
 |
 | The concept of separate front-end and back-end applications sort
 | of dictates this.  For one it would make it possible to use the
 | grapher part with another back-end, making the oracle fans happy.
 |
 | Generating a stream of numbers out of the RRAs is clearly a task
 | for a back-end (rrdtool).  Processing these numbers in whatever
 | format you like (be it a text-report or an image) is something that
 | falls in another catagory, namely front-end.  This all of course
 | being MHO and mine alone.

ok, call them what you like, no problem there ... for me, the
fontends are the guys organizing everything on a higher level,
defining how to configure a monitoring app with hundreds of targets
and presenting everithing in a sensibly organized manner ...

having the ability to feed external data to the grapher would
certainly bee nice, but this data source must also pass through the
massage part of rrdtool this after all makes up a large part of the
magic of the grapher, regardles where yor data comes from you do
not want to loose this ability ...

what we need to get external data into the grapher would be a
module which can eat arbitrary time/data pairs and normalize them
into a rrdtool data array ...

cheers
tobi
 |
 |

-- 
 ______    __   _
/_  __/_  / /  (_) Oetiker, ETZ J97, ETH, 8092 Zurich, Switzerland
 / // _ \/ _ \/ / phoneto:+41(0)1-632-5286  faxto:+41(0)1-632-1517
/_/ \.__/_.__/_/ mailto:oetiker at ee.ethz.ch http://people.ee.ethz.ch/~oetiker


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