Re: mrtg and squid

On Tue, 22 Dec 1998, Marc Lucke wrote:

> >> Target[squid]:
> >> 1.3.6.1.4.1.3495.1.3.1.5&1.3.6.1.4.1.3495.1.3.1.5:public@IPnumber:3401::4

> >You are trying to query the sysUpTime from port 3401, and squid's SNMP
> >doesn't support that OID.
> >
> >As long as the platform where squid runs also has a normal SNMP
> >port (161) active, you need the following configuration entry:
> >
> >routerUptime[squid]: public@IPnumber

> I had exactly the same problem. Doing the Router Uptime didn't seem to help
> me because it came up with more errors.

Please be more specific about what the symptoms are. This is too
vague to be of any benefit.

> I don't understand how Alan has
> used this system successfully & would really like to...

To tell the truth, I'm using this technique against my multicast
router, whose SNMP port is 9161, but the principle seems to be
identical, hence I offered this advice.

> The way I fixed it was to apply the patch in the SNMP section of the home
> page. This patch had 3 purposes

That's a maintenance nightmare. There should be one separate patch
for each separate purpose. IMHO, of course.

> (1) the ability to graph per hour or minute

That issue isn't addressed by my comments at all.

> (2) to change the default port to 3401

Changing the _default_ port is counterproductive, now that MRTG
supports configuring the port number from the configuration file.

> & (3) to supply the correct OIDs.

That's handy to be able to access them by name, but it isn't
essential.

...
> Purpose 2 worked well too

Not if you're including your router stats in the same MRTG plots!

> Purpose 3 would have worked execpt the OIDs where not the same as in Squid
> 2. So I had to actually edit my copy of my patched MRTG to change the OIDs
> to Squid 2s.

Sounds as if there are still advantages in writing the numbers
explicitly ;-)

> Then there was the other problem. The patch was made for MRTG 2.5.1 not
> 2.5.4c. Because my MRTG 2.5.4c was doing quite enough already anyway &
> because the differences between what I wanted to monitor were so
> wide-stretched, I decided to run both

Just the kind of maintenance problem that I had in mind.

When I wanted a patch to MRTG, I implemented it as an extension to the
configuration language, so that it didn't upset the normal working.
I hate creating maintenance nightmares for the future. When a new
version of MRTG appeared, that was able to do what my private patch
had done (albeit with an entirely different configuration directive),
I happily upgraded my configuration file, and tossed my own patch
away.

I'm sorry if this all sounds too dogmatic: I'm just trying to tell
it the way I see it, without taking up too much of your valuable time.

Seasons greetings. (Oops, wrong season in your case ;-)
Received on Mon Dec 21 1998 - 19:05:54 MST