Niall wrote: > There's more to it than just choosing between daemon and cron > modes. Running multiple instances of MRTG partitions the > target space so that the effect of non-responsive units is > contained, as is that of restarts occasioned by the release > of a new configuration file.
I've mitigated the first by having multiple threads, and setting a shorter timeout on queries. The second I've fixed with a patch for MRTG to make it reload the CFG file if it has changed; I've not yet submitted this patch to Tobi as it's still in test. > I've set up a SysVInit script which finds all the MRTG config > files in the standard configuration directory and starts an > instance of MRTG for each one. Every config file specifies > daemon mode. This will still have the problem of what to do when config files change, of course, plus memory requirements. However its rather close to what we're currently doing in production (until we get the patched MRTG into production and can go to daemon mode) > I've found it really convenient, when developing some new > helper script, to have a dedicated instance of MRTG so that > testing doesn't interfere with production data collection. We have a separate dev host for this; I agree you need to keep it separate some way or another. > Our main network-monitoring MRTG boxes have 50+ instances > collecting 10k+ target data series from 800+ units of network We're on 15,000 targets on 718 devices at the moment, split over 3 MRTG servers running MRTG/RRD with Routers2 in distributed mode. I'm currently working on bringing this together with rrdcached and full daemon mode for the MRTG instances, since we're experiencing some performance issues. With the features now available in rrdtool 1.4 there are a number more options available. The rrdcached will soon allow MRTG, RRDTool and Routers2 (the frontend) to exist on separate servers, to have multiple MRTG hosts collecting data going back to a single RRD server... If anyone is coming to LISA10 in San Jose this year, please come by the MRTG/RRDTool BoF session in the evening! It will be a good chance for everyone to share experiences and configurations for large setups. Steve Steve Shipway ITS Unix Services Design Lead University of Auckland, New Zealand Floor 1, 58 Symonds Street, Auckland Phone: +64 (0)9 3737599 ext 86487 DDI: +64 (0)9 924 6487 Mobile: +64 (0)21 753 189 Email: [email protected] Please consider the environment before printing this e-mail _______________________________________________ mrtg mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
