Re: [squid-users] SNMP MIB updates?

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 16 Apr 2009 00:23:10 +1200

Gregori Parker wrote:
> I was creating a fresh batch of cacti graph templates for Squid the other day (focused on reverse proxy setups, I will release them soon), and while crawling the Squid MIB I noticed that HTCP metrics don't register anywhere. Furthermore, the entire MIB seems to be in need of updating - here's a list of things I would like to understand or see updated at some point...
>

Excellent to see someone working on that update and the squid SNMP stuff
too. Thank you.

In answer to your points below, please retain followup to squid-dev
mailing list (cc'd) about any further on these.

Firstly which of the _3_ Squid MIB are you trying to get updated?
  Squid-2.x, 3.0, or 3.x MIB?

> * cachePeerTable should be re-created so that it doesnt index by ip address (results in OID not increasing error when walking!)

While we do see this as a minor issue in need of cleanup one day its not
a major problem (the -Cc options of snmpwalk is created for such) but
has major alterations needed to fix it.
If you want to spend the time please discuss ideas on how it can be
solved with us first. There have been many discussions and attempts in
the past which can be leveraged to reduce dead-end work.

> * update cacheIcp* to register HTCP now that it is built in by default

Good idea, but I would rather see a cacheHtcp* added instead of
cacheIcp* extended with a new protocol.
If it does make more sense to details them together then a better name
than cacheIcp needs to be chosen for the joint tables.

> * add a cacheHttpMisses (and pending, and negative) to cacheProtoAggregateStats

okay, details on what you are thinking though please.

> * more detailed memory counters - the current cacheMemUsage doesnt seem to measure how much memory is being used for caching (in my diskless cache setups, the counter flatlines around 600MB when I know there is much more than that being used)

Thing to look at here is SNMP data type the counter is being forced
into. We hit a similar issue just a short while ago that turned out to
be a too-small field. I don't know of SNMP being updated for sizes since
the 64-bit stuff went default.

Otherwise might be explained by; not all memory is accounted for by
Squid MemPools, certain objects and such use stack, or unaccounted heap
space. These are all design choices within the code itself, not an SNMP
solvable issue.

> * cacheCpuUsage is constant at 8% across a variety of squid servers at all times - I can see that this doesnt match up with what I see locally via top or in my normal unix cpu graphs.

Does sound like trouble. At least it needs to be investigated and any
results documented about whats actually going on.

> * throughput should be measured in bits instead of kilobytes throughout the MIB

Ah, nice, but AFAIK the output reflects the level of details kept in
counters. An upgrade of that I agree is needed. Just be careful not to
get into too much work there.

>
> Btw, I've been trying to understand the differences between the cacheProtoAggregateStats and cacheIpCache tables - I get very different numbers in terms of requests, hits, etc and I cant account for it.
>

Anyone have info on this?

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE14
   Current Beta Squid 3.1.0.7
Received on Wed Apr 15 2009 - 12:23:28 MDT

This archive was generated by hypermail 2.2.0 : Wed Apr 15 2009 - 12:00:02 MDT