No subject


Thu Jul 12 09:23:04 CDT 2007


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

------=_Part_54927_31974881.1216284977096
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr"><br><div class="gmail_quote">2008/7/16 Tilghman Lesher &lt;<a href="mailto:tilghman at mail.jeffandtilghman.com">tilghman at mail.jeffandtilghman.com</a>&gt;:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">
&gt; If they TRULY &nbsp;see themselves as a TELCO replacements for large shop<br>
&gt; they REALLY need to step up to<br>
&gt; proving INFO, WARN, ERROR messaging in a unified reliable manner. Such<br>
&gt; as a SNMP messaging ability for all<br>
&gt; INFO, ERROR, and WARN level messages.<br>
<br>
</div><br>That&#39;s an interesting idea, and perhaps someone might pick up on the idea and<br>
run with it. &nbsp;Perhaps you might and donate your efforts back to the project.<br></blockquote><div><br>From memory, I think I&#39;ve read here (or developers list) a note (was it from Olle ?)&nbsp;  aiming to unify logging, eventing, monitoring (AMI, SNMP, ...) APIs.<br>
I think that thread occurred when it was decided to include a version number in Manager interface.<br>I agree this is an interesting idea ...<br><br><br>The use case that made me ask this is here :<br><br>I&#39;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.<br>
Each time it can&#39;t dialout, I&#39;ve got such messages (though, obviously the system has unused ISDN channels and should be able to dial out) :<br><br>[Jul 11 10:01:47] WARNING[19997] app_dial.c: Unable to create channel of type &#39;Zap&#39; (cause 34 - Circuit/channel congestion)<br>
<br><br><br>As a balance between finding root cause and minimizing users disturbance, I would like to configure Asterisk (and its environment) so that I can&nbsp; :<br>- gather data that could help to find root cause,<br>- trigger an Asterisk convenient restart after a couple of such messages.<br>
<br>What we can say Asterisk&#39;s output is stable enough but I can&#39;t make up my mind about the best way to implement the following rules :<br><br>&quot;as soon as Asterisk issues &quot;cause 34 - Circuit/channel congestion&quot; logs, switch to &quot;Debug BRI mode&quot; (ie turn on DEGUG PRI, increase verbosity, print channels values, ...)&quot;<br>
&quot;as soon as the third &quot;cause 34 - Circuit/channel congestion&quot; message is issued (within a 30mn time frame, for instance), restart Asterisk in Standard Mode&quot;<br><br><br>Being able to insert parsing functions between Asterisk code and pure logging functions and tie commands to such parsing functions would be perfect.<br>
Syslog-ng seems to bundle those parsing-logging functions (see <a href="http://web.suffieldacademy.org/ils/netadmin/docs/software/syslog/#toc4">http://web.suffieldacademy.org/ils/netadmin/docs/software/syslog/#toc4</a>). It should be worth to try.<br>
 </div></div><br><br>Alternatives are :<br>- perl scripts<br>- nagios<br>- splunk<br>- munin<br><br>Thanks for this input. I&#39;ll try to give a deeper look into each of those.<br><br>Regards<br></div>

------=_Part_54927_31974881.1216284977096--



More information about the asterisk-users mailing list