RRD XPORT is not the same as DUMP... it's more like FETCH.<br>You basically use it like GRAPH but the values get printed rather than drawn into a PNG.<br>Think of it as getting your graph data in XML/CSV rather than PNG.
<br>If more RRD web interfaces did this, then I'd actually have access to network data that I could<br>harvest this data and include it in my own graphs (OS and Business metrics) and the whole user experience would improve.
<br><br>oooOOooo 1.3 beta is out... [thanks!]<br>the single wiki page doesn't mention much about the daemon and delayed writes,<br>but references MMAP IO, which mentions writing only modified blocks to disk... I thought that was what it did before.
<br>I also see yet-another-change of libs, so the build instructions are ever changing.... oh well.<br>My problem is that even with 4GB of RAM across several servers, I cannot hope to keep even most of the RRDs in memory,
<br>so while the in-core performance has improved, I still get hammered on IO.<br>I've been resorting to pre-processing my RRD updates into batches sorted by which RRD they update, which improves performance notably.<br>
<br>loose integration at the UI level is still desirable when you have several large remote datacenters<br>and tons of datacenter specific metrics provide little value if that datacenter is down.<br>Site generic data still needs to be consolidated, but can be done by fetch-n-store in a single central location,
<br>but the datacenter specific doesn't need to be central if the UI can still fetch information from a remote UI.<br>I suppose this could be done without XPORT if you 'layer' transparent PNGs.... or just show datacenter specific data
<br>on the page with separate PNGs (I do that now too).<br><br><div><span class="gmail_quote">On 9/13/07, <b class="gmail_sendername">Fabien Wernli</b> <<a href="mailto:wernli@in2p3.fr">wernli@in2p3.fr</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Wed, Sep 12, 2007 at 04:46:02PM -0400, Eric Law wrote:<br>> * reduce IO load on RRD updates (ie: keep more in memory for longer periods,
<br>> or optimize for updates like the rrd daemon alluded to would do).<br><br>I believe Tobias Oetiker has put quite some work on this matter:<br><br><a href="http://oss.oetiker.ch/rrdtool-trac/wiki/RRDtool13">http://oss.oetiker.ch/rrdtool-trac/wiki/RRDtool13
</a><br><br>> Imagine a drraw URL call that would export the data in csv/xml, much like<br>> RRD XPORT does today....<br><br>you're not talking about exporting the actual rrd here are you? more like<br>exporting the parts that need to be plotted, right?
<br><br>> Anyone want to work on such a beast?<br><br>let's wait for rrdtool 1.3 first ;)<br><br>_______________________________________________<br>drraw-users mailing list<br><a href="mailto:drraw-users@taranis.org">
drraw-users@taranis.org</a><br><a href="http://web.taranis.org/mailman/listinfo/drraw-users">http://web.taranis.org/mailman/listinfo/drraw-users</a><br></blockquote></div><br>