Hey @serhii.homeniuk, Thank you for reaching out.
TBH, having the methods instrumented is the best way to deal with issues with Netty where Spring cloud gateway is involved.
I would also like to give you a little bit of a glimpse under the hood, regarding how our agent’s various instrumentation packages work together, and how the agent goes about starting and naming transactions. When an HTTP request first hits your server, assuming you’re running a supported web server (we support Netty 3.3.0.Alpha1 to 5.0.0.Alpha1), we mark a transaction start point and assign a name. That name is usually the page URI. But, as that request moves through your application, the agent will notice and recognize certain method calls that match one of its instrumentation packages. For example, it recognizes spring controllers that are annotated with the @Controller annotation.
As it does so, it renames the transaction that appears in APM, as per our transaction naming protocol.
So a single transaction trace might be named based on page URI, then renamed NettyDispatcher when it hits our Netty instrumentation, and then renamed again to a controller name when it hits our Spring instrumentation.
We do have instrumentation for Spring however, we don’t have an instrumentation package specific to Spring cloud gateway, which I see in your application. Please check out our Compatibility and requirements for the Java agent.
I understand you might not want to make code changes every time you install an agent on Netty, but you can leverage custom instrumentation editor where you have the capability to instrument methods through NR UI itself.
The other way to maybe mitigate this issue is by disabling
auto_transaction_naming from the YAML file. This will just be a troubleshooting step. We, however, do not recommend this step as it might lead to and MGI. Relic Solution: Video - Understanding Metric Grouping Issues in 80 seconds and will start sending us unusual unique metric names.
Let me know if that helps. Cheers!