[drraw-users] drraw "cluster"?

[Eric Law]

RRD XPORT is not the same as DUMP... it's more like FETCH.
You basically use it like GRAPH but the values get printed rather than drawn
into a PNG.
Think of it as getting your graph data in XML/CSV rather than PNG.
If more RRD web interfaces did this, then I'd actually have access to
network data that I could
harvest this data and include it in my own graphs (OS and Business metrics)
and the whole user experience would improve.

oooOOooo 1.3 beta is out... [thanks!]
the single wiki page doesn't mention much about the daemon and delayed
writes,
but references MMAP IO, which mentions writing only modified blocks to
disk... I thought that was what it did before.
I also see yet-another-change of libs, so the build instructions are ever
changing.... oh well.
My problem is that even with 4GB of RAM across several servers, I cannot
hope to keep even most of the RRDs in memory,
so while the in-core performance has improved, I still get hammered on IO.
I've been resorting to pre-processing my RRD updates into batches sorted by
which RRD they update, which improves performance notably.

loose integration at the UI level is still desirable when you have several
large remote datacenters
and tons of datacenter specific metrics provide little value if that
datacenter is down.
Site generic data still needs to be consolidated, but can be done by
fetch-n-store in a single central location,
but the datacenter specific doesn't need to be central if the UI can still
fetch information from a remote UI.
I suppose this could be done without XPORT if you 'layer' transparent
PNGs.... or just show datacenter specific data
on the page with separate PNGs (I do that now too).

On 9/13/07, Fabien Wernli <wernli at in2p3.fr> wrote:
>
> On Wed, Sep 12, 2007 at 04:46:02PM -0400, Eric Law wrote:
> > * reduce IO load on RRD updates (ie: keep more in memory for longer
> periods,
> > or optimize for updates like the rrd daemon alluded to would do).
>
> I believe Tobias Oetiker has put quite some work on this matter:
>
> http://oss.oetiker.ch/rrdtool-trac/wiki/RRDtool13
>
> > Imagine a drraw URL call that would export the data in csv/xml, much
> like
> > RRD XPORT does today....
>
> you're not talking about exporting the actual rrd here are you? more like
> exporting the parts that need to be plotted, right?
>
> > Anyone want to work on such a beast?
>
> let's wait for rrdtool 1.3 first ;)
>
> _______________________________________________
> drraw-users mailing list
> drraw-users at taranis.org
> http://web.taranis.org/mailman/listinfo/drraw-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://web.taranis.org/pipermail/drraw-users/attachments/20070913/461254f9/attachment.html