<div dir="ltr">Our current model for logging in a containerized deployment has pretty much everything logging to files in a directory that has been bind-mounted from the host.  This has some advantages: primarily, it makes it easy for an operator on the local system to find logs, particularly if they have had some previous exposure to non-containerized deployments.<br clear="all"><div><br></div><div>There is strong demand for a centralized logging solution.  We've got one potential solution right now in the form of the fluentd service introduced in Newton, but this requires explicit registration of log files for every service.  I don't think it's an ideal solution, and I would like to explore some alternatives.</div><div><br></div><div>Logging via syslog</div><div>==============</div><div><br></div><div>For the purposes of the following, I'm going to assume that we're deploying on an EL-variant (RHEL/CentOS/etc), which means (a) journald owns /dev/log and (b) we're running rsyslog on the host and using the omjournal plugin to read messages from journald.</div><div><br></div><div>If we bind mount /dev/log into containers and configure openstack services to log via syslog rather than via files, we get the following for free:</div><div><br></div><div>- We get message-based rather than line-based logging.  This means that multiline tracebacks are handled correctly.</div><div><br></div><div>- A single point of collection for logs.  If your host has been configured to ship logs to a centralized collector, logs from all of your services will be sent there without any additional configuration.</div><div><br></div><div>- We get per-service message rate limiting from journald.</div><div><br></div><div>- Log messages are annotated by journald with a variety of useful metadata, including the container id and a high resolution timestamp.</div><div><br></div><div>- We can configure the syslog service on the host to continue to write files into legacy locations, so an operator looking to run grep against local log files will still have that ability.</div><div><br></div><div>- Ryslog itself can send structured messages directly to an Elastic instance, which means that in a many deployments we would not require fluentd and its dependencies.</div><div><br></div><div>- This plays well in environments where some services are running in containers and others are running on the host, because everything simply logs to /dev/log.</div><div><br></div><div>Logging via stdin/stdout</div><div>==================</div><div><br></div><div>A common pattern in the container world is to log everything to stdout/stderr.  This has some of the advantages of the above:</div><div><br></div><div>- We can configure the container orchestration service to send logs to the journal or to another collector.</div><div><br></div><div>- We get a different set of annotations on log messages.</div><div><br></div><div>- This solution may play better with frameworks like Kubernetes that tend to isolate containers from the host a little more than using Docker or similar tools straight out of the box.</div><div><br></div><div>But there are some disadvantages:</div><div><br></div><div>- Some services only know how to log via syslog (e.g., swift and haproxy)</div><div><br></div><div>- We're back to line-based vs. message-based logging.</div><div><br></div><div>- It ends up being more difficult to expose logs at legacy locations.</div><div><br></div><div>- The container orchestration layer may not implement the same message rate limiting we get with fluentd.</div><div><br></div><div>Based on the above, I would like to suggest exploring a syslog-based logging model moving forward. What do people think about this idea? I've started putting together a spec at <a href="https://review.openstack.org/#/c/484922/">https://review.openstack.org/#/c/484922/</a> and I would welcome your input.</div><div><br></div><div>Cheers,</div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Lars Kellogg-Stedman <<a href="mailto:lars@redhat.com" target="_blank">lars@redhat.com</a>><div><br></div></div></div>
</div>