On Wed, May 10, 2017 at 5:41 PM, Dan Prince <dpri...@redhat.com> wrote: > On Mon, 2017-04-24 at 07:47 -0400, Joe Talerico wrote: >> Hey owls - I have been playing with oslo.log fluentd integration[1] >> in >> a poc commit here [2]. Enabling the native service logging is nice >> and >> tracebacks no longer multiple inserts into elastic - there is a >> "traceback" key which would contain the traceback if there was one. >> >> The system-level / kernel level logging is still needed with the >> fluent client on each Overcloud node. >> >> I see Martin did the initial work [3] to integrate fluentd, is there >> anyone looking at migrating the OpenStack services to using the >> oslo.log facility? > > Nobody officially implementing this yet that I know of. But it does > look promising. > > The idea of using oslo.logs fluentd formatter could dovetail very > nicely into our new containers (docker) servers for Pike in that it > would allow us to log to stdout directly within the container... but > still support the Fluentd logging interfaces that we have today.
Right, I think we give the user the option for oslo.log fluentd for OpenStack services. We will still need fluentd to send the other noise -- kernel/rabbit/etc > > The only downside would be that not all services in OpenStack support > olso.log (I don't think Swift does for example). Nor do some of the > core services we deploy like Galera and RabbitMQ. So we'd have a mixed > bag of host and stdout logging perhaps for some things or would need to > integrate with Fluentd differently for services without oslo.log > support. Yeah, this is the downside... > > Our current approach to containers logging in TripleO recently landed > here and exposed the logs to a directory on the host specifically so > that we could aim to support Fluentd integrations: > > https://review.openstack.org/#/c/442603/ > > Perhaps we should revisit this in the (near) future to improve our > containers deployments. > > Dan I think oslo.log fluentd fluentd work shouldn't be much to integrate, which could give the container work something to play with sooner than later. Who from the ops-tools side could I work with on this -- or maybe people don't see this as a high enough priority? Joe > >> >> Joe >> >> [1] https://github.com/openstack/oslo.log/blob/master/oslo_log/format >> ters.py#L167 >> [2] https://review.openstack.org/#/c/456760/ >> [3] https://specs.openstack.org/openstack/tripleo-specs/specs/newton/ >> tripleo-opstools-centralized-logging.html >> >> _____________________________________________________________________ >> _____ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs >> cribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev