-
Notifications
You must be signed in to change notification settings - Fork 205
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
W3C tracing correlating only 99% of the time using webclients under agent 3.0 #1453
Comments
Just realised that I could dump the headers on the second application to see more what is going on. So, for the requests that don't have a corresponding first application match we have headers such as
This indicates to me that the second application is receiving all the correct W3C headers. Looking at |
hey @petergphillips, are there any warnings or errors in the applicationinsights.log file on the first application? thanks! |
hi @trask, no there aren't any of either of them. Just reproduced the bug with level set to
Looking at the log file the only times that |
hey @petergphillips, I think this was resolved very recently upstream (open-telemetry/opentelemetry-java-instrumentation#2156), and that fix is in the latest SNAPSHOT: applicationinsights-agent-3.0.3-BETA-SNAPSHOT.jar.zip in case you have a chance to give it a try. |
Hi @trask, just had a try with that latest snapshot. Still same result I'm afraid in that the same proportion aren't being matched. However with
so it looks like something is going wrong with the wrapping and therefore the correlation? |
hey @petergphillips, there was another fix upstream related to context correlation in netty, and new support for reactor-netty that we pulled in to our distribution. do you mind giving the latest snapshot another try? applicationinsights-agent-3.0.3-BETA-SNAPSHOT.jar.zip |
hi @trask, just had a go with the latest snapshot and all seems to be working fine now. All the requests are being correlated correctly 👍 |
oh, that's awesome! thanks for your patience, planning to release 3.0.3-BETA end of this week or beginning of next week |
3.0.3-BETA is released! |
Expected behaviour
When one spring boot application calls out to another spring boot application using
WebClient
the java agent will set headers so that request can be correlated. Under 2.6.2 there was no support forWebClient
so requests weren't being correlated at all. We expect all requests to be correlated correctly, sodependencies
shows the outgoingoperation_Id
and thenrequests
shows the incoming request with the sameoperation_Id
.Actual behaviour
About 1% of the requests aren't being correlated correctly. In the first application I can see that the request has generated a new
operation_Id
which is duplicated in theoperation_ParentId
column too. I can see the outgoing request independencies
with the sameoperation_Id
.However in the second application about 1% of the time the request gets a different
operation_Id
that doesn't match the first application request and can't be matched with any other requests going on at the same time. Theoperation_ParentId
then has a completely different value too and doesn't even match theoperation_Id
, indicating to me that thetraceparent
is coming through, but with incorrect values.To Reproduce
Make lots of calls to the first application and then check app insights.
I have been doing
and then checking app insights to see if there are any requests that aren't correlated:
I don't seem to be able to reproduce the behaviour with two servers running locally, but can reproduce if the second server is in the cloud - tried both AWS & Azure with same results.
Sample Application
Project to replicate the issue is https://github.com/ministryofjustice/prison-estate.git. Need Java 11. Replace with your key for app insights.
The first application can run locally:
The second application can be any spring boot app connected to the same app insights running in the cloud, the first app needs to be started with that url.
System information
SDK Version: 2.6.2
Java Agent Version: 3.0.2
OS type and version: Debian 14
Application Server type and version (if applicable): Spring Boot 2.4.2
Using spring-boot? yes
The text was updated successfully, but these errors were encountered: