spring agent - spring gateway4.x #12636
Replies: 3 comments 2 replies
-
|
Segment IDs are different as they are in different threads. This is expected case in the Java agent. |
Beta Was this translation helpful? Give feedback.
-
|
I don't have any spring gateway experience, I have repeated thus many times in many issues. It is ok you keep this public here, wait for someone could help, but I am not capable to do that. |
Beta Was this translation helpful? Give feedback.
-
|
There are gateway tesr scenario in the code bases. You could find out how it is tested, and whether your cases and versions are covered. Someone reported weeks ago, new gateway may have different behavior, if so, we rely on new patch from someone to fix this. |
Beta Was this translation helpful? Give feedback.
-
I found a lot of information today I'm not sure if my understanding is correct, but currently there are known issues: I have an additional question to ask. Where can I find the location of the |
Beta Was this translation helpful? Give feedback.
-
|
They are all in skywalking-java repo. |
Beta Was this translation helpful? Give feedback.
-
Search before asking
Apache SkyWalking Component
Java Agent (apache/skywalking-java)
What happened
my project use spring boot 3.2， spring-could-starter-gateway version is 4.1.5
I use skywalking agent version is 9.3.0， oapserver version is 9.3.0
I put the option-plugin “apm-spring-cloud-gateway-4.x-plugin-9.3.0.jar” and “apm-spring-webflux-6.x-plugin-9.3.0.jar” into the agent dir。
Then I conducted tests and found the following issues：
In the gateway service, a request is split into two spans, as shown in the following figure. SpringCloudGateway/RoutingFilter and /testsk/api/inner/login/loginPwd are the same request, and you can see that their trace IDs are the same, but they are displayed as two on SK UI. Upon closer inspection, it is found that their segment IDs are different. Normally, they are all on the same gateway instance, and the segmentation ID should be consistent。
The downstream service user, traceid of the gateway is completely different from that of the gateway, and has not received the traceid passed down by the gateway
So, my problem is that there is a problem with the trace passing inside the gateway. I traced the source code of the agent and found that in NettyRoutingFilterInterceptor, the afterMethod was executed before the subsequent call was initiated, causing ContextManager. stopSpan();. After exiting span, FHIR FinalizerSendInterceptor was executed, and ContextManager. isActive() became null, causing the traceid not to be passed down.
I don't know if I debugged it wrong, but I hope the trace information can be processed correctly within the gateway. I hope everyone can help me
What you expected to happen
I hope the trace information can be processed correctly within the gateway. I hope everyone can help me
How to reproduce
Describe the steps in the previous section
Anything else
No response
Are you willing to submit a pull request to fix on your own?
Code of Conduct
Beta Was this translation helpful? Give feedback.
All reactions