2008/7/16 Tilghman Lesher <[EMAIL PROTECTED]>: > > If they TRULY see themselves as a TELCO replacements for large shop > > they REALLY need to step up to > > proving INFO, WARN, ERROR messaging in a unified reliable manner. Such > > as a SNMP messaging ability for all > > INFO, ERROR, and WARN level messages. > > > That's an interesting idea, and perhaps someone might pick up on the idea > and > run with it. Perhaps you might and donate your efforts back to the > project. >
>From memory, I think I've read here (or developers list) a note (was it from Olle ?) aiming to unify logging, eventing, monitoring (AMI, SNMP, ...) APIs. I think that thread occurred when it was decided to include a version number in Manager interface. I agree this is an interesting idea ... The use case that made me ask this is here : I've got a running system which is working ok up to a moment it stops to dial out on ISDN-BRI spans (incoming calls are ok). When Asterisk is restarted, everything runs normally for a couple of days. Each time it can't dialout, I've got such messages (though, obviously the system has unused ISDN channels and should be able to dial out) : [Jul 11 10:01:47] WARNING[19997] app_dial.c: Unable to create channel of type 'Zap' (cause 34 - Circuit/channel congestion) As a balance between finding root cause and minimizing users disturbance, I would like to configure Asterisk (and its environment) so that I can : - gather data that could help to find root cause, - trigger an Asterisk convenient restart after a couple of such messages. What we can say Asterisk's output is stable enough but I can't make up my mind about the best way to implement the following rules : "as soon as Asterisk issues "cause 34 - Circuit/channel congestion" logs, switch to "Debug BRI mode" (ie turn on DEGUG PRI, increase verbosity, print channels values, ...)" "as soon as the third "cause 34 - Circuit/channel congestion" message is issued (within a 30mn time frame, for instance), restart Asterisk in Standard Mode" Being able to insert parsing functions between Asterisk code and pure logging functions and tie commands to such parsing functions would be perfect. Syslog-ng seems to bundle those parsing-logging functions (see http://web.suffieldacademy.org/ils/netadmin/docs/software/syslog/#toc4). It should be worth to try. Alternatives are : - perl scripts - nagios - splunk - munin Thanks for this input. I'll try to give a deeper look into each of those. Regards
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
