[mrtg-developers] Question- opinions on MRTG support for rrdcached

[Steve Shipway]

If MRTG runs via rrdcached (RRDTool 1.4) , then there's a decision to make
on the RRD file checks.

 

When it runs locally or via rrdcached with UNIX sockets, then the existence
check is quick and simple, and the check for the rrd file having the correct
max/type settings is relatively cheap.

 

However when running via rrdcached with TCP sockets, you have the problem
that to test for existence and parameters you need to do a remote rrdinfo,
which is relatively expensive, particularly since it seems to happen for
ever RRD file on every cycle.

 

It could be changed to only attempt creation of the RRD file if the update
fails, but this would mean that changes of MaxBytes/type wouldn't be
actioned.  The test for rrd Maxbytes/type should only be done once - on
initial cfg file processing - but I'm not sure at the moment how to manage
this.

 

Would people prefer to omit the rrdtune step and do a create attempt only
after a failed update (fast), or check the rrd file existence and
configuration every cycle (slow but flexible)?  Or maybe this should be a
global option in the cfg file?

 

As for Threshold checks, these have to be omitted if you're using rrdcached,
as rrdcached does not yet support updatev.

 

I've also not yet quite managed to get Routers2 to work via the rrdcached
since the remote rrdfetch doesn't support -s, but we're close.

 

Steve

 

  _____  

Steve Shipway

steve at steveshipway.org

Routers2.cgi web frontend for MRTG/RRD; NagEventLog Nagios agent for Windows
Event Log monitoring; check_vmware plugin for VMWare monitoring in Nagios
and MRTG; and other Open Source projects.

Web: http://www.steveshipway.org/software

P Please consider the environment before printing this e-mail 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/mrtg-developers/attachments/20100920/64b0b8ff/attachment-0001.htm