[openstack-dev] [tripleo][logging] oslo.log fluentd native logging
jtaleric at redhat.com
Mon May 15 16:52:02 UTC 2017
On Wed, May 10, 2017 at 5:41 PM, Dan Prince <dprince at 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
>> a poc commit here . Enabling the native service logging is nice
>> 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  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
> 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
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:
> Perhaps we should revisit this in the (near) future to improve our
> containers deployments.
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
Who from the ops-tools side could I work with on this -- or maybe
people don't see this as a high enough priority?
>>  https://github.com/openstack/oslo.log/blob/master/oslo_log/format
>>  https://review.openstack.org/#/c/456760/
>>  https://specs.openstack.org/openstack/tripleo-specs/specs/newton/
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev