<div dir="ltr">Guys, thank you for your feedback. As a quick and dirty solution we continue to hide extra information from UI. It will not break existing user experience.<div><br></div><div>Roman, there were attempts to get rid of our current web logs page and use Logstash. As usual, it's all about time and resources. It is our backlog, but it is not in our current roadmap.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 6:11 PM, Roman Prykhodchenko <span dir="ltr"><<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks!<br>
<br>
In most productions environments I’ve seen bare logs as they are shown now in Fuel web UI were pretty useless. If someone has an infrastructure that consists of more that 5 servers and 5 services running on them they are most likely to use logstash, loggly or any other log management system. There are options for forwarding these logs to a remote log server and that’s what is likely to be used IRL.<br>
<br>
Therefore for production environments formatting logs in Fuel web UI or even showing them is a cool but pretty useless feature. In addition to being useless in production environments it also creates additional load to the user interface.<br>
<br>
However, I can see that developers actually use it for debugging or troubleshooting, so my proposal is to introduce an option for disabling this feature completely.<br>
<br>
<br>
- romcheg<br>
<div class="HOEnZb"><div class="h5"><br>
> On 15 Dec 2014, at 12:40, Tomasz Napierala <<a href="mailto:tnapierala@mirantis.com">tnapierala@mirantis.com</a>> wrote:<br>
><br>
> Also +1 here.<br>
> In huge envs we already have problems with parsing performance. In long long term we need to think about other log management solution<br>
><br>
><br>
>> On 12 Dec 2014, at 23:17, Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>> wrote:<br>
>><br>
>> +1 to stop parsing logs on UI and show them "as is". I think it's more<br>
>> than enough for all users.<br>
>><br>
>> On Fri, Dec 12, 2014 at 8:35 PM, Dmitry Pyzhov <<a href="mailto:dpyzhov@mirantis.com">dpyzhov@mirantis.com</a>> wrote:<br>
>>> We have a high priority bug in 6.0:<br>
>>> <a href="https://bugs.launchpad.net/fuel/+bug/1401852" target="_blank">https://bugs.launchpad.net/fuel/+bug/1401852</a>. Here is the story.<br>
>>><br>
>>> Our openstack services use to send logs in strange format with extra copy of<br>
>>> timestamp and loglevel:<br>
>>> ==> ./neutron-metadata-agent.log <==<br>
>>> 2014-12-12T11:00:30.098105+00:00 info: 2014-12-12 11:00:30.003 14349 INFO<br>
>>> neutron.common.config [-] Logging enabled!<br>
>>><br>
>>> And we have a workaround for this. We hide extra timestamp and use second<br>
>>> loglevel.<br>
>>><br>
>>> In Juno some of services have updated oslo.logging and now send logs in<br>
>>> simple format:<br>
>>> ==> ./nova-api.log <==<br>
>>> 2014-12-12T10:57:15.437488+00:00 debug: Loading app ec2 from<br>
>>> /etc/nova/api-paste.ini<br>
>>><br>
>>> In order to keep backward compatibility and deal with both formats we have a<br>
>>> dirty workaround for our workaround:<br>
>>> <a href="https://review.openstack.org/#/c/141450/" target="_blank">https://review.openstack.org/#/c/141450/</a><br>
>>><br>
>>> As I see, our best choice here is to throw away all workarounds and show<br>
>>> logs on UI as is. If service sends duplicated data - we should show<br>
>>> duplicated data.<br>
>>><br>
>>> Long term fix here is to update oslo.logging in all packages. We can do it<br>
>>> in 6.1.<br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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><br>
>>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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><br>
><br>
> --<br>
> Tomasz 'Zen' Napierala<br>
> Sr. OpenStack Engineer<br>
> <a href="mailto:tnapierala@mirantis.com">tnapierala@mirantis.com</a><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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><br>
<br>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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><br>
<br></blockquote></div></div>