[mrtg] Setting up RRD Tools.

[McDonald, Dan]

On Sat, 2008-02-02 at 20:38 +0000, Niall O'Reilly wrote:
> On 2 Feb 2008, at 12:54, PAUL WILLIAMSON wrote:
> 
> > >>> "Niall O'Reilly" <Niall.oReilly at ucd.ie> 2/2/2008 7:27 AM >>>
> > > Would you care to explain how '3' has a scalability advantage
> > > over ''1'?
> > Because trying to maintain one file is a huge PITA.
> 
> 	No doubt, but an earlier poster seemed to declare an
> 	advantage due to scalability rather than to ease of
> 	administration.  This may be one aspect of scalability,
> 	but it's surely not the only, or even most important,
> 	one.

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.

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.

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.

> 
> 	I'm interested to know whether there's anything else
> 	to the claim.
> 
> 	/Niall
> 
> _______________________________________________
> mrtg mailing list
> mrtg at lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
-- 
Daniel J McDonald, CCIE #2495, CISSP #78281, CNX
Austin Energy
http://www.austinenergy.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.oetiker.ch/pipermail/mrtg/attachments/20080204/35ae53c0/attachment-0001.bin