<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 6, 2017 at 8:04 AM, Cédric Jeanneret <span dir="ltr"><<a href="mailto:cedric.jeanneret@camptocamp.com" target="_blank">cedric.jeanneret@camptocamp.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 class="gmail-HOEnZb"><div class="gmail-h5">On 11/04/2017 07:08 AM, Doug Hellmann wrote:<br>
> Excerpts from Juan Antonio Osorio's message of 2017-11-04 00:11:47 +0200:<br>
>>> On 3 Nov 2017 19:59, "Doug Hellmann" <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br>
>>><br>
>>> Excerpts from Cédric Jeanneret's message of 2017-11-01 14:54:34 +0100:<br>
>>>> 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>
>>> 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>
>>><br>
>><br>
>> This would actually be very useful.<br>
><br>
> Great! Let me know if you would like to help figuring out where to do<br>
> that in the library code.<br>
<br>
</div></div>There's already some (not really documented) feature allowing oslo.log<br>
to load a configuration file. In fact, there's already one existing in<br>
the keystone tree (/etc/keystone/logging.conf - altougn not loaded) - we<br>
might base something "casual" and "generic" on that one.<br>
<br>
I think all wsgi/python services should configure the logging through<br>
that file so that it's clearer and cleaner. But that part is maybe a bit<br>
too big and "aggressive" :). And the logging configuration isn't that<br>
friendly, to be honest, at least I have some issues with its doc ;).<br>
<br>
But I think we might come to something nice and cool. It would allow<br>
anyone to push  their own log "formatter", in the end.<br>
So you (oslo.log) wouldn't need to work with format output requests<br>
anymore, just provide two basics (plain and json), and let users play<br>
with the logging configuration (and even output things in XML if they<br>
want) ;).<br>
<br>
Regarding oslo.log: apparently, adding the following entry in the<br>
service configuration file should do it:<br>
log-config-append¹<br>
<br>
Can anyone confirm that?<br></blockquote><div><br></div><div>It seems to be the case at least from the docs in the option [1]. But if we use this file (in TripleO and puppet) we really need to make it backwards compatible. Would folks be OK with taking it into use? I guess what it would take would be to document better the usage of this advanced configuration. Taking it into use doesn't look that bad; If you look at the file where the options are being set (_options.py), you will see that there are several options that get ignored once we start using this file [2]. To see all the options that get ignored you can look at the instances of _IGNORE_MESSAGE. So, if we would start taking that into use, we would need to change the parameters of the oslo::log resource in puppet [3] to also configure an equivalent option to that advanced logging file.<br></div><div><br></div><div>[1] <a href="https://github.com/openstack/oslo.log/blob/master/oslo_log/_options.py#L44">https://github.com/openstack/oslo.log/blob/master/oslo_log/_options.py#L44</a></div><div>[2] <a href="https://github.com/openstack/oslo.log/blob/master/oslo_log/_options.py#L32">https://github.com/openstack/oslo.log/blob/master/oslo_log/_options.py#L32</a></div><div>[3] <a href="https://github.com/openstack/puppet-oslo/blob/master/manifests/log.pp">https://github.com/openstack/puppet-oslo/blob/master/manifests/log.pp</a><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
¹ <a href="https://github.com/openstack/oslo.log/blob/master/oslo_log/_options.py#L44" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>oslo.log/blob/master/oslo_log/<wbr>_options.py#L44</a><br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
><br>
> Doug<br>
><br>
> ______________________________<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>
><br>
<br>
<br>
</div></div><br>______________________________<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>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><font style="font-family:arial narrow,sans-serif;color:rgb(102,102,102)" size="2">Juan Antonio Osorio R.<br>e-mail: <a href="mailto:jaosorior@gmail.com" target="_blank">jaosorior@gmail.com</a><br></font><font style="font-family:arial narrow,sans-serif;color:rgb(102,102,102)" size="2"><br></font></div></div></div>
</div></div>