-
Notifications
You must be signed in to change notification settings - Fork 565
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
[3.x] - Make Jaeger Tracer OpenTelemetry Agent aware. #6537
[3.x] - Make Jaeger Tracer OpenTelemetry Agent aware. #6537
Conversation
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.
See my suggestion for a more general solution.
Also, even though this is a simple change, it would be good to add a test that shows this solves the reported problem when the agent is present.
|
||
private static boolean checkAgent() { | ||
try { | ||
Class.forName("io.opentelemetry.javaagent.bootstrap.AgentStarter"); |
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.
As we discussed yesterday, this approach handles the single situation in which the OpenTelemetry agent is present (and has established the global tracer itself) but there could be various other cases in which other code (perhaps user code), for whatever reason, has assigned the global tracer before our code has a chance to do so. The OTel agent being present is just one such case.
Is there a way to create a more general solution?
From my quick look I did not see a way to find out simply if the global OpenTelemetry
has been set. We can get
it (OTel automatically creates a no-op instance if set
had not previously been invoked, which does not work focus) or set
it (OTel throws an exception if set
had previously been invoked).
But could we use that behavior to our advantage? I have not tried this, but instead of checking for the presence of the agent, what if the Helidon code which invokes GlobalOpenTelemetry#set
caught the IllegalStateException
, logged a message indicating that the global OTel has already been set, and invokes get
to retrieve that previously-set instance?
That would tell the user that any configuration she had used which Helidon works would not have been used in setting up OT and would allow our code to continue, using either the OTel instance we had built and set or the previously-set one.
The exception which OT throws contains the stack trace captured when GlobalOpenTelemetry#set
was invoked and we could include that in our log message (perhaps at FINE
level) so the user understand what code had set the global OTel instance.
This might be a little more code than what's in the PR currently, but
- it would be less fragile (OTel could change the agent class name whereas it seems less likely they would change the signature and behavior of
GlobalOpenTelemetry#set
, and - it would handle any case, not just the agent case, in which other code has set the global OT instance before our code does.
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.
Please never ever use Class.forName("")
in Helidon.
We should handle this type of requirements differently
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.
Currenty using fast solution with indirect checks of properties and instrumented Context
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.
Fixed
|
||
private static boolean checkAgent() { | ||
try { | ||
Class.forName("io.opentelemetry.javaagent.bootstrap.AgentStarter"); |
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.
Please never ever use Class.forName("")
in Helidon.
We should handle this type of requirements differently
Could I suggest this AgentDetector class instead? @dalexandrov @tomas-langer
|
Nice, but do we really want to use this type of detection. I would consider it as a temporary solution. |
True - it still isn't the best. Using something like this isn't much better either
I'll think on a better solution, and should I come up with one I'll post it here. |
Depends on #6493 for the Agent Detector |
879d7c1
to
5e851b8
Compare
return HelidonOpenTelemetry.create(GlobalOpenTelemetry.get(), | ||
GlobalOpenTelemetry.getTracer(this.serviceName), | ||
tags); |
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 formatting seems wrong. Should not this be on the level where GlobalOpenTelemetry.get() parameter is?
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 is what Idea did....
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.
Fixed
I have been out of the office and am catching up on this PR now. @dalexandrov Did you ever try the approach I described in my 31 March comment? That would avoid any implementation details (such as the name of the agent class, expressed either as a class name or a resource name) which could change from one release to another. It would also support any way that the global tracer might be set--not just by the agent but by any code--before the Helidon code runs and Helidon would then properly work with the established global tracer. |
Hello @tjquinno, |
@dalexandrov We already knew that the Otel API did not permit a get-without-set, as I described in my earlier comment. The OTel code simply throws an Can you please explain why checking for the exception when invoking |
Apparently Mitia has had off-line discussions with Tomas about this. Mitia and I will speak once more about this early next week. |
Mitia walked me through some code that shows my suggestion about catching the exception does not work. The exception is thrown not from the thread which invokes the |
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.
Just formatting issues. Otherwise it looks good from what I can judge. Fix these please and I will approve this.
return HelidonOpenTelemetry.create(GlobalOpenTelemetry.get(), | ||
GlobalOpenTelemetry.getTracer(this.serviceName), tags); |
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 think this formatting is not correct.
It should look like this:
if (HelidonOpenTelemetry.AgentDetector.isAgentPresent(config)) {
return HelidonOpenTelemetry.create(GlobalOpenTelemetry.get(),
GlobalOpenTelemetry.getTracer(this.serviceName),
tags);
}
Every method paramter should be on the new line. It improves readablity.
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...
(#6537 (comment))
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.
it was wrong at that point as well. since it was at the level of return
instead of create
method and that was what I was talking about.
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.
fixed :)
Resolves #6174 for Jager Tracer