<div dir="ltr"><div><div><div>CentOS/RHEL 6 are under production support until Nov 2020 [1] and journald is not available.  Even if journald could improve Asterisk logging, that's not an acceptable reason to force Asterisk users to upgrade from a supported OS.  If there was a module that allowed Asterisk logging to talk to journald I wouldn't care, but it should not replace the logging system or be required to run Asterisk.<br></div></div></div><div><div><div><br>[1] <a href="http://wiki.centos.org/FAQ/General#head-fe8a0be91ee3e7dea812e8694491e1dde5b75e6d" target="_blank">http://wiki.centos.org/FAQ/General#head-fe8a0be91ee3e7dea812e8694491e1dde5b75e6d</a><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 10, 2015 at 5:22 PM, Ludovic Gasc <span dir="ltr"><<a href="mailto:gmludo@gmail.com" target="_blank">gmludo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>2015-05-10 20:46 GMT+02:00 Bruce Ferrell <span dir="ltr"><<a href="mailto:bferrell@baywinds.org" target="_blank">bferrell@baywinds.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 05/09/2015 01:53 PM, Ludovic Gasc wrote:<br>
> 2015-05-09 16:15 GMT+02:00 Bruce Ferrell <<a href="mailto:bferrell@baywinds.org" target="_blank">bferrell@baywinds.org</a> <mailto:<a href="mailto:bferrell@baywinds.org" target="_blank">bferrell@baywinds.org</a>>>:<br>
<div><div>><br>
>     On 05/09/2015 01:17 AM, Ludovic Gasc wrote:<br>
>     > Hi,<br>
>     ><br>
>     > Systemd and Journald is now by default on Debian Jessie and Ubuntu 15.04, as on RHEL/CentOS.<br>
>     > Journald supports syslog format, nevertheless, at least for us, the structured log system provided with journald helps us to debug the production.<br>
>     ><br>
>     > The idea behind that is to attach metadata with a log line to facilitate the search with journalctl, you can write queries to find the errors.<br>
>     ><br>
>     > For example, with Apache: <a href="http://httpd.apache.org/docs/trunk/mod/mod_journald.html" target="_blank">http://httpd.apache.org/docs/trunk/mod/mod_journald.html</a><br>
>     ><br>
>     > For our Python daemons, for each log line, we store account_id, request_id, endpoint and method used to be easy to retrieve quickly interesting logs.<br>
>     ><br>
>     > Moreover, not yet used for us, but you can generate statistics about your source code real usage based<br>
>     > on: <a href="http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html#CODE_FILE=" target="_blank">http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html#CODE_FILE=</a><br>
>     ><br>
>     > For Asterisk, for example with dialplan logging, you should attach the context, the extension and the channel.<br>
>     ><br>
>     > You can simulate this journald feature with a specific format message for your logs, nevertheless, journalctl is more user-friendly to retrieve pertinent logs compare to the<br>
>     > classical grep usage.<br>
>     > ave no idea if i<br>
>     > I'm permitted to raise the question about an eventual journald support in Asterisk because I don't find anything about that in issues tracker nor mailing list.<br>
>     ><br>
>     > Moreover, I understand that even if you add the journald support, it's certainly necessary to change logging everywhere in Asterisk, however, I should help to do that.<br>
>     ><br>
>     > Regards<br>
>     > --<br>
>     > Ludovic Gasc (GMLudo)<br>
>     > <a href="http://www.gmludo.eu/" target="_blank">http://www.gmludo.eu/</a><br>
>     ><br>
>     ><br>
>     systemd and journald SUCK to high heaven.<br>
><br>
><br>
> I've no problems to believe you, nevertheless, could you be more precise ?<br>
> What are the facts that you arrive to this conclusion ?<br>
><br>
><br>
>       I have no idea if the issues I've had with them (OpenSUSE) are distro related or inherent.<br>
><br>
><br>
> It's issues on your production with several servers ? Or on your laptop ?<br>
> Could give us links with unresolved bugs you have ?<br>
> For now, to my experience, with 6 VMs on Debian Jessie on production with small clients and Asterisk 13, I've no issues with systemd nor journald.<br>
><br>
><br>
>     I have seen that the implementation of apache with a static systemd/journald module will no longer correctly serve content.<br>
><br>
><br>
> Could you give me a link about that ?<br>
</div></div>I would suggest you try it for yourself.  Procedure to reproduce:<br>
<br>
Perform fresh install of OpenSUSE 13.2<br>
assure apache/php/MySQL support are installed<br>
install wordpress from <a href="http://wordpress.org" target="_blank">wordpress.org</a><br>
Observe CSS is NOT correctly served.<br>
<br>
I did this several times to assure my findings.<br>
<br>
I rebuilt the opensuse rpms from the source rpms to omit systemd/journald from the apache build.  Correct operation was now observed<br></blockquote><div><br></div></div></div><div>Interesting, it seems like a regression bug.</div><div>The question now is the patchs from opensuse has broken this module, or the bug is in Apache itself.</div><div>The bug seems to be too obvious to be present in Apache source code, but who knows ?</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The response to the bug report was "Use Nginex"<br></blockquote><div><br></div></span><div>To be really honest with you, I've thought that when you explain your problem, I've dropped Apache on our production a long time ago for efficiency issues.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>     Please do NOT do this<br>
<span>><br>
<br>
> Why ? If it works for me, what's the problem for you ?<br>
<br>
</span>  Systemd integration has been insidious.  Should you wish to discuss further, please off this list.<br>
<span><br>
><br>
><br>
>       It also breaks fail2ban site security.<br>
><br>
><br>
> I don't understand the issue here, I see at least two solutions:<br>
> 1. You can continue to use rsyslog even if you have journald, BTW, it's the default setup of Debian Jessie, where journald forwards everything to rsyslog to avoid to perturb<br>
> sysadmins with log files.<br>
> 2. Apparently, fail2ban supports journald: <a href="https://github.com/fail2ban/fail2ban/pull/82" target="_blank">https://github.com/fail2ban/fail2ban/pull/82</a><br>
<br>
</span>1.) I don't know of any asterisk systems that use any form of system logging.  It can, and the fact that you keep bringing syslog logging into this indicates a lack of<br>
understanding of asterisk usage on your part.<br>
2.) Not released code and still under test.  This is disingenuous, at best.<br>
3.) Just because everyone else is jumping off of bridges isn't a good enough reason to do it.  It's NOT broken and this is NOT an improvement.<br></blockquote><div><br></div></span><div>Concretely, we have an infrastructure that for now handles more than 3 millions of SIP calls by month with a dedicated telco team for that, and we're continuing to grow.</div><div><br></div><div>For now, even with voipmonitor and homer, it's a nightmare for our telco team to debug that.</div><div>One part of the problem is because we have an heterogeneous architecture with kamailio, freeswitch and asterisk, but also, as most telco solutions in the cloud, we're trying to stack the most clients as possible with the less VMs: It means that each node is in tenant mode => no nodes are dedicated for one client.</div><div><br></div><div>To improve this situation, I'm looking for a solution to invert the classical UNIX model: to split logs not by daemon, but by client => instead of a telco guy becomes crazy to parse with grep each daemon log and track one call with different ids, telco guys want to track easily all history to understand why the system has taken this decision to do that. One of a concrete example is Asterisk and FastAGI daemons interactions.</div><div><br></div><div>journald itself isn't clearly a silver bullet to handle all problematic, nevertheless, the first step is to have a better categorization of logs for after build a tool behind that.</div><div>In the past, we've tried a little bit ELK but it was very complicated, heavy process for a few ROI from our experience.</div><div><br></div><div>We'd already made a small tool to parse Asterisk logs and categorize them, but under high load, we had efficiency issues: it didn't parse enough fastly to be useable for a direct live debugging.</div><div><br></div><div>It's why I've made a little labo with some clients to validate my ideas before a bigger production, because I don't trust the mainstream nor hipster architectures promoted in IT world.</div><div>I "believe" only in concrete values I can measure on concrete use cases useful for my users: clients or telco guys.</div><div><br></div><div>Ok, while Asterisk doesn't support structured logs, the workaround is to implement a more efficient parser for Asterisk logs to categorize that.</div><div><br></div><div>Thanks for your attention.</div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div><br>
><br>
><br>
>     Asterisk works well now.  It integrates easily.<br>
><br>
><br>
> For this point, I'm agree with you, it's very important to continue to be integrated easily, I use that a lot.<br>
><br>
><br>
><br>
><br>
><br>
>     --<br>
>     _____________________________________________________________________<br>
>     -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
><br>
>     asterisk-dev mailing list<br>
>     To UNSUBSCRIBE or update options visit:<br>
>        <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
><br>
><br>
><br>
><br>
<br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</div></div></blockquote></span></div><br></div></div>
<br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br></div></div></div></div></div>