<div dir="ltr">Hi,<div><br></div><div>Kolla-ansible went through this process a few years ago, and ended up with a solution involving heka pulling logs from files in a shared docker volume (kolla_logs). Heka was recently switched for fluentd due to the disappearance of upstream support. I suspect kolla-kubernetes has been through a similar process recently.<div><br></div><div>I'd recommend soliciting input from the kolla team on the factors that lead to the current design, and whether with hindsight anything would be done differently.</div><div><br></div><div>Cheers,</div><div>Marl</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 19 July 2017 at 09:26, Bogdan Dobrelya <span dir="ltr"><<a href="mailto:bdobreli@redhat.com" target="_blank">bdobreli@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 18.07.2017 21:27, Lars Kellogg-Stedman wrote:<br>
> Our current model for logging in a containerized deployment has pretty<br>
> much everything logging to files in a directory that has been<br>
> bind-mounted from the host.  This has some advantages: primarily, it<br>
> makes it easy for an operator on the local system to find logs,<br>
> particularly if they have had some previous exposure to<br>
> non-containerized deployments.<br>
><br>
> There is strong demand for a centralized logging solution.  We've got<br>
> one potential solution right now in the form of the fluentd service<br>
> introduced in Newton, but this requires explicit registration of log<br>
> files for every service.  I don't think it's an ideal solution, and I<br>
> would like to explore some alternatives.<br>
><br>
> Logging via syslog<br>
> ==============<br>
><br>
> For the purposes of the following, I'm going to assume that we're<br>
> deploying on an EL-variant (RHEL/CentOS/etc), which means (a) journald<br>
> owns /dev/log and (b) we're running rsyslog on the host and using the<br>
> omjournal plugin to read messages from journald.<br>
><br>
> If we bind mount /dev/log into containers and configure openstack<br>
> services to log via syslog rather than via files, we get the following<br>
> for free:<br>
><br>
> - We get message-based rather than line-based logging.  This means that<br>
> multiline tracebacks are handled correctly.<br>
><br>
> - A single point of collection for logs.  If your host has been<br>
> configured to ship logs to a centralized collector, logs from all of<br>
> your services will be sent there without any additional configuration.<br>
><br>
> - We get per-service message rate limiting from journald.<br>
><br>
> - Log messages are annotated by journald with a variety of useful<br>
> metadata, including the container id and a high resolution timestamp.<br>
><br>
> - We can configure the syslog service on the host to continue to write<br>
> files into legacy locations, so an operator looking to run grep against<br>
> local log files will still have that ability.<br>
><br>
> - Ryslog itself can send structured messages directly to an Elastic<br>
> instance, which means that in a many deployments we would not require<br>
> fluentd and its dependencies.<br>
><br>
> - This plays well in environments where some services are running in<br>
> containers and others are running on the host, because everything simply<br>
> logs to /dev/log.<br>
<br>
</div></div>Plus it solves the log rotation (still have to be addressed [0] for Pike<br>
though), out-of-box.<br>
<span class=""><br>
><br>
> Logging via stdin/stdout<br>
> ==================<br>
><br>
> A common pattern in the container world is to log everything to<br>
> stdout/stderr.  This has some of the advantages of the above:<br>
><br>
> - We can configure the container orchestration service to send logs to<br>
> the journal or to another collector.<br>
><br>
> - We get a different set of annotations on log messages.<br>
><br>
> - This solution may play better with frameworks like Kubernetes that<br>
> tend to isolate containers from the host a little more than using Docker<br>
> or similar tools straight out of the box.<br>
><br>
> But there are some disadvantages:<br>
><br>
> - Some services only know how to log via syslog (e.g., swift and haproxy)<br>
><br>
> - We're back to line-based vs. message-based logging.<br>
><br>
> - It ends up being more difficult to expose logs at legacy locations.<br>
><br>
> - The container orchestration layer may not implement the same message<br>
> rate limiting we get with fluentd.<br>
><br>
> Based on the above, I would like to suggest exploring a syslog-based<br>
> logging model moving forward. What do people think about this idea? I've<br>
> started putting together a spec<br>
> at <a href="https://review.openstack.org/#/c/484922/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/484922/</a> and I would welcome your input.<br>
<br>
</span>My vote goes for this option, but TBD for Queens. It won't make it for<br>
Pike, as it looks too late for such amount of drastic changes, like<br>
switching all OpenStack services to syslog, deploying additional<br>
required components, and so on.<br>
<br>
[0] <a href="https://bugs.launchpad.net/tripleo/+bug/1700912" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>tripleo/+bug/1700912</a><br>
[1] <a href="https://review.openstack.org/#/c/462900/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/462900/</a><br>
<br>
><br>
> Cheers,<br>
<span class="HOEnZb"><font color="#888888">><br>
> --<br>
> Lars Kellogg-Stedman <<a href="mailto:lars@redhat.com">lars@redhat.com</a> <mailto:<a href="mailto:lars@redhat.com">lars@redhat.com</a>>><br>
><br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
<br>
<br>
--<br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<br>
<br>
______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</font></span></blockquote></div><br></div>