-
Notifications
You must be signed in to change notification settings - Fork 613
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
ISPN-15156 Avoid to spam DEBUG log when OpenTelemetry is not found on the client #11272
Conversation
I would probably move all the checks to public interface TelemetryService {
TelemetryService INSTANCE = createInstance();
/**
* Try to create a {@link TelemetryService} instance.
*
* @throws ClassCastException if the OpenTelemetry API module is not in the classpath
* @return a {@link TelemetryService} instance
*/
static TelemetryService create() {
return INSTANCE;
}
void injectSpanContext(HeaderParams header);
private static TelemetryService createInstance() {
try {
Class.forName("io.opentelemetry.api.trace.propagation.W3CTraceContextPropagator", false,
TelemetryService.class.getClassLoader());
return new TelemetryServiceImpl();
} catch (ClassNotFoundException e) {
// log warning that opentelemetry is not in the classpath
}
// return no-op implementation
return header -> {
//no-op
};
}
} |
I don't know, since there is the case of |
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.
Looks good, just some comments on the levels.
@@ -387,9 +387,9 @@ public interface Log extends BasicLogger { | |||
@Message(value = "Native IOUring transport not available, using NIO instead: %s", id = 4108) | |||
void ioUringNotAvailable(String cause); | |||
|
|||
@LogMessage(level = DEBUG) | |||
@LogMessage(level = TRACE) |
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.
DEBUG for this is okay now that it is only logged once and without a stack trace.
@@ -399,4 +399,8 @@ public interface Log extends BasicLogger { | |||
@Message(value = "OpenTelemetry API is present in the classpath, but the tracing propagation is not enabled. Client context tracing will not be propagated.", id = 4111) | |||
void openTelemetryPropagationDisabled(); | |||
|
|||
@LogMessage(level = DEBUG) |
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.
I wonder if this should be ERROR now? If this exception is encountered the user has open telemetry on the classpath and has explicitly configured trace propagation.
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.
Right this error shouldn't happen, since we've already checked that the OpenTelemetry is present on the classpath.
It looks like a very runtime exception...
Looking at the code that is executed by the current OpenTelemetry version, it should be safe to call W3CTraceContextPropagator.getInstance()
.
Anyway we don't have control over this library, that's the reason I introduced the check.
In general implementing tracing I usually write code that is usually more defensive, since in any case tracing should not affect the main behavior of the application.
Anyway it is OK for me to remove this check.
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.
Oh I am not saying to remove it. Whether we let it propagate or log the exception is up to you, you know more issues that may cause this to happen. I was only proposing it be higher priority log level.
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.
Sure, makes sense
@@ -399,4 +399,8 @@ public interface Log extends BasicLogger { | |||
@Message(value = "OpenTelemetry API is present in the classpath, but the tracing propagation is not enabled. Client context tracing will not be propagated.", id = 4111) | |||
void openTelemetryPropagationDisabled(); |
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.
This and openTelemetryPropagationEnabled may want to be TRACE since they are logged for every cache that is used when telemetry is on the classpath. DEBUG may be fine, just want to make sure this spot is considered for evaluation.
What is your concern exactly? |
I wanted to make the TelemetryService creation lazy. But since this instance is very simple, we can have it eager as well. |
15601b8
to
96f40d2
Compare
96f40d2
to
86ea641
Compare
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.
LGTM. Personally, if we trying to avoid spam debug messages, I would just remove them instead of changing them to trace. Just my 2cents.
86ea641
to
ff56668
Compare
You're right. We can expect we don't have the OpenTelemetry library on the client VM most of the time. With the last push I set the last debug log to trace. |
ff56668
to
0400919
Compare
When OpenTelemetry is not found on the client
0400919
to
deb4423
Compare
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.
LGTM, just one last question though. Is there a reason the client/hotrod-client
module logs if the telemetry API is present or not and client/hotrod
doesn't? It looks like there is no way to disable or enable it per cache with the new module?
Thank for the review @wburns
I'm not really sure that the latter doesn't.
Enabling / disabling tracing on cache basis is part of Tracing 2.0 targeting Infinispan 15. I'm finishing these days https://github.com/fax4ever/infinispan/tree/ISPN-14974. |
I was taking that from the diff in that the following code only exists in client/hotrod-client module. if (cfg.tracingPropagationEnabled()) {
telemetryService = TelemetryService.INSTANCE;
log.openTelemetryPropagationEnabled();
} else {
log.openTelemetryPropagationDisabled();
}
Sorry, didn't realize it was a global configuration not per cache. |
On the client/hotrod in the init of TelemetryService telemetryService = TelemetryService.INSTANCE; the first access to the interface should initialize the singleton if i don't get wrong: TelemetryService INSTANCE = createInstance();
static TelemetryService createInstance() {
try {
Class.forName("io.opentelemetry.api.trace.propagation.W3CTraceContextPropagator", false,
TelemetryService.class.getClassLoader());
} catch (ClassNotFoundException e) {
log.noOpenTelemetryAPI();
return null;
}
try {
return new TelemetryServiceImpl();
} catch (Throwable e) {
log.errorCreatingPropagationContext(e);
return null;
}
} |
Sorry @wburns I just realized that you asked for the enable / disable propagation log and not for the main log. |
Integrated into main, thanks @fax4ever ! |
Thank you @wburns! |
https://issues.redhat.com/browse/ISPN-15156