[mrtg] Re: Long-term data stability

[Don R Maxwell]

Hello Alan!

This is precisely something that IS needed.  In my organization, I have used
MRTG on my own and it now has many people choosing to examaine network
traffic by means of it instead of a costly commerical package which claims
support for the aliasing you describe.  (As a note, I do not believe this
aliasing feature has been enabled or configured on our "official" traffic
polling program.)

Since I don't consider myself to be a programmer, I have not pursued such.
However, I would be delighted to assist in the development or testing in any
way that I can.

     --Don

> -----Original Message-----
> From: mrtg-bounce at list.ee.ethz.ch
> [mailto:mrtg-bounce at list.ee.ethz.ch]On
> Behalf Of Alan J. Flavell
> Sent: Sunday, August 01, 1999 8:36 AM
> To: mrtg mailing list
> Subject: [mrtg] Long-term data stability
>
>
>
> 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
>

--
* 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