Skip to content
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

Closed
wants to merge 3 commits into from

Conversation

elevenzqx
Copy link
Contributor

@elevenzqx elevenzqx commented Dec 15, 2021

In this CL:

  • add default noop log emitter, guaranteed to be consistent with tracer and metrics
  • add logEmitterProvider api
  • add unit test cases

@codecov
Copy link

codecov bot commented Dec 15, 2021

Codecov Report

Merging #3994 (aa30995) into main (cbecf1f) will increase coverage by 0.25%.
The diff coverage is 100.00%.

Impacted file tree graph

@@             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     
Impacted Files Coverage Δ
.../opentelemetry/sdk/logs/SdkLogEmitterProvider.java 100.00% <ø> (ø)
...a/io/opentelemetry/sdk/logs/DefaultLogEmitter.java 100.00% <100.00%> (ø)
...ntelemetry/sdk/logs/DefaultLogEmitterProvider.java 100.00% <100.00%> (ø)
.../io/opentelemetry/sdk/logs/LogEmitterProvider.java 100.00% <100.00%> (ø)
...er/otlp/internal/okhttp/OkHttpExporterBuilder.java 87.03% <0.00%> (-5.83%) ⬇️
...telemetry/sdk/metrics/SdkMeterProviderBuilder.java 96.29% <0.00%> (-0.38%) ⬇️
.../io/opentelemetry/sdk/OpenTelemetrySdkBuilder.java 100.00% <0.00%> (ø)
...ry/exporter/otlp/internal/grpc/GrpcStatusUtil.java 100.00% <0.00%> (ø)
...xporter/otlp/internal/grpc/ManagedChannelUtil.java 86.27% <0.00%> (ø)
...xporter/otlp/internal/grpc/OkHttpGrpcExporter.java 82.47% <0.00%> (ø)
... and 27 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cbecf1f...aa30995. Read the comment docs.

Copy link
Contributor

@anuraaga anuraaga left a 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?

@anuraaga
Copy link
Contributor

@trask Do I understand correctly that your PR is the same as this API?

open-telemetry/opentelemetry-java-instrumentation#4917

@trask
Copy link
Member

trask commented Dec 16, 2021

@trask Do I understand correctly that your PR is the same as this API?

open-telemetry/opentelemetry-java-instrumentation#4917

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. */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two thoughts:

  1. 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 to MeterProvider, not SdkMeterProvider. GlobalOpenTelemetry provides access to OpenTelemetry, not OpenTelemetrySdk. Who would use this?

  2. Related to the javadoc: because there are no plans for a log api, this likely isn't a temporary solution.

Copy link
Contributor Author

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 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NoopSpanBuilder => NoopLogBuilder

Copy link
Contributor Author

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();
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@anuraaga
Copy link
Contributor

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?

@elevenzqx
Copy link
Contributor Author

elevenzqx commented Dec 18, 2021

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?

@anuraaga
Copy link
Contributor

that can be used anywhere who want to use log exporter, not just in javaagent

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

@elevenzqx
Copy link
Contributor Author

that can be used anywhere who want to use log exporter, not just in javaagent

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

@elevenzqx elevenzqx closed this Dec 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants