-
Notifications
You must be signed in to change notification settings - Fork 50
Add top level support for logging #130
Comments
can we clarify what the goal is here a little more specifically?
Are we looking at a generalized feature for log ingest that allows
correlation (like stackdriver enhancer) this would be appender based I
guess..
or is this a correlation with other logging library contexts (like MDC in
log4j)?
|
Using We use To move the conversation forward, I put together a working experiment of what this library might look like, https://github.com/savaki/opencensus-go/tree/logging/log Like In languages like Java, I would imagine we would want to make available exporters for common packages like |
Thanks for the info. so this sounds like a primary interface for logging, then. Ex user code would use it directly instead of another library. Would you expect this only to be the case in languages where there is no dominant logging library? Ex in java would you expect folks to use something like this instead of SLF4J or log4j2 etc? Or would you use an integration pattern there instead (asking the more general question as this is a spec repo so seemingly cross language) |
That's a good question. As I understand it, one of the main value propositions of OpenCensus is that it provides standard interface for common operational operations like tracing and metrics across many languages and many service providers. When I write to the OpenCensus API, I have the promise of portability between the supported providers. It's reasonably easy to swap out Zipkin for Stackdriver for example. The intent of this proposal is to extend that promise to logging. Disclaimer: I'm not very familiar with the OC Java implementation. That said, it seems that if we want to allow users to integrate logging an existing Java app with OC, there are a number of approaches. Configuration Only Custom Marker Primary Interface I'm not a Java expert, so I certainly admit I could be missing something. |
I think there is an option 4 in java, which is to synchronize a logging
context when applying the tracing one. That's what's in use by brave for
example and doesn't require users to depend on instrumentation code. Note
it is also needed as many can't or won't change other libraries like
zookeeper's logging library etc.
https://github.com/openzipkin/brave/blob/master/context/slf4j/src/main/java/brave/context/slf4j/MDCCurrentTraceContext.java#L55
In practice, folks write custom plugins to propagate more data than IDs for
example to the logging context, or data from other sources. Such plugins
don't affect call sites.
There are also plugins for this at least in log4j2 maybe also in the new
slf4j as well not sure..
https://logging.apache.org/log4j/2.x/manual/extending.html#Custom_ContextDataInjector
Note: I've never seen ContextDataInjector set outside the internals of
log4j2 itself, but that doesn't mean it hasn't happened
|
Finding this issue in search of an open-census opinion on logging. I think a point of value of open-census is a nice decoupling from platform implementation. So metrics instrumentation can work with multiple backends. The same could be applied to logging in way that logrus has done for golang (eg I wrote a stackdriver logging plugin for logrus - stackrus). But logrus is golang centric, while open-census is polyglot. If a large team wanted to adopt a standard logging framework, and then leave infrastructure implementation up to a platform team, open-census seems like a good project to provide that decoupling. (correlation to traces is a bonus, but different thing) |
@c24t @mtwo -- see #130 (comment) above. |
@ptone this is something that we're very interested in, and @c24t is working on some prototypes in Python. We wrote a plan a few months ago describing our goals and current thinking - feel free to comment or suggest edits (open it, apply for comment access, I'll grant it). |
In addition to metrics and traces, opencensus should also include support for logging. Tags are an incredibly useful feature and being able to share a common set of tags across metrics and logging is incredibly useful not to mention the ability to correlate logs with traces as referenced here:
#123
The text was updated successfully, but these errors were encountered: