We’ve noticed that when viewing back traces or service flows, all calls that pass through WSO2 end at WSO2. Presumably the continuation of these calls is registered as a new transaction. DynaTrace claims it doesn’t support wso2, but it DOES support wso2’s underlying http engine, Axis. Therefore, I’m wondering if anyone else has figured out a workaround to maintain this continuity.
For some additional context..
- We’ve confirmed that no DT headers are being stripped at any point
- The trend we’ve noticed is that GETs don’t make it through, while PUTs and POSTs usually do
- An IIS Pool service sends requests to wso2, then wso2 forwards them to a destination spring api
Any insight is greatly appreciated, thank you!
Solved! Go to Solution.
We have WSO2 with the oneagent and dont see such situation.
Our Purepath are represented from the first tier, Java -> to apaches as Reverse proxys -> A10 -> WSO2 -> reverse proxy again -> A10 -> WS02 -> DB
Will check tomorro what version we have. Does the new transaction at WSO2 go as background process? The fact that the dyantrace header is there and no correlation is build is kinda weird.
Thanks for taking the time to respond!
Our new transaction at WSO2 is classified by Dynatrace as a 'background' process, but we aren't doing anything that we can tell to contribute to that misclassification. We're using WSO2 APIM 2.6 with a pretty standard passthroughhttp Axis configuration (with some security modifications for our SSL setup), and we've confirmed with the WSO2 wire logs that no headers are being stripped.
Let us know what you can find :).
Nick (Sean's Colleague)
Following up with some clarification and a solution!
In our original post here, we were referring specifically to WSO2 API Manager v2.0.0
No solution was ever found to restore tracing through that version of the product. However, upon upgrading to v3.2.0, we were able to find a solution. We created the following 2 custom services, and tracing support seems to be fully restored:
Hope this helps someone