on - edited on by
HannahM
Summary: Your web application traffic isn't appearing in the defined Dynatrace application or being captured. The best way to troubleshoot this is to narrow down the source of the problem, as it could be an injection or detection issue or be related to a different application.
Troubleshooting steps
Start ruling out the cause by following these steps:
The first step would be to go to the website and open the dev-tools and check the network tab, see if you're able to spot the Dynatrace RUM JavaScript request:
The RUM JavaScript may look different, i.e. '2f34badcac72bfa2_complete.js' or be injected inline directly in HTML starting with '<script type="text/javascript" data-dtconfig='.
That's why, the ultimate way to check for the injection, is to run 'dT_.gdi()' in the console of the browser, if an injection is successful you would get something similar to this:
If the console returns a red output like the following then there is no injection on the website:
When there is an injection:
This means that the traffic is being captured but is being sent to a different application (we're assuming that the beacon requests 'rb_' or 'bf_' are being sent correctly) in Dynatrace. To find out which application you can do multiple things here:
-
Run 'dT_.cfgO()' in the console. This will return multiple pieces of information one of which is the application ID that is handling the injection. This ID is present in the URL of the application page in Dynatrace:
- https://{environmentid}.live.dynatrace.com/#uemapplications/uemappmetrics;uemapplicationId=APPLICATION-EA7C4B59F27D43EB;gtf=-2h;gf=all
- You can go to the service that handles the frontend of the main page, and check for the Distributed Trace / PurePath there.
-
The third method is better because it will help you solve the problem faster (but here we're also assuming that correlation is working, so the User Actions are linked to the Distributed Traces), by checking your session in Dynatrace you're able to jump to the traces captured in Dynatrace. And from those traces you're able to see what the full URL looks like when it was captured:
- Next check Settings -> Web and mobile monitoring -> Host determination. You could have used another header to use as a HOST for the trace.
- Now you can build the full URL its the (Top header from the host determination + URI), for example here the full URL here would be: localhost:8079/
- Next check the application detection rule and it states why this request was assigned to the application, in this case it states that the domain matches localhost.
You will either have to fix the detection rule or fix whatever is changing his URL (Dynatrace does not manipulate the URL we only capture it).
When there is no injection:
-
Open the dev-tools, enable dtHealthCheck and load the website.
-
Check the document request of the page, see if you find 'x-dthealthcheck' in the response headers in the Headers part of the request, if you don't see it, skip to the next point. You should see something similar to this:
-
Usually dtHealthCheck provides us with the information needed, but you might come across a situation where the headers don't show up and this is due to 2 possible reasons:
-
Either the customer didn't disable cache while recording the HAR, let him toggle 'disable cache' and test it in an incognito window:
-
The application is served by a CDN which doesnt have oneagent installed in this case automatic injection is not possible.
-
-
In this case you need to ask the customer to check it on his side.
What's Next
If this article did not help, please open a support ticket, mention that this article was used and provide the following in the ticket:
- A link to the website and some login credentials if access is possible.
- A HAR file or fiddler with 'dtHealthCheck' enabled.
- A link to the service handling the loading of the main page in Dynatrace.
- A link to the application
What to read next:
