<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On 3 Nov 2017 19:59, "Doug Hellmann" <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Cédric Jeanneret's message of 2017-11-01 14:54:34 +0100:<br>
<div class="elided-text">> Dear Stackers,<br>
><br>
> While working on my locally deployed Openstack (Pike using TripleO), I<br>
> was a bit struggling with the logging part. Currently, all logs are<br>
> pushed to per-service files, in the standard format "one line per<br>
> entry", plain flat text.<br>
><br>
> It's nice, but if one is wanting to push and index those logs in an ELK,<br>
> the current, default format isn't really good.<br>
><br>
> After some discussions about oslo.log, it appears it provides a nice<br>
> JSONFormatter handler¹ one might want to use for each (python) service<br>
> using oslo central library.<br>
><br>
> A JSON format is really cool, as it's easy to parse for machines, and it<br>
> can be on a multi-line without any bit issue - this is especially<br>
> important for stack traces, as their output is multi-line without real<br>
> way to have a common delimiter so that we can re-format it and feed it<br>
> to any log parser (logstash, fluentd, …).<br>
><br>
> After some more talks, olso.log will not provide a unified interface in<br>
> order to output all received logs as JSON - this makes sens, as that<br>
> would mean "rewrite almost all the python logging management<br>
> interface"², and that's pretty useless, since (all?) services have their<br>
> own "logging.conf" file.<br>
><br>
> That said… to the main purpose of that mail:<br>
><br>
> - Default format for logs<br>
> A first question would be "are we all OK with the default output format"<br>
> - I'm pretty sure "humans" are happy with that, as it's really<br>
> convenient to read and grep. But on a "standard" Openstack deploy, I'm<br>
> pretty sure one does not have only one controller, one ceph node and one<br>
> compute. Hence comes the log centralization, and with that, the log<br>
> indexation and treatments.<br>
><br>
> For that, one might argue "I'm using plain files on my logger, and<br>
> grep-ing -r in them". That's a way to do things, and for that, plain,<br>
> flat logs are great.<br>
><br>
> But… I'm pretty sure I'm not the only one wanting to use some kind of<br>
> ELK cluster for that kind of purpose. So the right question is: what<br>
> about switching the default log format to JSON? On my part, I don't see<br>
> "cons", only "pros", but my judgment is of course biased, as I'm "alone<br>
> in my corner". But what about you, Community?<br>
><br>
> - Provide a way to configure the output format/handler<br>
> While poking around in the puppet modules code, I didn't find any way to<br>
> set the output handler for the logs. For example, in puppet-nova³ we can<br>
> set a lot of things, but not the useful handler for the output.<br>
><br>
> It would be really cool to get, for each puppet module, the capability<br>
> to set the handler so that one can just push some stuff in hiera, and<br>
> Voilà, we have JSON logs.<br>
><br>
> Doing so would allow people to chose between the default  (current)<br>
> output, and something more "computable".<br>
<br>
</div>Using the JSON formatter currently requires setting a logging<br>
configuration file using the standard library configuration format<br>
and fully specifying things like log levels, handlers, and output<br>
destination. Would it make sense to add an option in oslo.log to<br>
give deployers an easier way to enable the JSON formatter?<br></blockquote></div></div></div><div dir="auto">This would actually be very useful. </div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font color="#888888"><br>
Doug<br>
</font><div class="quoted-text"><br>
><br>
> Of course, either proposal will require a nice code change in all puppet<br>
> modules (add a new parameter for the foo::logging class, and use that<br>
> new param in the configuration file, and so on), but at least people<br>
> will be able to actually chose.<br>
><br>
> So, before opening an issue on each launchpad project (that would be…<br>
> long), I'd rather open the discussion in here and, eventually, come to<br>
> some nice, acceptable and accepted solution that would make the<br>
> Openstack Community happy :).<br>
><br>
> Any thoughts?<br>
><br>
> Thank you for your attention, feedback and wonderful support for that<br>
> monster project :).<br>
><br>
> Cheers,<br>
><br>
> C.<br>
><br>
><br>
> ¹<br>
> <a href="https://github.com/openstack/oslo.log/blob/master/oslo_log/formatters.py#L166-L235" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>oslo.log/blob/master/oslo_log/<wbr>formatters.py#L166-L235</a><br>
> ²<br>
> <a href="http://eavesdrop.openstack.org/irclogs/%23openstack-oslo/%23openstack-oslo.2017-11-01.log.html#t2017-11-01T13:23:14" rel="noreferrer" target="_blank">http://eavesdrop.openstack.<wbr>org/irclogs/%23openstack-oslo/<wbr>%23openstack-oslo.2017-11-01.<wbr>log.html#t2017-11-01T13:23:14</a><br>
> ³ <a href="https://github.com/openstack/puppet-nova/blob/master/manifests/logging.pp" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>puppet-nova/blob/master/<wbr>manifests/logging.pp</a><br>
><br>
<br>
</div><div class="elided-text">______________________________<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>
</div></blockquote></div><br></div></div></div>