Re: [mrtg] Large Master Config Vulnerability

--===============0432383275==
Content-Type: multipart/alternative;
boundary="----=_Part_7462_20661772.1208543908645"

------=_Part_7462_20661772.1208543908645
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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@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@r andom-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@lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
>

------=_Part_7462_20661772.1208543908645
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I was using an older version and after updating it has definitely improved the speed. I also changed the other options everyone mentioned. <br><br>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.<br>
<br>I'll keep working on it and if I find anything, I'll report back here. =)<br><br>Thanks for the help.<br><br>Brad<br><br><div class="gmail_quote">On Thu, Apr 17, 2008 at 12:38 PM, Daniel J McDonald &lt;<a href="mailto:dan.mcdonald@austinenergy.com">dan.mc donald@austinenergy.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Thu, 2008-04-17 at 11:39 -0500, Brad Lodgen wrote:<br>
&gt; Hi everyone,<br>
&gt;<br>
&gt; I'm running a master config with hundreds of include lines and<br>
&gt; thousands of targets.<br>
<br>
</div>Ditto.<br>
<div class="Ih2E3d"><br>
&gt; This type of setup is vulnerable to errors in config files and/or<br>
&gt; changes made in the field not being immediately updated within the<br>
&gt; configs. If there are a few errors or changes out in the field to<br>
&gt; ports causing them to become 'unpollable', it causes the MRTG polling<br>
&gt; interval to go over five minutes because it's retrying those<br>
&gt; interfaces.<br>
<br>
</div>What version are you running? &nbsp;Dead host detection got noticeably better<br>
in 2.15.1<br>
<div class="Ih2E3d"><br>
<br>
&gt; At the moment, with only about 30 error lines in my log(equating to<br>
&gt; about 15 interfaces/targets), it's causing MRTG to take 7-9 minutes to<br>
&gt; complete polling.<br>
<br>
</div>How many forks are you running? &nbsp;More forks will help. &nbsp;I also limit<br>
retries. &nbsp;e.g.:<br>
Target[random-router.example.com.cpu1]:<br>
cpmCPUTotal5secRev.1&amp;cpmCPUTotal1minRev.1:publ ic@random-router.example.com::2:1:1:3<br>
<br>
::2:1:1 is read &quot;try twice. &nbsp;Wait 1 second after the first attempt, and<br>
add a second for each subsequent attempt&quot;. &nbsp;So, I have a maximum of 3<br>
seconds. &nbsp;The default is 3 polls with a 10 second timer, or 30 seconds.<br>
<div class="Ih2E3d"><br>
<br>
&gt; &nbsp;As this is a very small percentage compared to the total amount of<br>
&gt; targets being polled, I'm trying to figure out a way to get around<br>
&gt; this, if possible, or at least to minimize the effects.<br>
&gt;<br>
&gt; Is anyone else running a system like this or does anyone have<br>
<br>
&gt; suggestions to try?<br>
<br>
</div>Yes. &nbsp;Current code. &nbsp;Plentiful forks. &nbsp;Short timeouts.<br>
<br>
That doesn't affect one other problem I have. &nbsp;If I get an Include: line<br>
without the file existing (it happens, particularly since I generate the<br>
master file from a script reading a database...) then the whole thing<br>
just stops. &nbsp;I would like a &quot;try to include&quot; option that looks for the<br>
file, but if it can't find it will still process the other 471 include<br>
files...<br>
<br>
I know, I know, I should just write it and submit the code.... &nbsp;Maybe in<br>
August I might have a few days...<br>
<br>
--<br>
Daniel J McDonald, CCIE #2495, CISSP #78281, CNX<br>
Austin Energy<br>
<a href="http://www.austinenergy.com" target="_blank">http://www.austinenergy.com</a><br>
<br>
_______________________________________________<br >
mrtg mailing list<br>
<a href="mailto:mrtg@lists.oetiker.ch">mrtg@lists.oet iker.ch</a><br>
<a href="https://lists.oetiker.ch/cgi-bin/listinfo/mrtg" target="_blank">https://lists.oetiker.ch/cgi-bin/listinfo/mrtg</a><br>
</blockquote></div><br>

------=_Part_7462_20661772.1208543908645--


--===============0432383275==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
mrtg mailing list
mrtg@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/mrtg

--===============0432383275==--