[mrtg] Setting up RRD Tools.
Niall.oReilly at ucd.ie
Wed Feb 6 13:47:17 CET 2008
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
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
> 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
> to perform much better than twenty separate instances, as there is
> 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?
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...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.oetiker.ch/pipermail/mrtg/attachments/20080206/1352b9dc/attachment.bin
More information about the mrtg