Break out logs appender API #3880
Conversation
jack-berg
requested review from
anuraaga,
bogdandrutu,
carlosalberto,
jkwatson and
jsuereth
as code owners
Codecov Report
@@ Coverage Diff @@
## main #3880 +/- ##
============================================
+ Coverage 89.70% 90.00% +0.30%
+ Complexity 4230 4204 -26
============================================
Files 504 503 -1
Lines 13059 12911 -148
Branches 1274 1239 -35
============================================
- Hits 11714 11621 -93
+ Misses 915 894 -21
+ Partials 430 396 -34
Continue to review full report at Codecov.
|
|
I don't think we should add an API API for this at this point. There is no spec for it, and I'm not convinced there will be in the near future. Appenders can and should depend directly on the SDK if they need to be sending data to the SDK. Users who need to use an appender can also depend on the SDK, IMO. |
|
This appeared to be the preferred direction for a time. I'm just as happy sticking with only an SDK until something in the spec changes that suggests an API. After all, despite the module name including the I'm fine dropping this, and instead having instrumentation modules place a |
|
I think in Java we have a unique situation where the javaagent will add the appender to a user's app (I guess we're planning this). We usually add instrumentation into, such as this custom appender, into the bootstrap classloader affecting the entire app but we very much don't want to add SDKs there, we keep them in the agent classloader. As long as there's an API split out somewhere, for example |
For RUM, we're planning on designing a RUM API for otel which will be implemented with the various SDKs. The hope is that it'll be RUM specific, though, and not a part of the general use APIs. I'd be good with an sdk-scoped "appender api" for now until we have more clarity about what (if any) a final logs/appender API might look like. |
Sorry if this is a naive question - I haven't studied the java agent's classloader setup: Is there a way to include the appenders in the agent but with a |
|
@jack-berg - the idea of using a user's library has come to mind, for example to redirect the agent's logs through a user's logback.xml. But it's tricky, there can be dependency conflicts between the agent and the user's app that cause LinkageError or similar problems with the approach. Avoiding dependency conflicts is the motivation for the classpath separation and why we like to keep more complicated components, like the SDK, in the agent classloader to not affect the app. |
|
@anuraaga in today's SIG meeting we discussed the possibility of including an appender API in |
|
Closing this in favor of adding an appender API in |
Resolves #3807.
The most interesting decision is what to name the log appender API artifact / module.
I've put it in
:api:logs-appender. I also considered:extensions:logs-appender, but it didn't feel right for:sdk:logsto have a dependency on an extension module. I also chose "logs-appender" instead of "log-appender" for consistency with the plural logs and metrics SDK module names. I'm open to other suggestions.