[mrtg] Long-term data stability

[Alan J. Flavell]

Greetings,

An issue which has concerned me about the automatically-generated
configuration files from MRTG is that there's no long-term stability
of function about the maintained data.  For example if a site gets a
new router, then the Target names in the generated configuration file
are going to change, so there will be no long-term continuity of
function.

Then one is left with a heap of old.router.name.N.log data files, that
no longer get plotted, and a collection of new.router.name.N.log files
that show recent developments but whose earlier history doesn't exist.
It can even happen that a specific interface or IP number gets given a
different function, so that the plot shows earlier developments of one
kind of traffic together with later developments of quite a different
network link.

This can of course be circumvented when creating a configuration file
manually: then the Targets can be named for their logical function
rather than for the router name and interface number, or its IP
number, neither of which are necessarily stable enough for retaining
an overview of the network.

Having been repeatedly frustrated at the effort involved in producing
hand-crafted configuration files, versus the above shortcoming in any
of the available cfgmaker* scripts, I'm working on an idea.

The idea is to create a data file (I'm denoting it an "aliases" file)
that lists my logical function names against their actual Target names
as they would be derived by the cfgmaker script.  (I'm basing this on
the 2.8.6 version of the cfgmaker_ip script).  This data file is
sucked in to the script by an additional "-a aliasfile" option on the
commandline of the cfgmaker* script.

When the script is about to create a configuration entry, it checks
(in a hash that has been derived from the aliasfile) to see if it can
find an appropriate logical function name for the target, and if so,
it uses that as the configuration Target instead.

As the router configuration(s) change from time to time, the aliasfile
would be updated and the cfgmaker* script would be run again, followed
by indexmaker.

It wouldn't surprise me to hear that something of this kind already
exists somewhere, but I didn't find it.  Anyhow, does this sound like
something that people would like to have, when it's working?  Any
comments on the suggested implementation?

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