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

RUM-3405 Provide core tracer logger implementation #1953

Conversation

mariusc83
Copy link
Member

What does this PR do?

A brief description of the change being made with this pull request.

Motivation

What inspired you to submit this pull request?

Additional Notes

Anything else we should know when reviewing?

Review checklist (to be filled by reviewers)

  • Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
  • Make sure you discussed the feature or bugfix with the maintaining team in an Issue
  • Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

@mariusc83 mariusc83 self-assigned this Mar 29, 2024
@mariusc83 mariusc83 requested review from a team as code owners March 29, 2024 13:31
@mariusc83 mariusc83 marked this pull request as draft March 29, 2024 13:32
@mariusc83 mariusc83 force-pushed the mconstantin/rum-3405/provide-core-tracer-logger-implementation branch 2 times, most recently from 2a7a9a4 to e52fa08 Compare March 29, 2024 13:53
@codecov-commenter
Copy link

codecov-commenter commented Mar 29, 2024

Codecov Report

Merging #1953 (92bd5f3) into feature/otel-support (3cfe958) will increase coverage by 0.06%.
The diff coverage is 41.79%.

❗ Current head 92bd5f3 differs from pull request most recent head ef74896. Consider uploading reports for the commit ef74896 to get more accurate results

Additional details and impacted files
@@                   Coverage Diff                    @@
##           feature/otel-support    #1953      +/-   ##
========================================================
+ Coverage                 60.00%   60.06%   +0.06%     
========================================================
  Files                       803      805       +2     
  Lines                     30050    30119      +69     
  Branches                   4928     4929       +1     
========================================================
+ Hits                      18030    18089      +59     
- Misses                    10810    10822      +12     
+ Partials                   1210     1208       -2     
Files Coverage Δ
...c/main/java/com/datadog/trace/core/CoreTracer.java 63.71% <100.00%> (+0.36%) ⬆️
...e/src/main/java/com/datadog/trace/core/DDSpan.java 56.47% <100.00%> (-0.19%) ⬇️
...main/java/com/datadog/trace/core/PendingTrace.java 80.95% <100.00%> (ø)
...ava/com/datadog/trace/core/PendingTraceBuffer.java 64.89% <100.00%> (ø)
.../trace/core/scopemanager/AbstractContinuation.java 100.00% <100.00%> (ø)
...main/java/com/datadog/trace/logger/NoOpLogger.java 33.33% <ø> (+5.21%) ⬆️
...in/com/datadog/android/trace/OtelTracerProvider.kt 96.05% <100.00%> (+0.05%) ⬆️
...datadog/android/trace/logger/NoOpInternalLogger.kt 100.00% <100.00%> (ø)
...tadog/trace/core/scopemanager/ContinuingScope.java 0.00% <0.00%> (ø)
...n/java/com/datadog/trace/logger/LoggerFactory.java 42.86% <50.00%> (+2.86%) ⬆️
... and 6 more

... and 26 files with indirect coverage changes

@mariusc83 mariusc83 marked this pull request as ready for review March 29, 2024 14:56
@JvmField
val UNBOUND: InternalLogger = SdkInternalLogger(null)
Copy link
Member

Choose a reason for hiding this comment

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

I think you don't need to use UNBOUND. According to the code, you have access to the sdkCore.internalLogger in the OtelTracerProvider.Builder.build() which calls CoreTracer.CoreTracerBuilder() - you can just inject sdkCore.internalLogger there and pass it down to the CoreTracer instance then.

Is there a need in the UNBOUND then and thus this change?

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, I think I did not want to provide it as optional there in the builder but yes it can work this way. I will change it back.

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure why it should be optional. If it is provided in the constructor of CoreTracer.CoreTracerBuilder() why it should be?

InternalLogger.UNBOUND is only for cases when there is no possibility to get logger associated with particular SDK core. This logger is not able to send telemetry and logs produced cannot print the SDK core instance used.

Copy link
Member Author

Choose a reason for hiding this comment

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

yes...that's the thing, I did not want to provide it in the constructor, not sure why, can't remember, but think it about it now I don't see why I should not.

Copy link
Member Author

Choose a reason for hiding this comment

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

