Hi all My first tries to activate TRAPS were unsuccesful, is difficult to me to handle C++
The point behind my interest to get TRAPS into SQUID is because I have to monitor SQUID, so TRAPS is my first option If this is not available, in the meantime I can check the logfiles of Squid, but I face there is no a document where is listed all posible errors with its meanings Is there such document anywhere ? Or, does something approximated exist ? And, in case all answers are no.... would be feasible to "inspect" the source code and create such document ? -----Original Message----- From: Henrik Nordstrom [mailto:[EMAIL PROTECTED] Sent: lunes, 11 de julio de 2005 22:51 To: Lombao, Cesar Cc: Squid Developers Subject: 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