Set up agentless Real User Monitoring

Agentless monitoring is designed to be used when you don't have access to your web server and therefore can't install OneAgent. However, before deciding on a third-party library, note that the full benefits of Real User Monitoring can be obtained only after you’ve installed Dynatrace OneAgent.

For some technologies, automatic RUM JavaScript injection is not supported even when you can install OneAgent. For example, while OneAgent can monitor the server side of a Heroku application, it cannot inject the RUM JavaScript into the application's pages. If that's the case, you need to manually add the RUM JavaScript to your application's pages.

For a list of technologies and servers that support automatic RUM JavaScript injection, see Technology support - Real User Monitoring - Web servers and applications.

The installation of Dynatrace OneAgent is highly recommended for the following reasons:

With agentless monitoring, you need to manually insert the RUM JavaScript into each of your application’s pages, which can be challenging. Dynatrace OneAgent handles the insertion of the RUM JavaScript for you.
Unless you use the code snippet or JavaScript tag insertion option for agentless monitoring, the RUM JavaScript embedded into your application’s pages won't be automatically updated when you change application monitoring settings. You’ll have to update the code manually.

Performance impact

To minimize the impact on page-load time and your users’ first impressions of your application, you might want to load scripts as late as possible. Use blocking script tags to ensure that your RUM JavaScript will be executed exactly where you place it. If you need a script to run as early as possible, the execution can’t be postponed. One way to avoid these additional blocking requests during page load is to inline the script code. The script code needs to be inlined into each document, thereby propagating the data of a single cached file into every page of your application. By combining both these approaches, you can get an inline JavaScript snippet that performs the required initialization and defers loading of the big bulk of the code to a second script.

Standards and security policies

Certain development standards that are created to make applications more secure and faster also introduce new limitations. For example, the Content Security Policy (CSP) standard was introduced to minimize the chance of becoming a victim of cross-site scripting, thereby disallowing inline JavaScript code. This means that you have to use a simple JavaScript tag to inject the RUM JavaScript.

Another standard, the AMP project, aims to provide a framework that helps you build applications that are consistently fast across all devices and system platforms. In this case, self-developed and third-party JavaScript code isn't allowed; only scripts provided by AMP can be used.

To monitor AMP applications with Dynatrace

In the Dynatrace menu, go to Deploy Dynatrace.
Select Setup agentless or AMP monitoring.
Turn on My application relies on Accelerated Mobile Pages (AMP).

Maintenance effort

Agentless monitoring requires you to insert tags by yourself, which is why you must ensure that it requires as little manual effort as possible. You don’t want to have to change your code every time your configuration changes or when a new version is released. The code snippet added to your application usually doesn't need to be changed as it takes care of loading the right configuration and version for you.

Insertion methods

The RUM JavaScript insertion format depends on the application and your requirements. Find out about the available options for the RUM JavaScript insertion.

To choose an agentless Real User Monitoring insertion approach

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, go to Injection > Injection.

Go to the Manual insertion tab, and select the required format.

REST API

Dynatrace offers a REST API that allows you to automatically retrieve the latest RUM JavaScript for your application. You can automatically inject the latest code or tag during the build time of your application. To learn how to use the API, see Real User Monitoring JavaScript API.

You can also retrieve URL to download the RUM JavaScript as HTML tag in Dynatrace.

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, go to Injection > Injection.

Go to the Retrieve via API tab, and select the required format.
Select Copy to retrieve the download URL.

Prerequisites

Here's what you'll need to set up agentless Real User Monitoring:

RUM JavaScript—a custom JavaScript code or tag generated by Dynatrace
Access to your application’s HTML source so that you can insert the RUM JavaScript

(Managed deployments only) A CDN to serve the RUM JavaScript that will prevent web page performance problems during Dynatrace Managed Server maintenance periods or local network outages

Set up agentless monitoring

Dynatrace SaaS

In the Dynatrace menu, go to Deploy Dynatrace > Set up agentless or AMP monitoring.
Type in your application’s domain name, and select Add web application. A custom JavaScript snippet for your application is generated.
optional Turn on My application relies on Accelerated Mobile Pages (AMP) if your page is an AMP page. This doesn't allow JavaScript to run on a page and aims at making mobile pages faster.
Select Copy code snippet to copy your application’s custom JavaScript snippet to the clipboard.
Paste the JavaScript snippet from the clipboard into each of your application’s HTML pages that you want to monitor. Dynatrace waits for you to modify your pages’ code and then to see traffic on the website.

Note: If you already have an application that is set up for agentless monitoring, select Applications currently set up for agentless monitoring in step 2 instead of typing in your application’s name. You can then view the list of currently set up applications and their corresponding JavaScript snippets. This is useful when you’ve already added the RUM JavaScript to some of your pages and want to extend monitoring visibility to other pages.

Manual insertion options

To view all the available manual insertion options supported for agentless monitoring

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, go to Injection > Injection.

Go to the Manual insertion tab, and open the dropdown list. The available options are:
- JavaScript tag
- Code snippet
- Inline code
- OneAgent JavaScript tag
Select Download to download the selected option.

You can use the Dynatrace API to fetch the latest RUM JavaScript for injection.

Example

