How do I enable agentless Real User Monitoring?

This topic applies to Dynatrace Managed installations only.

Normally you benefit from Real User Monitoring only after you've installed Dynatrace. The manual approach to setup described here—otherwise known as agentless Real User Monitoring—should only be used for installations where you aren't able to start deep monitoring, for example because you have no Dynatrace installed on your web server machine.

Note:

  • Keep in mind that you'll need to manually insert a JavaScript tag into each of your application’s pages. You may find it challenging to insert the JavaScript tags in the right places (this is something that Dynatrace handles automatically).
  • The JavaScript tags embedded in your application’s pages will not be automatically updated if you change application monitoring settings—you’ll need to update the tags manually (this is something that Dynatrace handles automatically).

To enable agentless Real User Monitoring, follow the steps outlined below.

Before you begin

What you'll need:

  • Ensure that you have access to your application’s HTML source so that you can insert the JavaScript tags.
  • Using a CDN to serve the JavaScript tag is highly recommended and can prevent web page performance problems during Managed Server maintenance periods and/or local network outages.
  • You'll need a custom JavaScript tag generated by Dynatrace.

Set up agentless Real User Monitoring

To set up agentless Real User Monitoring:

  1. Install a public managed Security Gateway.
  2. Go to Settings > Public endpoints. In the Security Gateway URL text field, type the URL where your new Security Gateway can be reached. The URL must be publicly accessible and able to accept HTTPS requests.

Note: By default, public Managed Security Gateways listen on port 9999. If this isn't desired, it's possible to change the port in the Security Gateway configuration file. 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 Security Gateways and that you add a caching proxy or CDN to serve the JavaScript code.

Load balance multiple security gateways

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

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

<http|https>://<SecurityGatewayHostname>/bf/<InternalEnvironmentID>?<internalQueryParameters>

GET requests for the JavaScript tag:

http[s]://<SecurityGatewayHostname>/jstag/<internalRuxitClusterID>/<InternalEnvironmentID>/<InternalApplicationID>/bs.js
http[s]://<SecurityGatewayHostname>/jstag/<internalRuxitClusterID>/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 Security Gateway. For a higher performance and if security constraints allow it, traffic can be forwarded via plain HTTP from load balancer to Security Gateway.

JavaScript code caching

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

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

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

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

Serving the JavaScript tag via CDN

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

To serve the JavaScript tag from your own CDN:

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

Update

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

Troubleshooting

To investigate problems that you may encounter with agentless Real User Monitoring, confirm the following:

  • The pages to be monitored contain the JavaScript tag.
  • The JavaScript tag is correctly downloaded by the browser (assuming you're not using inline injection). Use browser dev tools to check if the response for the JavaScript tag is 200 and the response body contains the JavaScript code.
  • The JavaScript tag is loaded from the correct location (i.e., <cdnlocation>/jstag/<tag filename>).
  • The JavaScript tag sends beacons to <beaconendpoint>/bf.
  • The response of the beacon endpoint starts with OK(BF).
  • The application in the Dynatrace web UI shows data.