-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenTracing: Intercept log messages to record against any available a… #1559
Conversation
@davsclaus Attempt at a mechanism for intercepting log messages to associate with an active Span. Happy to change approach if you have better suggestions, as not sure if this approach may lead to issues:
|
Is there an use case for this? I think this is very invasive on users to just trap all logs. If there is some kind of opentracing logger trap, then I would rather see this hooked into the logger APIs. There is a logger API for MDC and I think its called Marker in slf4j where you can associate some custom key/values that the logger can output if instructed to do so. |
For use case, there is something on the opentracing website: http://opentracing.io/documentation/pages/instrumentation/common-use-cases.html - see "Logging Events" section near the end. This log event capability in opentracing is not intended to be a replacement for a general logging mechanism, or a centralised logging solution - but to enable significant events to be logged that occur in the context of a span (unit of work) and therefore an overall trace instance. There are two ways this can be achieved - one is by annotating the logs generated by the application with a trace/span correlation id - this is being discussed in opentracing/specification#24 which appears to be coming to agreement. However to support users who identify a particular trace/span and want to then investigate further details (i.e. the logs) this requires some level of backend integration between the tracing system and the aggregated logging mechanism - otherwise this will be a manual process. Second approach (where supported by the tracing solution - as not all will support the recording of events) is to capture these logged events in the context of the trace/span. Where visible via the tracing tool, it provides easy access to more detailed information (for diagnostic purposes) in the absence of linked aggregated logs. For this particular case, I thought the I'll investigate whether hooking into individual loggers would provide a cleaner solution. If beneficial, I could ask the OpenTracing authors to provide their perspective on the log event capability? Or feel free to raise an issue in the https://github.com/opentracing/opentracing.io repo - especially if you don't feel the use case description is compelling enough. |
Okay so you want to allow using the Log EIP (eg .log or in Camel route) to make those user messages logged with span details. Then that is a better understanding. If so I think maybe we should look at a better way to the hooks and do this more directly in the Log EIP itself and not "trap all slf4j logger". So it may be that we need some improvements to LogDefinition and the CamelLogger that it end up using that calls the logger I think maybe its cleaner and more nicer to provide some kind of SPI in camel-core that 3rd party components can implement and register which allows them to have callbacks in the LogEIP and then enrich/influence the logging, so opentracing can do that. Then we are not 'playing' with slf4j logger. |
That sounds good to me. Is this something you would implement, as it is part of camel-core? |
@objectiser I have asked @igarashitm to help with this as he is already doing some related work on the Log EIP. I am also on PTO this week doing some writing on my Camel book. So only have limited time in this community. |
Yep, I'll look into soon after I finish the mask stuff! |
@davsclaus Ok thanks |
…ctive span