Firewall constraints for RUM
Real User Monitoring (RUM) uses HTTP technologies to send performance data from your end users' browsers to Dynatrace. To do this, the RUM JavaScript is injected into your application's webpages. This tag or code snippet communicates with Dynatrace. However, you must verify the configuration of your firewalls, proxies, and web servers to allow all required data to pass through.
Starting with version 1.219, Dynatrace provides you with a call-to-action card that allows you to switch all your web applications to the new beacon format (beacon protocol version 3). The automatic migration to the new beacon protocol format happened in Dynatrace SaaS version 1.233.
All prior beacon versions reached their end-of-life with Dynatrace version 1.229. If you haven't managed to switch prior to this version, your firewall or security appliance might block beacons because of the format change. Also, if your OneAgents and RUM JavaScript versions are outdated, actions will be dropped and you won't be able to see any monitoring data for your application.
However, you don't need to take action if you set up your application with Session Replay enabled, or if you ever activated this feature for your application. In this case, you are already using the new beacon protocol.
Actions required to switch to the latest beacon format:
- Prepare your firewall or security appliance to allow the new format in case you apply filtering. The difference between the new query strings and the older ones is that the new strings now follow the proper format with an ampersand
&
as a separator instead of a semicolon;
, as was used previously. If you are still using OneAgent version 1.167 or earlier, we recommend that you update your OneAgents immediately. Otherwise, the cookies generated by OneAgent are detected as invalid.
Requests
For RUM to function fully, the following HTTP requests must be delivered to Dynatrace:
ruxitagentjs_
is the RUM JavaScript tag used for auto-injection—the name of the tag may contain additional information, such as active code modules and the version of the tag. Agentless RUM requests useruxitagent_
./rb_<id>
and/bf
or/bf_<id>
are the monitor signals the RUM JavaScript sends back to Dynatrace.- The monitor uses query parameters. For the previous beacon protocol version 2, they are
app
,flavor
,format
,referer
,session
,svrid
,type
,visitID
,size
,zip
,va
,tt
,ns
, and more. For the new beacon protocol version 3, they aretype
,svrid
,rf
,sn
,app
,dbg
,flavor
,vi
,modifiedSince
,bp
,contentType
,crc
,v
,end
, and more. - The
POST
body contains the payload. The payload is sent with thetext/plain
content type. For Session Replay, theapplication/octet-stream
content type can also be used.
- The monitor uses query parameters. For the previous beacon protocol version 2, they are
Headers
RUM uses the following HTTP headers. All of these headers must be able to reach Dynatrace.
Request headers
Header | Purpose |
---|---|
| Used for transaction stitching in HTTP headers. Set by OneAgent to link web servers. Ensure that network components, such as firewalls and routers, are never configured to remove these headers. Incorrect configuration can potentially lead to broken distributed traces. Some network components disable such requests and throw a |
| Contains the ID of the RUM application, the cookie domain, and the injection rule ( Used in case there's some proxy in between a user's browser and the original process that delivers the page. |
| Preserves the original URL of the request in case of URL rewriting. |
| Tracks the depth of a subpath tree to avoid endless distributed traces. |
| Identifies proper endpoints for beacon transmission; includes session ID for correlation. |
| Contains the referer of the page for an action and improves the correlation results. |
| Contains information for correlation of cross-origin XHRs. |
| Sets the |
| Used to track proxy scenarios by the NGINX code module. |
| Used by the Apache code module to synchronize service naming with the PHP code module. |
| Used by the IIS code module to declutter .NET code module subpaths. |
| Discarded by the Apache code module during the fine-tuning of HTML injection behavior. |
| Discarded during the fine-tuning of HTML injection behavior. |
| Discarded when caching is suppressed. |
| Discarded when caching is suppressed. |
| Modified when caching is suppressed. |
| Modified when caching is suppressed. |
| Used for W3C tagging. |
| Contains the address of the previous web page from which a link to the currently requested page was followed. |
| Used for browser and OS detection. |
| Contains the host information on non-http(s) domains. |
Response headers
Header | Purpose |
---|---|
| Confirms that the RUM JavaScript has been injected to avoid duplicate injection. Has one of the following values:
|
| Confirms that the RUM JavaScript has been injected to avoid duplicate injection. Has one of the following values:
|
| Contains the results of the RUM JavaScript injection diagnostics performed by Dynatrace Support. |
| If the RUM health check is enabled, any involved OneAgent code module adds its ID here. Set for responses to special requests. |
| Contains the fully qualified name of the injected servlet or filter. |
| Sets the session state cookie of OneAgent. |
| OneAgent appends a custom string to the original |
| If the |
| Adapted upon HTML injection. Set for responses to special requests. |
| Adapted during HTML injection into compressed responses. Set for responses to special requests. |
| Adapted during HTML injection into compressed responses. |
| Set for responses to special requests. |
| Set for responses to special requests. |
| Set for responses to special requests. |
| Used to transport information that is relevant for RUM correlation. |
| Allows the RUM JavaScript to access the information that is relevant for RUM correlation in case of cross-origin requests. |
| Set for responses to special requests. |
| Set for responses to special requests. |
| Set for responses to special requests. |
Cookies
RUM uses the following cookies. All of these must be able to reach Dynatrace. See Cookies for more information on how Dynatrace uses cookies.
Cookie | Max size | Purpose |
---|---|---|
dtCookie | No set limitation, but usually less than 100 B | Tracks a visit across multiple requests. |
dtLatC | 5 B | Measures server latency for performance monitoring. |
dtPC | 58 B | Identifies proper endpoints for beacon transmission; includes session ID for correlation. |
dtSa | Max URL length | Serves as an intermediate store for page-spanning actions. |
dtValidationCookie | Length of dTValidationCookieValue string, that is 23 | Determines the top-level domain. |
dtDisabled | 4 B | Determines if the RUM JavaScript should be deactiveted due to cost and traffic control or overload prevention. |
rxVisitor | 45 B | Contains the visitor ID to correlate sessions. |
rxvt | 27 B | Includes the timestamp of the session timeout. |
Mobile RUM
OneAgent for Mobile uses the x-dynatrace
header for tagging HTTP requests. Dynatrace uses this header to link the mobile part of the web request to the service part captured by another OneAgent.
For hybrid applications, the dtAdk
cookie allows to join a session from OneAgent for Mobile and a session from the RUM JavaScript so that these sessions appear as a single session, while the dtAdkSettings
cookie is used for syncing settings between OneAgent for Mobile and the RUM JavaScript.
/mbeacon
is the monitor signal that OneAgent for Mobile sends back to Dynatrace if the data is transferred through ActiveGate. If the data is sent to another OneAgent, the monitor signal is /dtmb
.