<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Just FYI. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Docker support multi log driver now[0].</div><div class="gmail_default" style=""><div class="gmail_default" style=""><font face="monospace, monospace"><br></font></div><div class="gmail_default" style=""><font face="monospace, monospace"><span class="">Version </span>New Logging Drivers</font></div><div class="gmail_default" style=""><font face="monospace, monospace">1.6.0<span class="" style="white-space:pre">   </span>json-file, syslog, none</font></div><div class="gmail_default" style=""><font face="monospace, monospace">1.7.0<span class="" style="white-space:pre">     </span>journald</font></div><div class="gmail_default" style=""><font face="monospace, monospace">1.8.0<span class="" style="white-space:pre">    </span>fluentd, gelf</font></div><div class="gmail_default" style=""><font face="monospace, monospace">1.9.0<span class="" style="white-space:pre">       </span>awslogs</font></div></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">For the stdout from container, we can use gelf/syslog driver to forward.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">[0] <a href="https://docs.docker.com/engine/reference/logging/overview/">https://docs.docker.com/engine/reference/logging/overview/</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 15, 2016 at 8:28 AM, Steven Dake (stdake) <span dir="ltr"><<a href="mailto:stdake@cisco.com" target="_blank">stdake@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Eric,<br>
<br>
Comments inline.<br>
<span class=""><br>
On 1/14/16, 3:31 AM, "Eric LEMOINE" <<a href="mailto:elemoine@mirantis.com">elemoine@mirantis.com</a>> wrote:<br>
<br>
>On Wed, Jan 13, 2016 at 1:27 PM, Steven Dake (stdake) <<a href="mailto:stdake@cisco.com">stdake@cisco.com</a>><br>
>wrote:<br>
>> Eric,<br>
><br>
><br>
>Hi Steven<br>
<br>
<br>
</span>Feel free to call me Steve<br>
<span class=""><br>
><br>
><br>
>><br>
>> Apologies for top post, not really sure where in this thread to post<br>
>>this<br>
>> list of questions as its sort of a change in topic so I changed the<br>
>> subject line :)<br>
>><br>
>> 1.<br>
>> Somewhere I read when researching this Heka topic, that Heka cannot log<br>
>> all details from /dev/log.  Some services like mariadb for example don't<br>
>> log to stdout as I think Heka requires to operate correctly.  Would you<br>
>> mind responding on the question "Would Heka be able to effectively log<br>
>> every piece of information coming off the system related to OpenStack<br>
>>(our<br>
>> infrastructure services like ceph/mariadb/etc as well as the OpenStack<br>
>> services)?<br>
><br>
><br>
>My first reaction to this is: if we have services, such as mariadb,<br>
>that can only send their logs to syslog then let's continue using<br>
>Rsyslog.  And with Rsyslog we can easily store logs on the local<br>
>filesystem as well (your requirement #3 below).<br>
<br>
</span>Rsyslog may be the best tool for this job.  I'll be looking to your POC to<br>
get a feel for the validity of that claim :)<br>
<span class=""><br>
><br>
>That being said, it appears that Heka supports reading logs from<br>
>/dev/log.  This can be done using the UdpInput plugin with "net" set<br>
>to "unixgram".  See<br>
><<a href="https://github.com/mozilla-services/heka/issues/790" rel="noreferrer" target="_blank">https://github.com/mozilla-services/heka/issues/790</a>> for the original<br>
>issue.  Heka also supports writing logs to files on the local<br>
>filesystem, through the FileOutput plugin.  We do not currently use<br>
>the UdpInput plugin, so we need to test it and see if it can work for<br>
>Kolla.  We will work on these tests, and report back to the list.<br>
><br>
><br>
><br>
>> 2.<br>
>> Also, I want to make sure we can fix up the backtrace defeciency.<br>
>> Currently rsyslog doesn't log backtraces in python code.  Perhaps Sam or<br>
>> inc0 know the reason behind it, but I want to make sure we can fix up<br>
>>this<br>
>> annoyance, because backtraces are mightily important.<br>
><br>
><br>
>I've had a look on my AIO Kolla.  And I do see Python tracebacks in<br>
>OpenStack log files created by Rsyslog (in<br>
>/var/lib/docker/volumes/rsyslog/_data/nova/nova-api.log for example).<br>
>They're just on a single line, with "#012" used as the separator [*].<br>
>So they are hard to read, but they are there.  I think that is<br>
>consistent with what SamYaple and inc0 said yesterday on IRC.<br>
><br>
>[*] This is related to Rsyslog's $EscapeControlCharactersOnReceive<br>
>setting. See<br>
><<a href="http://www.rsyslog.com/doc/master/configuration/input_directives/rsconf1_" rel="noreferrer" target="_blank">http://www.rsyslog.com/doc/master/configuration/input_directives/rsconf1_</a><br>
>escapecontrolcharactersonreceive.html>.<br>
><br>
<br>
</span>Apparently the one-lining of the tracebacks is a new feature because of a<br>
bug fix in oslo.log that dims fixed for us.  So my original comments about<br>
missing backtraces was dated information from December.<br>
<div><div class="h5"><br>
><br>
>> 3.<br>
>> Also I want to make sure each node ends up with log files in a data<br>
>> container (or data volume or whatever we just recently replaced the data<br>
>> containers with) for all the services for individual node diagnostics.<br>
>> This helps fill the gap of the Kibana visualization and Elasticsearch<br>
>> where we may not have a perfect diagnostic solution at the conclusion of<br>
>> Mitaka and in need of individual node inspection of the logs.  Can Heka<br>
>>be<br>
>> made to do this?  Our rsyslog implementation does today, and its a hard<br>
>> requirement for the moment.  If we need some special software to run in<br>
>> addition to Heka, I could live with that.<br>
><br>
><br>
>That "special software" could be Rsyslog :)  Seriously, Rsyslog<br>
>provides a solution for getting logs from services that only log to<br>
>syslog.  We can also easily configure Rsyslog to write logs on the<br>
>local filesystem, as done in Kolla already today.  And using Heka we<br>
>can easily make Python tracebacks look good in Kibana.<br>
><br>
>I would like to point out that our initial intent was not to remove<br>
>Rsyslog.  Our intent was to propose a scalable/decentralized log<br>
>processing architecture based on Heka running on each node, instead of<br>
>relying on a centralized Logstash instance.  Using Heka we eliminate<br>
>the need to deploy and manage a resilient Logstash/Redis cluster.  And<br>
>it is to be noted that Heka gives us a lot of flexibility.  In<br>
>particular, Heka makes it possible to collect logs from services that<br>
>don't speak syslog (RabbitMQ for example, whose logs are not currently<br>
>collected!).<br>
<br>
<br>
</div></div>FWIW the concern that logstash isn't scalable is unsubstantiated.  IMNSHO<br>
the reason to use Heka is it does two things we need with one component<br>
while removing JVMs from each compute node.  This is my main attraction to<br>
the adoption of Heka.<br>
<span class=""><br>
><br>
>As mentioned above Heka provides plugins that we could possibly<br>
>leverage to remove Rsyslog completely, but at this point we cannot<br>
>guarantee that they will do the job.  Our coming tests will tell.<br>
<br>
</span>If the plugins work in a way in which we can remove rsyslog completely, I<br>
would prefer that outcome.  Less dependencies in software systems are<br>
better.<br>
<br>
Regards<br>
-steve<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
>Thanks.<br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><span style="font-size:13px;border-collapse:collapse"><font face="monospace, monospace">Jeffrey Zhang</font></span></div><div><font face="monospace, monospace">Blog: <a href="http://xcodest.me" target="_blank">http://xcodest.me</a></font></div><div><font face="monospace, monospace">twitter/weibo: @jeffrey4l</font></div></div></div></div></div></div></div>
</div>