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