actually it is because I do not want to use modify the static method: CoreTracer:builder to CoreTracer:builder(logger) but will provide a NoOpInternalLogger implementation instead.

@mariusc83 mariusc83 force-pushed the mconstantin/rum-3405/provide-core-tracer-logger-implementation branch 3 times, most recently from 92bd5f3 to ef74896 Compare April 2, 2024 14:42
@mariusc83 mariusc83 requested a review from 0xnm April 2, 2024 14:53
0xnm
0xnm previously approved these changes Apr 3, 2024
Copy link
Member

@0xnm 0xnm left a comment

Choose a reason for hiding this comment

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

I left some comments, but I guess nothing blocking.

Comment on lines 376 to 379
public CoreTracerBuilder internalLogger(InternalLogger internalLogger) {
this.internalLogger = internalLogger;
return this;
}
Copy link
Member

Choose a reason for hiding this comment

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

is this method still needed given that we use constructor to inject logger?

Copy link
Member Author

Choose a reason for hiding this comment

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

I am keeping it just in case.

@NonNull DDSpanContext context,
final List<AgentSpanLink> links) {
final DDSpan span = new DDSpan(instrumentationName, timestampMicro, context, links);
log.debug("Started span: {}", span);
Copy link
Member

Choose a reason for hiding this comment

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

don't need this anymore?

Copy link
Member Author

Choose a reason for hiding this comment

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

I think I removed it because I could see the log also elsewhere. I will double check.

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, it was a call on a static instance log which now it is a private class instance. I will move it to the constructor instead.

import java.util.Arrays;
import java.util.Locale;

public class DatadogCoreTracerLogger implements Logger {
Copy link
Member

Choose a reason for hiding this comment

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

minor thought: is name still valid? I don't see any relationship with CoreTracer here.

Copy link
Member Author

Choose a reason for hiding this comment

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

It is as this is the Logger implementation for the CoreTracer module.

public final class LoggerFactory {

@NonNull
public static Logger getLogger(String name) {
return new NoOpLogger();
Copy link
Member

Choose a reason for hiding this comment

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

seems like we still can have places without any log coverage?

Copy link
Member Author

Choose a reason for hiding this comment

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

yes but it is quite a lot if we want to cover all the code, I covered all the important places and most of all the other places where these methods are used are not actually needed in the CoreTracer and maybe I will remove them at the end in a final clean.

.withProperties(properties())
.serviceName(serviceName)
.writer(tracingFeature?.otelDataWriter ?: NoOpOtelWriter())
.partialFlushMinSpans(partialFlushThreshold)
.idGenerationStrategy(IdGenerationStrategy.fromName("SECURE_RANDOM", false))
.internalLogger(sdkCore.internalLogger)
Copy link
Member

Choose a reason for hiding this comment

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

why do we need to call this if we already injected logger in the constructor above?

Copy link
Member Author

Choose a reason for hiding this comment

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

I wanted to keep this method just in case for flexibility later. Not sure if we still need to. What do you think ?

Copy link
Member

Choose a reason for hiding this comment

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

if we need it, we can add it later, but currently it creates just some confusion in the API imo, since it is already provided in the constructor.

@StringForgery
lateinit var fakeMessage: String

private lateinit var expectedFakeMessage: String
Copy link
Member

Choose a reason for hiding this comment

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

minor suggestion: fakes lingvo is usually just for the setup phase. And also for the consistency, because in some assertions it is already called as expectedMessage.

Another suggestion is to remove it from the properties as have as a function.

Suggested change
private lateinit var expectedFakeMessage: String
private lateinit var expectedMessage: String

@mariusc83 mariusc83 force-pushed the mconstantin/rum-3405/provide-core-tracer-logger-implementation branch from ef74896 to 41370c3 Compare April 3, 2024 08:34
@mariusc83 mariusc83 requested a review from 0xnm April 3, 2024 08:53
@mariusc83 mariusc83 merged commit 0e43b0d into feature/otel-support Apr 3, 2024
25 checks passed
@mariusc83 mariusc83 deleted the mconstantin/rum-3405/provide-core-tracer-logger-implementation branch April 3, 2024 09:30
@xgouchet xgouchet added this to the 2.11.x milestone Jul 31, 2024
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