[mrtg] Re: Long-term data stability

Utsav Ratti Utsav_Ratti at MCKINSEY.COM
Tue Aug 3 15:53:00 MEST 1999


Alan,

If I understand you correctly, what you want to do is have an alias file
that maps to different interfaces using names that assist you better in
your work. You do not want to go to the hardware and rename the ports, but
rather create this alias file with your own names that map to existing
ports.

Is this correct so far?

If yes, why would a line like Target[jumping_jack_flash] in the mrtg.cfg
file not do the trick? Sure, cfgmaker isn't going to give you these logical
names automatically; you would have to go in and change them. But isn't
that an easier thing to do than writing an alias file and passing it to
cfgmaker?

Please clarify if you think I'm still missing the point. I would like to
help.

Utsav






"Alan J. Flavell" <flavell at a5.ph.gla.ac.uk> on 08/03/99 08:31:58 AM

Please respond to A.Flavell at physics.gla.ac.uk
To:   "Kaj J. Niemi" <kajtzu at iki.fi>
cc:   mrtg mailing list <mrtg at list.ee.ethz.ch> (bcc: Utsav Ratti)
Subject:  [mrtg] Re: Long-term data stability


On Tue, 3 Aug 1999, Kaj J. Niemi wrote:

> Perhaps you both need to take a quick look at a Cricket [1] & RRDtool [2]
> combination? They are, imho, in many ways a much more scalable solution
for
> larger projects that require scalability.

Well, we have now seen two votes for those packages, and certainly the
packages look attractive, and build on the expertise of the previous
tool; however, I don't see anything that directly addresses the
specific concern that I was raising.  Let me try to explain, if I may.

When one is automatically constructing a configuration file, the nodes
in the configuration have to get named in some way: in MRTG this is
for the Target[name] parameters, and will determine the naming of the
long-term data (*.log) and generated plot files.  Both cfgmaker, and
the respective tools of your recommended packages, are going to
grapple some parameters out of the actual routers (be they interface
numbers, IP addresses of interfaces, DNS names, or description strings
that have been provided by somebody).  That "somebody" may or may not
be me.

Now, along I come with a task to maintain some kind of long-term
statistics of particular features that are of interest.  What I'm
saying is that I would like the freedom to name the nodes according to
the logical function that they represent in my field-of-interest, and
(as the configuration and hardware of the network develop, under
forces which may not be under my direct control) I will be planning
to place my logical node names at the appropriate points in the
network as they develop, so that my plots represent the long term
development of the features of interest to us.  This may or may not
have any similarity to the features that are of interest to the man in
the computer centre that actually runs these boxes ;-)

Bear in mind that I'm responsible for some aspects of networking in an
academic department, and am allowed/encouraged to keep tags on what's
happening between our department and the Rest of the World, but I
don't myself procure and manage the campus and backbone equipment that
I'm being allowed to graph.

So, this is where I feel the need for a separate handle on naming the
nodes, and this is where the "-a aliasfile" option that I have now
implemented in cfgmaker* seems to be useful.  If others would find it
useful too, I'm happy to make it available (after some minor
tidying-up yet).

best regards

--
* To unsubscribe from the mrtg mailing list, send a message with the
  subject: unsubscribe to mrtg-request at list.ee.ethz.ch
* The mailing list archive is at http://www.ee.ethz.ch/~slist/mrtg







--
* To unsubscribe from the mrtg mailing list, send a message with the
  subject: unsubscribe to mrtg-request at list.ee.ethz.ch
* The mailing list archive is at http://www.ee.ethz.ch/~slist/mrtg


More information about the mrtg mailing list