<div dir="ltr">Proposed a patch to be able to enable the JSON formatter via an oslo.log configuration parameter:<br><br><a href="https://review.openstack.org/#/c/517882/">https://review.openstack.org/#/c/517882/</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 6, 2017 at 9:43 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11/06/2017 08:36 AM, Juan Antonio Osorio wrote:<br>
> Giving this a bit more thought; I'm slightly more inclined on merely adding<br>
> the JSON formatter option to the standard oslo.log configuration options.<br>
<br>
</span>Fine for me.<br>
<span class=""><br>
><br>
> This is because we right now have the ability to pass oslo.cfg options via<br>
> the CLI, and we would loose that with the advanced logging configuration<br>
> file. The aforementioned option is something that we're using for<br>
> containerized openstack services.<br>
<br>
</span>OK - I'll check on my own if I can get something nice with the<br>
logging.conf file. But that won't be for "tomorrow", as I'm not<br>
full-time on openstack (unfortunately :(). Both solutions have their<br>
pros and cons in the end.<br>
<span class=""><br>
><br>
> I'll look into adding the ability to turn that handler on/off from oslo.log.<br>
<br>
</span>Ping me if I can help :). And big thanks for that coming change!<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
><br>
> On Mon, Nov 6, 2017 at 8:34 AM, Juan Antonio Osorio <<a href="mailto:jaosorior@gmail.com">jaosorior@gmail.com</a>><br>
> wrote:<br>
><br>
>><br>
>><br>
>> On Mon, Nov 6, 2017 at 8:04 AM, Cédric Jeanneret <<br>
>> <a href="mailto:cedric.jeanneret@camptocamp.com">cedric.jeanneret@camptocamp.<wbr>com</a>> wrote:<br>
>><br>
>>> 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<br>
>>> +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),<br>
>>> 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<br>
>>> 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)<br>
>>> service<br>
>>>>>>> using oslo central library.<br>
>>>>>>><br>
>>>>>>> A JSON format is really cool, as it's easy to parse for machines,<br>
>>> 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<br>
>>> real<br>
>>>>>>> way to have a common delimiter so that we can re-format it and feed<br>
>>> it<br>
>>>>>>> to any log parser (logstash, fluentd, …).<br>
>>>>>>><br>
>>>>>>> After some more talks, olso.log will not provide a unified interface<br>
>>> 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<br>
>>> 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<br>
>>> 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,<br>
>>> I'm<br>
>>>>>>> pretty sure one does not have only one controller, one ceph node and<br>
>>> 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<br>
>>> see<br>
>>>>>>> "cons", only "pros", but my judgment is of course biased, as I'm<br>
>>> "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<br>
>>> way to<br>
>>>>>>> set the output handler for the logs. For example, in puppet-nova³ we<br>
>>> 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<br>
>>> 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>
>>> 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>
>>><br>
>><br>
>> It seems to be the case at least from the docs in the option [1]. But if<br>
>> we use this file (in TripleO and puppet) we really need to make it<br>
>> backwards compatible. Would folks be OK with taking it into use? I guess<br>
>> what it would take would be to document better the usage of this advanced<br>
>> configuration. Taking it into use doesn't look that bad; If you look at the<br>
>> file where the options are being set (_options.py), you will see that there<br>
>> are several options that get ignored once we start using this file [2]. To<br>
>> see all the options that get ignored you can look at the instances of<br>
>> _IGNORE_MESSAGE. So, if we would start taking that into use, we would need<br>
>> to change the parameters of the oslo::log resource in puppet [3] to also<br>
>> configure an equivalent option to that advanced logging file.<br>
>><br>
>> [1] <a href="https://github.com/openstack/oslo.log/blob/master/oslo_log/_" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>oslo.log/blob/master/oslo_log/<wbr>_</a><br>
>> options.py#L44<br>
>> [2] <a href="https://github.com/openstack/oslo.log/blob/master/oslo_log/_" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>oslo.log/blob/master/oslo_log/<wbr>_</a><br>
>> options.py#L32<br>
>> [3] <a href="https://github.com/openstack/puppet-oslo/blob/master/manifests/log.pp" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>puppet-oslo/blob/master/<wbr>manifests/log.pp</a><br>
>><br>
>>><br>
>>><br>
>>> ¹ <a href="https://github.com/openstack/oslo.log/blob/master/oslo_log/_" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>oslo.log/blob/master/oslo_log/<wbr>_</a><br>
>>> options.py#L44<br>
>>><br>
>>>><br>
>>>> Doug<br>
>>>><br>
>>>> ______________________________<wbr>______________________________<br>
>>> ______________<br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> Unsubscribe: OpenStack-dev-request@lists.op<br>
>>> <a href="http://enstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">enstack.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>
>>><br>
>>> ______________________________<wbr>______________________________<br>
>>> ______________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscrib" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscrib</a><br>
>>> e<br>
</div></div><span class="im HOEnZb">>>> <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>
>><br>
>> --<br>
>> Juan Antonio Osorio R.<br>
>> e-mail: <a href="mailto:jaosorior@gmail.com">jaosorior@gmail.com</a><br>
>><br>
>><br>
><br>
><br>
><br>
><br>
</span><div class="HOEnZb"><div class="h5">> ______________________________<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" data-smartmail="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>