[mrtg] Setting up RRD Tools.

[Niall O'Reilly]

	Dan,

	Thank you very much for your reply.  Some of this is information
	which is new to me, or which I wasn't sure of.  Other parts are
	"old news", but still interesting.

	Comments in line ...

On 4 Feb 2008, at 14:53, McDonald, Dan wrote:

> an RRDtol front-end like routers2.cgi expects to find each router in a
> separate file.  That makes it possible to display huge hierarchies of
> routers and sites.  So, using separate files helps scale the display
> functions, making the overall system more scalable.

	You seem to be saying that routers2.cgi treats "Include" as
	an implicit configuration instruction for grouping or
	partitioning the display.  This is what I understood from
	some reading, but I haven't yet had the opportunity to confirm
	from experience.

	Overloading "Include" in this way seems to me to introduce
	undesirable brittleness.  IMO, "Include" should simply make
	a collection of configuration files appear as one large file,
	and organization of the display should be determined by
	explicit configuration directives.

> If I had to run cfgmaker for all of my managed boxes at once, it would
> take close to an hour, but with my configurations segmented I can
> re-learn individual devices in just a few seconds.  This "ease of
> administration" is actually a critical scalability concern when you  
> have
> large mrtg monitoring complexes.

	I understand.  Since back whenever I first lost monitoring because
	of a syntax error in specifying some hand-crafted new target, I've
	always thought of this as a "basic survivability" issue rather than
	in terms of "scalability".  I see what you mean too.

> Running under linux, a large number of Includes: with forks: 20 is  
> going
> to perform much better than twenty separate instances, as there is  
> less
> parsing to do and more shared code.  I know that is comparing "2" and
> "3", but again it continues to demonstrate a more scalable solution.


	OTOH, the overhead you mention only occurs during startup, and
	re-starting is less disruptive if only a single instance,
	without "Include", has to be interrupted.

	I'm wondering whether your idea that a single generously-included
	and well-forked instance will perfom better than an equivalent
	collection of include-free instances is based on a
	"high-quality educated guess" (not to be discounted), or rather
	on measurements. Has anyone done a study and published the results?


	Best regards,

	Niall O'Reilly
	University College Dublin IT Services

	PGP key ID: AE995ED9 (see www.pgp.net)
	Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.oetiker.ch/pipermail/mrtg/attachments/20080206/1352b9dc/attachment.bin