Why don't I see my applications or monitoring data?
This page explains what to do when Real User Monitoring (RUM) isn't working in your environment.
To confirm that your application web frontend process is monitored
- From the Dynatrace menu, go to Settings > Monitoring > Monitoring overview.
- Switch to the Process groups tab, and search for the required process group. All monitored processes are listed on this page.
If RUM data is ending up in the wrong application, make sure that you've correctly configured the application detection rules. For details, see Check application detection rules and Define applications for Real User Monitoring | Application detection rules approach.
If you don't see any of your applications or RUM data in the Dynatrace web UI, start by confirming that there's traffic in your web frontend processes (web server, Java, Node.js, and more). To do this, interact with one of your application pages to generate some traffic.
Once you're certain that your web frontend processes have traffic on them, check the following to determine the cause of the problem:
See the expandable sections below for details on confirming these points.
Load one of your pages, inspect its source in the web browser, and make sure that the
Search for a script that contains the
data-dtconfig attribute in the tag.
For agentless monitoring (no OneAgent, no automatic injection)
data-dtconfig attribute in the tag.
In the example above,
[...] indicates a variable URL element, such as an application ID or a configuration parameter.
- The request maps to a different application than expected because application detection was set up incorrectly. Either the pattern is incorrect, or the associated web servers operate behind proxies or other components that are rewriting the URL. For details, see What can I do if an uninstrumented component rewrites parts of the URL?.
- The application that is detected by OneAgent on the first instrumented tier is not propagated to subsequent OneAgents because the
x-dynatrace-applicationheader is removed by a firewall or proxy.
- You have defined exclusion rules for browsers, robots, and spiders.
Open your preferred development tool, go to the Network or Net section, and load your application page in a browser. In the Network section, you should see the list of network operations and their statuses. Look for the following:
- Responses must have
304 Not Modifiedstatus. The script file may come from cache.
To do this, go to your browser developer console, type
dT_, and use Enter. As a result, an object should be returned.
See examples below for Google Chrome that show server responses containing the correct script content:
For agentless monitoring
https://js-cdn.dynatrace.comisn't reachable for client browsers due to firewall rules or proxy server configuration. Connections to and from the host must be allowed.
For automatic injection on web servers
For automatic injection on Java application servers
- In the Dynatrace menu, go to Web.
Select the application that you want to configure.
- In the upper-right corner of the application overview page, select More (…) > Edit.
- From the application settings, select Capturing > Advanced setup.
For agentless monitoring
CORS requests to the Dynatrace infrastructure should be visible. Look for the following:
- URL pattern:
- Responses must have
200 OKstatus, and response content must start with
For automatic injection
XHR requests back to the server-side should be visible. Look for the following:
- URL is relative to the current page location and begins with
- Responses must have
200 OKstatus and response content must start with
If the response content starts with
"FL", the beacon was rejected and not forwarded to the server. The response contains additional information about the problem. One possible root cause is that Dynatrace throttled the capture rate of your application.
Possible reasons for failure
Rules on firewalls, load balancers, or proxies may need to be adapted.
Content security policy settings may need to be adapted.
Java application server setup may need to be adapted.
For agentless monitoring, your browser may not support CORS requests. Data can be reported only via browsers that support CORS.
Content that is delivered as XHTML (content type
To confirm that the monitor signal is correctly passing through your infrastructure to OneAgent, you must call the URL form
<your hostname>/rb_<Your external Environment ID>?$.
To get your environment's URL for the monitor-signal check
- Open your browser's developer tools, and look for an
XHR Postrequest that begins with
rb_<ID>, for example,
- Copy the URL of this request, and append the
?type=checkquery string, for example,
- Use Enter to execute the URL in your browser.
You should receive a response with
status 200 and some text like
As long as the string
state=ok appears (along with other text and HTTP status), then you know that the beacon signal is passing through your servers, and you should be receiving RUM data.
If these suggestions don't resolve your issue, please contact a Dynatrace product expert via live chat within your Dynatrace environment.
In Chrome DevTools, go to the Network tab.
Select More (…) > Network request blocking.
New user sessions aren't reported in real time. There is a delay of 5–6 minutes from the moment a new user session begins until the user session is reflected in charts and other analytical views in the Dynatrace web UI. This delay results in a slight drop in the number of user sessions that are recorded at the end of each time interval during which new user sessions are started.
If your application might be accessed via Internet Explorer 7–10
If your application might be accessed via Internet Explorer 11
1Unsupported Internet Explorer version detected. Only version 11 (without Compatibility View) is supported!
If user action data is missing from your monitored web application, you can perform the following checks in Google Chrome with Chrome DevTools open, and then use Chrome DevTools to verify that certain data exists to see if user action data is captured properly. Select F12 to open Chrome DevTools in Chrome.
Make sure the user action triggers network traffic. Open the Network tab in Chrome DevTools, and then clear all requests. Perform the action you would like to check and inspect the action's network traffic. To do this, check the Type column in the Network tab. If there are no
fetchand won't cause an action to be generated. If you see no
Make sure the action does not use
setTimeout(async). Perform the action you would like to check and use Chrome DevTools to make sure there is an
xhrrequest in the Network tab. If an
xhrrequest exists, hover over the Initiator column in that row and see if there is a line that reads
setTimeout(async). If that is the case, see if enabling
Timed action supporthelps capture this action. If this does not work, or if the Initiator contains
Promise(async), manual instrumentation is necessary. See Missing XHR actions when promises are used for more details.
The following image shows a typical
xhr request in Chrome DevTools, with
setTimeout(async) in the initiator data.
- Make sure the correct modules are activated. Perform the action and use Chrome DevTools to see if the Network tab contains a request with the
xhrtype. Enable the correct module—fetch or a more specialized module for fetch, BasicXHR, or a more specialized module for XHR actions.
- If you configured the cookie domain manually, make sure that it does not overlap with the cookie domain of another application. For details, see Configure the RUM cookie domain for web applications.
- Make sure that your firewalls and proxies let RUM cookies pass through. See Firewall constraints for RUM for details.
- If you configured your infrastructure to add the
dtCookie, remove this attribute; it is not supported for RUM cookies. See Cookies for details.
If your page requests resources from other domains, the Timing-Allow-Origin HTTP response header needs to be set. Otherwise, the browser can't supply the values, and they can't be displayed in the Contributors breakdown chart. If this happens, a message appears in the chart area stating that network and server time can't be calculated because Dynatrace didn't receive W3C resource timings.
Check the following things if some required metadata is missing.
dtrum.getAndEvaluateMetaData()function that captures all the configured metadata and lists the current values. If the metadata was not captured, then the function lists a reason for that.
If the metadata expression is not listed, the page you are currently on might not be mapping to the correct application.
DOM Element valueand
Variable valueentries. Ensure that those entries have valid values.
The following image shows a DOM Element access in the IFrame that contains the DOM Element:
This image shows a DOM Element access in the IFrame that doesn't contain the DOM Element:
See if the DOM selector is wrong or the querySelector isn't available.
Perform the following actions to verify that the DOM selector is correct:
document.querySelectoris available by typing it into the Chrome DevTools console. If it's not available, you won't be able to capture values in this browser. However, this is unlikely as
document.querySelectoris supported even by older browser versions.
document.querySelector('yourselector')returns the value you want to capture. If not, then your
To check the return value for
document.querySelector, perform the desired action in the application. Then in Chrome DevTools, go to the Elements tab, do a string search for
document.querySelector, and verify the return value.
The following image shows data correctly returned from
See if the cookies are using HttpOnly.
If the cookies have the
You can check if the
HttpOnlyflag is set for cookies in the Application tab of Chrome DevTools.
Ensure that cookies are set on the correct domain.
To try this, you can search the
document.cookiestring in the Chrome DevTools console and check if the return string contains the cookie you want to capture.
If you notice your sessions aren't correctly tagged or if you have missing metadata, it's likely due to the application data privacy setting called Do Not Track.
For this setting, the Capture anonymous user-session data for "Do Not Track" enabled browsers option is enabled by default, which is an important element of RUM data privacy. This option ensures that Dynatrace only captures anonymized sessions when the "Do Not Track" setting is detected in users' browsers.
You can change the Do Not Track setting for your application. Note that if you select the Disable Real User Monitoring for "Do Not Track" enabled browsers option, RUM is turned off when the "Do Not Track" setting is detected in users' browsers.
For detailed instructions, see Configure Real User Monitoring according to GDPR | Do Not Track.