The following example shows a simple page code before and after the RUM JavaScript insertion.

Before injection

html
<html>
<head>
    <title>MyApp</title>
    <script type="text/javascript" src="myapp.js"></script>
</head>

<body>

<form>
    Username: <input type="text name="username"/><br/>
    Password: <input type="password" name="password"/><br/>
    <input type="submit" value="Login">
</form>

After injection

html
<html>
<head>
    <title>MyApp</title>
    <script type="text/javascript" src="//js-cdn.dynatrace.com/jstag/145e12d594f/ruxitagentjs_2nr_1006400120011129.js" data-dtconfig="tp=500,50,0,0,10"></script>
    <script type="text/javascript" src="myapp.js"></script>
</head>

<body>

<form>
    Username: <input type="text name="username"/><br/>
    Password: <input type="password" name="password"/><br/>
    <input type="submit" value="Login">
</form>

Dynatrace Managed

Install a Cluster ActiveGate.
Go to Settings > Public endpoints. In the ActiveGate URL text field, type the URL where your new ActiveGate can be reached. The URL must be publicly accessible and able to accept HTTPS requests.

Note: By default, a Cluster ActiveGate listens on port 9999. If this isn't desired, it's possible to change the port in the ActiveGate configuration. Alternatively, you can use the port of your choice and then redirect the traffic to port 9999 using firewall settings.

Make your cluster production ready

For production monitoring with higher load and strict fail-over requirements, it's required that you use multiple load-balanced Cluster ActiveGates and that you add a caching proxy or CDN to serve the RUM JavaScript.

Load balance multiple ActiveGates

If you take this approach, you'll need to provide your load balancer URL in the activeGate URL text field, as explained above. Requests that your load balancer forwards to Cluster ActiveGates appear as follows:

GET and POST requests for transmitting session information to Dynatrace Managed:

bash
<http|https>://<ClusterActiveGateHostname>/bf/<EnvironmentID>?<internalQueryParameters>

GET requests for the RUM JavaScript:

bash
http[s]://<ClusterActiveGateHostname>/jstag/<ManagedClusterID>/<EnvironmentID>/<InternalApplicationID>/bs.js
http[s]://<ClusterActiveGateHostname>/jstag/<ManagedClusterID>/ruxitagent<configInfo>_<version>.js

Note: Be sure to configure the load balancer to set the x-forwarded-for parameter for all forwarded requests. This parameter contains the IP address of the original request. Dynatrace needs this parameter to determine where the request originated from.

Load balancer should terminate SSL as this is very expensive on Cluster ActiveGate. For a higher performance and if security constraints allow it, traffic can be forwarded via plain HTTP from load balancer to Cluster ActiveGate.

RUM JavaScript caching

To support higher load scenarios when using a load balancer, we recommend that you cache the RUM JavaScript that is loaded from the Cluster ActiveGate using a caching proxy or a CDN.

CDN or caching proxy should forward all requests to <cdnurl>/jstag/** to http[s]://<ActiveGateHostname>/jstag/ to be prepared for configuration changes and updates. There are multiple variants and versions of the RUM JavaScript. URLs can change depending on the application settings.

The CDN/caching proxy should respect the "expires" header. There are RUM JavaScript variants that can be cached forever (1year) and others that can change more often.

Note: If you use the inline code insertion type, you don't need the CDN part, as in such cases the entire RUM JavaScript is inserted into your application’s HTML source.

Serving the RUM JavaScript via CDN

In addition to the obvious benefits of serving the RUM JavaScript from your CDN, with this approach the GET requests for the RUM JavaScript are directed to your CDN.

To serve the RUM JavaScript from your own CDN

Go to Settings > Public endpoints.
Type the root path of your CDN into the CDN for JavaScript tag field (select the little pencil icon).

Update

To simplify updates and configuration changes, you can use the Dynatrace API to get the current RUM JavaScript.

Troubleshooting

To investigate problems that you may encounter with agentless real user monitoring, confirm the following:

The pages to be monitored contain the RUM JavaScript.
The RUM JavaScript is correctly downloaded by the browser (assuming you're not using inline injection). Use browser dev tools to check if the response for the RUM JavaScript is 200 and the response body contains the RUM JavaScript.
The RUM JavaScript is loaded from the correct location (<cdnlocation>/jstag/<tag filename>).
The RUM JavaScript sends beacons to <beaconendpoint>/bf.
You are retrieving and inserting the RUM JavaScript only after fully configuring the public endpoint, such as the load balancer. This ensures that the public endpoint is correctly set in the RUM JavaScript.
The response of the beacon endpoint starts with OK(BF).
The application in the Dynatrace web UI shows data.

User action to distributed trace correlation

For agentless monitoring, the ability to link user actions and distributed traces depends on the technologies that your application uses.

If your application is instrumented with OneAgent, but Real User Monitoring is not supported for its technology, then the distributed traces captured by this OneAgent cannot be linked to user actions.
If your application issues XHR calls to AWS Lambda or to another instrumented web or app server that uses the supported technologies, then it is possible to link user actions and distributed traces. However, these web requests are usually cross-origin requests, so additional configuration is needed to achieve the user action to distributed trace correlation. See Link cross-origin XHR user actions and their distributed traces for details.