<div dir="ltr"><div>Hello Alicja,<br><br></div>Comments inline.<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 12, 2016 at 1:19 PM, Kwasniewska, Alicja <span dir="ltr"><<a href="mailto:alicja.kwasniewska@intel.com" target="_blank">alicja.kwasniewska@intel.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 link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal">Unfortunately I do not have any experience in working or testing Heka, so it’s hard for me to compare its performance vs Logstash performance. However I’ve read that Heka possess a lot advantages over Logstash in this scope.
<br>
<span style="font-size:11pt"><br>
<br>
<u></u><u></u></span></p>
<p class="MsoNormal">But which version of Logstash did you test? One guy from the Logstash community said that:
<i>“The next release of logstash (1.2.0 is in beta) has a 3.5x improvement in event throughput. For numbers: on my workstation at home (6 vcpu on virtualbox, host OS windows, 8 GB ram, host cpu is FX-8150) - with logstash 1.1.13, I can process roughly 31,000
 events/sec parsing apache logs. With logstash 1.2.0.beta1, I can process 102,000 events/sec.”</i><br>
<br>
<br>
<u></u><u></u></p>
<p class="MsoNormal">You also said that Heka is a unified data processing, but do we need this? Heka seems to address stream processing needs, while Logstash focuses mainly on processing logs. We want to create a central logging service, and Logstash was created
 especially for it and seems to work well for this application.<br>
<br>
<br>
<u></u><u></u></p>
<p class="MsoNormal">One thing that is obvious is the fact that the Logstash is better known, more popular and tested. Maybe it has some performance disadvantages, but at least we know what we can expect from it. Also, it has more pre-built plugins and has
 a lot examples of usage, while Heka doesn’t have many of them yet and is nowhere near the range of plugins and integrations provided by Logstash.<br></p></div></div></blockquote><div><br></div><div>From my experience, Heka has already a large number of plugins that cover most of the use cases. But I understand your concerns regarding the adoption of Heka vs Logstash.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal">
<br>
<br>
<u></u><u></u></p>
<p class="MsoNormal">In the case of adding plugins, I’ve read that in order to add Go plugins, the binary has to be recompiled, what is a little bit frustrating (static linking - to wire in new plugins, have to recompile). On the other hand, the Lua plugins
 do not require it, but the question is whether Lua plugins are sufficient? Or maybe adding Go plugins is not so bad?
<br></p></div></div></blockquote><div><br></div><div>For the reason that you pointed, Lua plugins are first-class citizens and the Heka developers encourage their use over writing custom Go plugins. In terms of performances, Lua and Go plugins are usually equivalent.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal">
<br>
<br>
<u></u><u></u></p>
<p class="MsoNormal">You also said that you didn’t test the Heka with Docker, right? But do you have any experience in setting up Heka in Docker container? I saw that with Heka 0.8.0 new Docker features were implemented (included Dockerfiles to generate Heka
 Docker containers for both development and deployment), but did you test it? If you didn’t, we could not be sure whether there are any issues with it.
<br></p></div></div></blockquote><div><br></div><div>From my experience, Heka runs in Docker without problem.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal">
<br>
<br>
<u></u><u></u></p>
<p class="MsoNormal">Moreover you will have to write your own Dockerfile for Heka that inherits from Kolla base image (as we discussed during last meeting, we would like to have our own images), you won’t be able to inherit from ianneub/heka:0.10 as specified
 in the link that you sent <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>.<br></p></div></div></blockquote><div><br></div><div>Since the Heka binary embeds all its dependencies, writing the Dockerfile shouldn't be hard.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal">
<br>
<br>
<u></u><u></u></p>
<p class="MsoNormal">There are also some issues with DockerInput Module which you want to use. For example splitters are not available in DockerInput (<a href="https://github.com/mozilla-services/heka/issues/1643" target="_blank">https://github.com/mozilla-services/heka/issues/1643</a>). I can’t say that it will affect us, but we also don’t
 know which new issues may arise during first tests, as any of us has ever tried Heka in and with Dockers.<br></p></div></div></blockquote><div><br></div><div>Good point. This should be investigated by Eric in his specification.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal">
<br>
<br>
<u></u><u></u></p>
<p class="MsoNormal">I am not stick to any specific solution, however just not sure whether Heka won’t surprise us with something hard to solve, configure, etc.<u></u><u></u></p></div></div></blockquote><div><br></div><div>I just wanted to mention that Heka powers the Firefox Telemetry Data Pipeline [1] which collects and processes many data.<br><br></div><div>Simon<br><br>[1] <a href="https://people.mozilla.org/~rmiller/heka-monitorama-2015-06/#/41">https://people.mozilla.org/~rmiller/heka-monitorama-2015-06/#/41</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><i><span style="font-size:11pt;font-family:"Intel Clear Light",sans-serif;color:rgb(31,73,125)"><br>
Alicja Kwaśniewska</span></i><span style="font-size:11pt;font-family:"Intel Clear Light",sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11pt;font-family:"Calibri",sans-serif"> Sam Yaple [mailto:<a href="mailto:samuel@yaple.net" target="_blank">samuel@yaple.net</a>]
<br>
<b>Sent:</b> Monday, January 11, 2016 11:37 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [kolla] Introduction of Heka in Kolla<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Sam Yaple<u></u><u></u></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Mon, Jan 11, 2016 at 10:16 PM, Eric LEMOINE <<a href="mailto:elemoine@mirantis.com" target="_blank">elemoine@mirantis.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<p><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>
> > 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.<u></u><u></u></p>
<p>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.<u></u><u></u></p>
<p>> > 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.<u></u><u></u></p>
<p>I'm not following you. Could you please be more specific?<u></u><u></u></p>
<p>> >> 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?<u></u><u></u></p>
<p>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.<u></u><u></u></p>
<p>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.<u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:12pt"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>

<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></div></div></div>