<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 20, 2016 at 6:18 AM, Michael Kleinhenz <span dir="ltr"><<a href="mailto:kleinhenz@redhat.com" target="_blank">kleinhenz@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
----<br>
Mgmt abstract: there are pretty common combinations for log<br>
aggregations available. We need to decide if we need an intermediate<br>
"quick-but-ugly" central logging now or if we can wait until the<br>
system-provided logging solution is available. Consideration points:<br>
only a few containers now, time to availabilty of system-logging<br>
(TBD). We can build the intemediate solution so that migration later<br>
on should be easy.<br>
----<br>
<br>
I looked into some tech for aggregating logs for almighty today. This<br>
was a parking lot task due this week. To be clear: this is only to<br>
provide some insight about how we *could* achieve centralized logging,<br>
not to actually decide or build one of the possible solutions. The<br>
info is to give an overview of that stuff.<br>
<br>
Also, this currently only touches the logging for our own container<br>
instances, not the per-user logging of a "client-usage" of the<br>
pipeline. Although the solution, in the best case, should be able to<br>
handle both later.<br>
<br>
@KB: can you add details on the planned system-provided solution to<br>
the mix? Thanks!<br>
<br>
Aim is to have a single, centralized logging for all running<br>
containers. I used a combination of the following components before<br>
which turned out to be pretty neat:<br>
<br>
- Logsprout, <a href="https://github.com/gliderlabs/logspout" rel="noreferrer" target="_blank">https://github.com/gliderlabs/<wbr>logspout</a>, MIT License<br>
Connects to a docker daemon and collects logs from running containers<br>
to be sent elsewhere (like, a syslog or a rest endpoint). The ususual<br>
usecase is "a set of container instances run on one node, collect all<br>
stdout/stderr logs of all running containers and send them to a syslog<br>
or provide them on a single http endpoint". This one is not usable for<br>
us, because it involves exposing the host's docker daemon, implying<br>
that all containers are running on the same daemon. In our scenario,<br>
we would rather use a direct connection from the running instance to a<br>
central log sink (like Logstash, see below).<br>
<br>
- Logstash, <a href="https://github.com/elastic/logstash" rel="noreferrer" target="_blank">https://github.com/elastic/<wbr>logstash</a>, Apache License (also<br>
Elasticsearch)<br>
Collects, normalizes and stores (usually in Elasticsearch) any<br>
incoming info. Usually used for collection and storing logs (but<br>
defines itself more generic). Has lots of input and output plugins for<br>
accepting a wide range of event/log sources and writing them to lots<br>
of output sinks (Elasticsearch is only one of them). Looking at the<br>
possible protocols, Docker and Logstash support two matching protocols<br>
that could be used to send logs "directly" to Logstash: syslog and<br>
gelf.<br>
<br>
- Kibana, <a href="https://github.com/elastic/kibana" rel="noreferrer" target="_blank">https://github.com/elastic/<wbr>kibana</a>, Apache License<br>
Webfrontend for Elasticsearch that visualizes the data with pretty<br>
advanced stuff. Optional, but nice to provide diagrams. This one might<br>
be a candidate to look at when we are looking at the KPI stuff.<br>
<br>
For a very simple intermediate solution, we could put together a<br>
single container that includes most of the above components and acts<br>
as a "single sink" for logs. Ugly, but works. I did that one before<br>
(with logsprout as aggregator).<br>
<br>
Decision needed: we are currently working with a low number of<br>
containers. Are we even need a central logging at this stage? Or can<br>
we wait until the system-provided logging is available?</blockquote><div><br></div><div>Let's keep design a priority. :)  We want to be in the position where we can confidently replicate our patterns to new modules/containers as we introduce and integrate new features.  That said, we don't need to be perfect on the first swipe.</div><div><br></div><div>So anything we can do to make a single stable logging service extension SPI now, even if it's a stupid hack whose implementation we soon swap out, centralizes the issue for us and future work here wouldn't impact the various systems calling upon it.</div><div><br></div><div>S,</div><div>ALR</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Anyway, a possible custom solution should be compatible with a coming<br>
system logging. I would think that syslog may be the<br>
"supported-everywhere" variant.<br>
<br>
For the above "ugly" solution, I would have some stuff already<br>
available that we could use to build on. I would suppose setting this<br>
up should not take longer than 1-2 days (has to be converted from<br>
Ubuntu to Centos, may need some tweaking due to new releases of<br>
contained software etc).<br>
<br>
So, this for this mornings findings. :-)<br>
<br>
-- Michael<br>
<br>
--<br>
Michael Kleinhenz<br>
Principal Software Engineer<br>
<br>
Red Hat Deutschland GmbH<br>
Werner-von-Siemens-Ring 14<br>
85630 Grasbrunn<br>
Germany<br>
<br>
RED HAT | TRIED. TESTED. TRUSTED.<br>
Red Hat GmbH, <a href="http://www.de.redhat.com" rel="noreferrer" target="_blank">www.de.redhat.com</a>,<br>
Registered seat: Grasbrunn, Commercial register: Amtsgericht München,<br>
HRB 153243,<br>
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,<br>
Michael O'Neill<br>
<br>
______________________________<wbr>_________________<br>
almighty-public mailing list<br>
<a href="mailto:almighty-public@redhat.com">almighty-public@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/almighty-<wbr>public</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Red Hat Developer Programs Architecture<div>@ALRubinger</div></div></div>
</div></div>