RE: About SQUID and SNMP TRAPS , and snmp in general

On Mon, 11 Jul 2005, Lombao, Cesar wrote:

> Please, first, if I pollute too much the list let me know

Not at all. The list needs people participating.

> Second, at this very earlier stage, is my opinion to use more the CMU
> library, it looks like nice, and most if the things are already done.
> For instance, if my theory is correct, there is an ASN parser build,
> that builds the MIB on execution time based in a MIB file (the mib.txt).

snmplib in Squid is a heavily modified CMU SNMP 1.8.

> So, if you change something in the mib, you have not to modify much
> code. At the other side, the snmp_core creates the MIB in memory in a
> hard-coded way. I don't see any problem in terms of special select, or
> interrupt calls that can impact in squid.

If you intend to use the SNMP agent or client from CMU SNMP you will run
into some problems to fit this into the I/O loops of Squid.

> However, the CMU library copied into the /snmplib folder, seems not to
> create the sockets, it seems that is left to the implementation, and in
> that point the snmp_core has some functions to do that, I guess taking
> into account the problems of the select, and its blocking issues.

The code dealing with networking I/O has been replaced. The library
originally had all of that, but it wasn't useable from within Squid.

> So, this is my plan, and let's see if I'm able to get results (that
> remains to be seen):
> Take the current files in snmplib (The cmu library), create an snmp
> agent on my own, using the network functions in the snmp_core
> To test the TRAPS, I'll create some false TRAP definitions in the mib,
> and test it.
> If I'm success, then, later we can review if is posible to integrate
> into SQUID and how.

Probably easier to stay within Squid from start. You can do a lot of
testing from the debugger using suitable print statements simulating
various events.

> About what TRAPS to add
> I think this point is independent of the implementation itself
> We have three"type" of traps:
> 1) Those who inform about a "database" change (some oid modified)
> 2) Those who report about an event, for instance, "Corruption in the
> DNS..." "Internal error..."
> 3) The "standard" ColStart, WarnStart, etc, etc.
>
> For type 1, I think many other things come first

Indeed.

> For type 2, here is the point where I'm strngly interested. To have a
> proper monitoring, it would be nice when some critical issue happens a
> trap be sent. Which ones?

My suggestions in no special order:

- Fatal errors

- Startup/shutdown events

- peers detected dead/alive.

- Log write failures

- Cache oversized

- Close to running out of filedescriptors

- Threshold on select/poll loop latency, to warn when there is overload
conditions.

and probably a few more.

Regards
Henrik
Received on Mon Jul 11 2005 - 14:50:59 MDT