[mrtg] Setting up RRD Tools.
Dan.McDonald at austinenergy.com
Mon Feb 4 15:53:14 CET 2008
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,
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.
> mrtg mailing list
> mrtg at lists.oetiker.ch
Daniel J McDonald, CCIE #2495, CISSP #78281, CNX
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.oetiker.ch/pipermail/mrtg/attachments/20080204/35ae53c0/attachment-0001.bin
More information about the mrtg