[mrtg] Large Master Config Vulnerability

[Brad Lodgen]

I was using an older version and after updating it has definitely improved
the speed. I also changed the other options everyone mentioned.

It still doesn't seem to have answered the vulnerability that changes out in
the field bring if the configs aren't updated immediately. I just wish there
was some way I could make the system be more fault-tolerant instead of
having to make more smaller configs to get rid of it.

I'll keep working on it and if I find anything, I'll report back here. =)

Thanks for the help.

Brad

On Thu, Apr 17, 2008 at 12:38 PM, Daniel J McDonald <
dan.mcdonald at austinenergy.com> wrote:

> On Thu, 2008-04-17 at 11:39 -0500, Brad Lodgen wrote:
> > Hi everyone,
> >
> > I'm running a master config with hundreds of include lines and
> > thousands of targets.
>
> Ditto.
>
> > This type of setup is vulnerable to errors in config files and/or
> > changes made in the field not being immediately updated within the
> > configs. If there are a few errors or changes out in the field to
> > ports causing them to become 'unpollable', it causes the MRTG polling
> > interval to go over five minutes because it's retrying those
> > interfaces.
>
> What version are you running?  Dead host detection got noticeably better
> in 2.15.1
>
>
> > At the moment, with only about 30 error lines in my log(equating to
> > about 15 interfaces/targets), it's causing MRTG to take 7-9 minutes to
> > complete polling.
>
> How many forks are you running?  More forks will help.  I also limit
> retries.  e.g.:
> Target[random-router.example.com.cpu1]:
>
> cpmCPUTotal5secRev.1&cpmCPUTotal1minRev.1:public at random-router.example.com:
> :2:1:1:3
>
> ::2:1:1 is read "try twice.  Wait 1 second after the first attempt, and
> add a second for each subsequent attempt".  So, I have a maximum of 3
> seconds.  The default is 3 polls with a 10 second timer, or 30 seconds.
>
>
> >  As this is a very small percentage compared to the total amount of
> > targets being polled, I'm trying to figure out a way to get around
> > this, if possible, or at least to minimize the effects.
> >
> > Is anyone else running a system like this or does anyone have
>
> > suggestions to try?
>
> Yes.  Current code.  Plentiful forks.  Short timeouts.
>
> That doesn't affect one other problem I have.  If I get an Include: line
> without the file existing (it happens, particularly since I generate the
> master file from a script reading a database...) then the whole thing
> just stops.  I would like a "try to include" option that looks for the
> file, but if it can't find it will still process the other 471 include
> files...
>
> I know, I know, I should just write it and submit the code....  Maybe in
> August I might have a few days...
>
> --
> Daniel J McDonald, CCIE #2495, CISSP #78281, CNX
> Austin Energy
> http://www.austinenergy.com
>
> _______________________________________________
> mrtg mailing list
> mrtg at lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/mrtg/attachments/20080418/021b7f20/attachment.html