-
Notifications
You must be signed in to change notification settings - Fork 858
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
Add support for log emitter provider #3994
Conversation
Codecov Report
@@ Coverage Diff @@
## main #3994 +/- ##
============================================
+ Coverage 89.71% 89.96% +0.25%
- Complexity 4272 4287 +15
============================================
Files 513 515 +2
Lines 12941 12965 +24
Branches 1248 1250 +2
============================================
+ Hits 11610 11664 +54
+ Misses 927 900 -27
+ Partials 404 401 -3
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jack-berg Can you check out this PR?
@trask Do I understand correctly that your PR is the same as this API? |
I don't think so. open-telemetry/opentelemetry-java-instrumentation#4917 introduces a way for instrumentation to avoid direct dependency on SDK, which we need for javaagent bridging. |
|
||
package io.opentelemetry.sdk.logs; | ||
|
||
/** This class is a temporary solution until log SDK is marked stable. */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two thoughts:
-
Do we want a global accessor for the log sdk? There's not a precedent for providing global accessor for SDK components.
GlobalMeterProvider
provides access toMeterProvider
, notSdkMeterProvider
.GlobalOpenTelemetry
provides access toOpenTelemetry
, notOpenTelemetrySdk
. Who would use this? -
Related to the javadoc: because there are no plans for a log api, this likely isn't a temporary solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I see and It has been deleted; this can be defined in my business code in a private way
} | ||
|
||
// Noop implementation of LogEmitter.Builder. | ||
private static final class NoopSpanBuilder implements LogBuilder { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NoopSpanBuilder
=> NoopLogBuilder
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
|
||
@Override | ||
public LogBuilder logBuilder() { | ||
return new NoopSpanBuilder(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can use a singleton here instead of instantiating a new instance each time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
Hi @elevenzhan - we are currently working on a logs appender API in the instrumentation API here open-telemetry/opentelemetry-java-instrumentation#4917 This is because we only expect it to be used by log appenders, not by end users. Will that satisfy your use case? |
Hi @anuraaga - I simplified the implementation and removed global provider; javaagent is a greatest way to resolve logs export, but in some unusable scenarios, It cannot overwrite these scenes; this CR provides a LogEmitterProvider api and noop implementation, that can be used anywhere who want to use log exporter, not just in javaagent Let's see if this MR is useful? |
The logs appender API in the java-instrumentation repo is just a library, it will be used for instrumentation both within the javaagent and without. So I think this one is mostly a dupe of that API |
thanks @anuraaga, I see instrumentation-api-appender is consistent with current MR, so I will close this merge |
In this CL: