[mrtg] New MRTG install... Run as Daemon and RRD setup?

Niall O'Reilly Niall.oReilly at ucd.ie
Tue Sep 28 00:53:48 CEST 2010


On 27/09/10 22:27, Arvon Griffiths wrote:
> That being said, it sounds like the headaches involved in running it in Daemon mode are greater than the performance gain.  Opinions?

	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.  Choosing to do this has likely
	a bigger impact on how the configuration is managed than the
	daemon/cron choice has.

	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.

	We record traffic, wireless clients, DNS quality, DHCP leases,
	arp cache entries, server load and disk occupancy, router
	load and environmentals, and probably some other special stuff,
	using a mixture of classic SNMP and a variety of helper scripts.

	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.
	Likewise, whenever we roll out or upgrade a cluster of
	networks, and partially commissioned equipment is in yo-yo
	mode for a while, isolation of the affected MRTG targets
	helps. I've never been minded subsequently to merge
	configurations and reduce the instance count.

	Our main network-monitoring MRTG boxes have 50+ instances
	collecting 10k+ target data series from 800+ units of network
	equipment (wireless APs, switches, routers).  Our DHCP servers
	each have a couple on instances: one for monitoring the leases,
	another for local server monitoring (CPU, disk, ...), and
	sometimes a third.

	Our navigation and display functions are based on HTML::Mason
	and support both RRDtool and classic modes of operation of
	MRTG.  This allowed instance-by-instance migration to RRDtool
	with seamless continuity of display.

	We got here because of where we were coming from, and probably
	would choose a different path if we were starting now from cold.
	It works for me.  Steve's approach is quite different, as he has
	explained.  It works for him, as far as I can see from the
	opposite side of the world.  8-)

	Your mileage may vary.
	I hope this is of some interest.


	Best regards
	Niall O'Reilly
	University College Dublin IT Services



More information about the mrtg mailing list