[rrd-users] Re: distributed rrd files

[Philip Molter]

On Thu, May 31, 2001 at 12:26:58AM +1000, Keith Sinclair wrote:
: 
: Team,
: 
: To enable distributed management in NMIS (http://www.sins.com.au/nmis/) 
: I use a couple of simple CGI scripts which can be polled from another 
: system to get information like what is being managed and summary stats, 
: etc.  The graphing routine is all done by CGI too, so i can just embed 
: graphics in any web page I like.  Very easy to scale and easy to manage, 
: just deploy the software and manage a list of servers.
: 
: I even have a very basic lightweight HTML for dumb browsers, ie WAP, etc.
: 
: Is that enough information?

What are you using for your graphing and how are you doing it?

Let's say I have a setup like this:

  Box 1: RRD files 1-5
  Box 2: RRD files 6-10
  Box 3: Web server

Let's say I go to Box 3 and request a graph that combines data from RRD
file 3 and RRD file 7.  Since right now, RRD graphing is tied to files
on a disk, you would have to do one of three things:

  1) transfer RRD 7 from Box 2 to Box 1,
     run graph commands, send graph to Box 3
  2) transfer RRD 3 from Box 1 to Box 2,
     run graph commands, send graph to Box 3
  3) transfer RRD 3 and RRD 7 to Box 3, run graph commands

What I'd like to do is be able to have Box 3 say, "Combine the data
from Box 1/RRD 3 and Box 2/RRD 7 and graph".  I'm not talking about a
GD graph or anything, but RRDs internal graphing routines (which are GD
based, yes I know), which can do GPRINTs and the like.  AFAIK, that
would require a completely different logic than the one which RRD
supports now (separation of graph routines from data manipulation,
etc), as well as changes to make the RRD file format more machine
universal.

Does your system support a configuration like that?

The reason for separating the RRD files to different boxes is simply
the sheer volume of data we're collecting.  Being able to have them on
separate boxen means that we'll be able to mirror data more
efficiently, store RRD data with greater consideration for network
topology, and quickly expand service by adding remote disk locations.
Using them as basically a piecemeal replication of a master system
defeats the purpose.

Again, this isn't something I expect done now anytime in the near
future, but if anyone's doing something like this, it'd certainly be
great to details.

* Philip Molter
* DataFoundry.net
* http://www.datafoundry.net/
* philip at datafoundry.net

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