[mrtg] Large Master Config Vulnerability

[Steve Shipway]

There are several things to try, some have already been mentioned.  We
have >4500 targets being polled at the moment and so have had to do all
of them.

 

1) Set lower SNMP timeout and retry options as other people have said

2) Use the Forks: option to create multiple polling threads.  This does
not work in Windows, I think.  You need to set a Forks level appropriate
for your system, which depends on the available memory and CPU.

3) Run multiple instances of MRTG by having more than one master.cfg
file.  We actually do this by using a home-grown scheduler which builds
the master.cfg files on the fly and takes care of multithreading, and
also temporarily disabled a CFG file if the host/device is down.

4) Get a more powerful polling machine!  We use a 2x3GHz Xeon with 6Gb
memory.

5) Split your MRTG over multiple servers.  You can get an integrated
frontend if you use the distributed MRTG feature in routers2 

6) Get faster disks.  MRTG also bottlenecks on disk IO, so faster disks
can help the processing finish sooner.  We installed an Adaptec SAS
array with multiple spindles.

7) Upgrade MRTG and RRDTool to the latest versions.  Apparently they can
handle errors and IO better now.

 

Steve

 

 

________________________________

From: mrtg-bounces at lists.oetiker.ch
[mailto:mrtg-bounces at lists.oetiker.ch] On Behalf Of Brad Lodgen
Sent: Friday, 18 April 2008 04:39
To: mrtg at lists.oetiker.ch
Subject: [mrtg] Large Master Config Vulnerability

 

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.
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. 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?

Thanks in advance for any help!
Brad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/mrtg/attachments/20080418/26509917/attachment.html