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 [email protected] 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
_______________________________________________ mrtg-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/mrtg-developers
