on 02 Jan 2023 06:42 PM - edited on 03 Jan 2023 12:49 AM by MaciejNeumann
When it comes to the Dynatrace Purepath Stitching functionality, it largely comes down to the x-dynatrace HTTP header we add to every request that we can or the dtdTraceTag JMS message property if a request is travelling across messaging queues.
The expectation in most "Requests to unmonitored hosts" is that there is some sort of Proxy, Load Balancer, Firewall, or any other piece of networking equipment between one server and the next that leads to the header being stripped.
Beyond our own x-dynatrace header, we also have the W3C Distributed Tracing functionality within the "Server Side Service Monitoring" > "Deep Monitoring" settings that could be enabled to help address the situation in some circumstances if said equipment supports or otherwise leaves alone the properties used by Distributed Tracing.
There is also potential that in some cases the HTTP client seeing/sending out the requests creates 2 subpath nodes for the exact same URL/request, leading to duplicate listings of the same web request, one that shows as "Requests to unmonitored hosts" and the other that is stitched fully and has all the details.
When it comes to validating if there are potential duplications of URL request sent purepath nodes taking place, this can best be done by inspecting the URL/URI information available between each purepath node to see how similar they are or not.
If such a duplication is not being seen, then the next step should be trying to verify whether or not the x-dynatrace header or JMS tag are being stripped.
When it comes to header presence validation, this can easily be achieved by creating an x-dynatrace header based request attribute to mark what processed purepaths were processed without seeing the necessary information.
Said request attribute creation does not require any restarts and can be configured for all types of OneAgent code modules/special agents and should be created for the Server Side of the purepath transaction as in it should be set up for the called service/process.
You can also configure request attributes to be collected from the Client Side as in the sender of the requests but only if the calling service's technology is .NET or Java based.
You can find the information on creating a request attribute in this documentation.
Hello. Good afternoon. Please help me? In my environment I have a Kubernetes cluster that is monitored with dynakube, but before a request arrives in the cluster, it hits a load balancer that is not monitored. I configured the request attribute x-dynatrace and saw that all requests that appear in the Request to unmonitored hosts service have this attribute. What else can I do to continue the analysis?
@gabrielle either some component such as the mentioned load balancer removes the x-dynatrace header or the service (pod) in the Kubernetes cluster is not deep monitored. Is your process in Kubernetes monitored? If you already set up request attribute for collecting the x-dynatrace request header, do you see it on the called service?
Yes, the process is monitored and I can see the service in dynatrace. I see the request within the monitored service and the same request in requests to unmonitored host. It's as if a request had been divided into two and both have the x-dynatrace attribute.