[mrtg] Large Master Config Vulnerability
bradmrtg at gmail.com
Fri Apr 18 20:38:28 CEST 2008
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.
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.
> > 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.:
> cpmCPUTotal5secRev.1&cpmCPUTotal1minRev.1:public at random-router.example.com:
> ::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
> 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
> mrtg mailing list
> mrtg at lists.oetiker.ch
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mrtg