<div dir="ltr">Here is why I am on board with this. As we have discovered, the logging with the syslog plugin leaves alot to be desired. It (to my understanding) still can't save tracebacks/stacktraces to the log files for whatever reason. stdout/stderr however works perfectly fine. That said the Docker log stuff has been a source of pain in the past, but it has gotten better. It does have the limitation of being only able to log one output at a time. This means, as an example, the neutron-dhcp-agent could send its logs to stdout/err but the dnsmasq process that it launch (that also has logs) would have to mix its logs in with the neutron logs in stdout/err. Can Heka handle this and separate them efficiently? Otherwise I see no choice but to stick with something that can handle multiple logs from a single container.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>Sam Yaple</div></div></div></div>
<br><div class="gmail_quote">On Mon, Jan 11, 2016 at 10:16 PM, Eric LEMOINE <span dir="ltr"><<a href="mailto:elemoine@mirantis.com" target="_blank">elemoine@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"><span class=""><br>
Le 11 janv. 2016 18:45, "Michał Jastrzębski" <<a href="mailto:inc007@gmail.com" target="_blank">inc007@gmail.com</a>> a écrit :<br>
><br>
> On 11 January 2016 at 10:55, Eric LEMOINE <<a href="mailto:elemoine@mirantis.com" target="_blank">elemoine@mirantis.com</a>> wrote:<br></span><span class="">
> > Currently the services running in containers send their logs to<br>
> > rsyslog. And rsyslog stores the logs in local files, located in the<br>
> > host's /var/log directory.<br>
><br>
> Yeah, however plan was to teach rsyslog to forward logs to central<br>
> logging stack once this thing is implemented.<br></span></p>
<p dir="ltr">Yes. With the current ELK Change Request, Rsyslog sends logs to the central Logstash instance. If you read my design doc you'll understand that it's precisely what we're proposing changing.<br></p><span class="">
<p dir="ltr">> > I know. Our plan is to rely on Docker. Basically: containers write<br>
> > their logs to stdout. The logs are collected by Docker Engine, which<br>
> > makes them available through the unix:///var/run/docker.sock socket.<br>
> > The socket is mounted into the Heka container, which uses the Docker<br>
> > Log Input plugin [*] to reads the logs from that that socket.<br>
> ><br>
> > [*] <<a href="http://hekad.readthedocs.org/en/latest/config/inputs/docker_log.html" target="_blank">http://hekad.readthedocs.org/en/latest/config/inputs/docker_log.html</a>><br>
><br>
> So docker logs isn't best thing there is, however I'd suspect that's<br>
> mostly console output fault. If you can tap into stdout efficiently,<br>
> I'd say that's pretty good option.<br></p>
</span><p dir="ltr">I'm not following you. Could you please be more specific?<br></p><span class="">
<p dir="ltr">> >> Seems to me we need additional comparason of heka vs rsyslog;) Also<br>
> >> this would have to be hands down better because rsyslog is already<br>
> >> implemented, working and most of operators knows how to use it.<br>
> ><br>
> ><br>
> > We don't need to remove Rsyslog. Services running in containers can<br>
> > write their logs to both Rsyslog and stdout, which even is what they<br>
> > do today (at least for the OpenStack services).<br>
> ><br>
><br>
> There is no point for that imho. I don't want to have several systems<br>
> doing the same thing. Let's make decision of one, but optimal toolset.<br>
> Could you please describe bottoms up what would your logging stack<br>
> look like? Heka listening on stdout, transfering stuff to<br>
> elasticsearch and kibana on top of it?<br></p>
</span><p dir="ltr">My plan is to provide details in the blueprint document, that I'll continue working on if the core developers agree with the principles of the proposed architecture and change.<br></p>
<p dir="ltr">But here's our plan—as already described in my previous email: the Kolla services, which run in containers, write their logs to stdout. Logs are collected by the Docker engine. Heka's Docker Log Input plugin is used to read the container logs from the Docker endpoint (Unix socket). Since Heka will run in a container a volume is necessary for accessing the Docker endpoint. The Docker Log Input plugin inserts the logs into the Heka pipeline, at the end of which an Elasticsearch Output plugin will send the log messages to Elasticsearch. Here's a blog post reporting on that approach: <<a href="http://www.ianneubert.com/wp/2015/03/03/how-to-use-heka-docker-and-tutum/" target="_blank">http://www.ianneubert.com/wp/2015/03/03/how-to-use-heka-docker-and-tutum/</a>>. We haven't tested that approach yet, but we plan to experiment with it as we work on the specs.</p>
<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></blockquote></div><br></div>