Dynatrace captures a lot of end-user data from monitored environments. Based on your license type and configuration, Dynatrace can capture both real-user traffic (user actions, captured directly in end-user browsers) and service-side traffic (web requests and other communications that may include sensitive data).
This page provides information about what sensitive data types Dynatrace collects (and why) for both Dynatrace Real User Monitoring (RUM) server-side service monitoring. Here you'll also find information about how sensitive end-user data can be protected, including options for capturing such data by default or excluding it from capture.
Dynatrace Real User Monitoring (RUM)
Purpose of Dynatrace RUM
What data are captured when using Dynatrace RUM?
Dynatrace captures the user experience for every end-user interaction with the application (e.g. button clicks, page loads, etc.), which triggers server side web requests. These interactions are called “user actions”. By default user actions are named after the triggered web request URL, but it can be changed in order to name every user action after the control that was clicked (e.g. “Click on Login”). For each user action, Dynatrace captures timings as well as the URLs of all web requests that were sent to backend services and the URLs of all assets on a view like images, css and js files.
Dynatrace combines all subsequent user actions into a session which allows to understand how the user was navigating through the application. Along with a session Dynatrace also stores a masked IP address to allow performance analysis based on geographical regions. Dynatrace processes the full IP address but masks it before doing geo lookups or storing it in a database.
Dynatrace can detect recurring users by storing a randomly generated id in the browser or on the device. By default this user tracking feature is not enabled.
In addition to the above mentioned features that are available out-of-the box, it is possible to report additional Strings to tag user actions and sessions for deeper analytics use-cases. Such tags may include a user name or other sensitive data. No such tags are configured by default.
Service request monitoring
What is the purpose of Service request monitoring
Dynatrace helps you to improve the performance of your applications, it also enables you to analyze problems that occur in production in timely manner. This is done via the Dynatrace OneAgent
What data is captured when using Dynatrace OneAgent?
Dynatrace captures the most important data points of incoming requests and specifically web requests from end-users in your application. These are called service requests. By default service requests are named after the triggered web request URL, but but it can be changed in order to name them according to their business meaning (see [request naming rules]).
For this purpose Dynatrace capture the URL, the client ip and certain HTTP header fields automatically.
In addition to the above mentioned features that are available out-of-the box, it is possible to report additional data to categorize request via [request attributes], to allow deeper analysis and enhance the capability of [request naming rules]. This is configurable by the user.
What is the purpose of Log Analytics
With Dynatrace Log Analytics, you gain direct access to the log content of all your system's mission-critical processes. It's easy to search for specific log messages that you're interested in. Log content can be filtered based on keywords or time frame. You can even analyze multiple log files simultaneously—even when log files are stored across multiple hosts.
Most significantly, Dynatrace artificial intelligence automatically correlates relevant log messages with any problems that it detects in your environment. Relevant log messages that are associated with problems are then factored into problem root-cause analysis.
What data are captured when using Log Analytics?
Log Analytics enables you to store all logs centrally within external storage. This makes log data available independent of log files themselves. This can be beneficial in the following situations:
- Short log-retention periods
- Volatile log storage
- Legal requirements for keeping logs archived centrally for long time periods
For Dynatrace SaaS customers, log files are stored in Amazon Elastic File System encrpted volume in the zone where your Dynatrace environment resides. Your log data can contain information that may be considered sensitive. Specific log messages may include user names, email addresses, URL parameters, and other information that you may not want to disclose. Log Analytics features the ability to mask any information by modifying the configuration file on each of the OneAgents that handles information you consider to be sensitive.
Dynatrace UI usage monitoring
What is the purpose of Dynatrace UI usage monitoring
Remark: This section does not apply to end-users but only to As such this only applies to employees and partners of Dynatrace customers that are working on the Dynatrace User Interface.
Dynatrace uses Woopra, a customer analytics provider, headquartered in San Francisco, United States, to analyze the usage of our website as well as our Dynatrace SaaS and Managed offering. This enables us to improve our products and services, thus providing users of Dynatrace with a better experience.
What data is captured when you use the Dynatrace UI
How does Dynatrace protect sensitive data
Depending on your environment setup and data-privacy settings, some captured data may be protected by law or considered sensitive for other reasons. In such instances, you must take extra precautions to protect your customers' private data.
Dynatrace has 3 levels of protection in place concerning sensitive data.
- Scrubbing of data at the point of capture: In this case the data in question will not leave the monitored process or the customers browser.
- Scrubbing of data prior to storage: In this case the data in question is being processed by Dynatrace to allow better analysis, but the original data is scrubbed prior to storage. Scrubbed data portions are replaced with “
- Masking of data on display: In this case the data is being stored but only presented to users with the View sensitive request data permission. All other users will see that the data point exists but the sensitive data is masked out by “*****“.
Protect sensitive data by never capturing it
Dynatrace automatically masks certain data points already at the point of capture. This happens within the application or browser and never leaves it. Masked values are replaced by “***“.
- Literals and Numbers that are part of the where clause of an SQL statement
- Bind parameters of an SQL statement
- URL Query parameters in exception messages
Protect sensitive data by never storing it
If your organization captures personal user data from customers that fall under the GDPR compliance you should go to Settings > Preferences > Data privacy to turn on data masking. This page contains several configuration flags that allow to enable proper masking of captured data.
Masking of IP Addresses and GPS coordinates
Dynatrace captures IP addresses of end users to determine the region from where they access your application.
Once enabled, IP address masking sets the last octet of monitored IPv4 addresses and the last 80 bits of IPv6 addresses to zeroes. GPS coordinates will be rounded up to to 1 decimal place (~10km). This masking occurs on the Dynatrace cluster prior to storage. Full IP addresses are never written to disk. Location lookups will be made with the anonymized IP addresses and GPS coordinates.
Masking of personal data in URLs
Dynatrace captures the full URIs of requests sent from browsers, mobile device and those sent and received in monitored server side processes.
Once enabled, Dynatrace will
- automatically detect UUIDs, IP addresses and other IDs in the URL path and replace these parts with the string “
- replace the query parameter values with the string “
Masking of user action names (Web applications only)
When Dynatrace detects a user action that triggers a page load or an AJAX/XHR action, it constructs a name for the user action based on:
- User event type (‘click on...’, ‘loading of page...’, or ‘key press on...’)
- Title, caption, label, value, ID, className or other available property of the related HTML element (for example, image, button, checkbox, or text input field).
In most instances, the default approach to user action naming works well, resulting in user action names such as:
- click on “Search” on page /search.html
- keypress on “Feedback” on page /contact.html
- touch on “Homescreen” of page /list.jsf
In rare circumstances however confidential data (for example, email addresses, usernames, or account numbers) are unintentionally included in user action names because the confidential data is included in HTML element labels, attributes, or values (for example, click on “my Account Number: 1231231”...). If such confidential data appears in your application’s user action names, turn on User action name masking below. This setting replaces specific HTML element names and values with generic HTML element names. With user action name masking enabled, the user action names listed above would change to:
- click on INPUT on page /search.html
- keypress on TEXTAREA on page /contact.html
- touch on DIV of page /list.jsf
Protect sensitive data by not displaying it
Dynatrace automatically considers certain data points it captures as sensitive and will only display them to users with the View sensitive request data permission. All other users will see that the data point exists but the sensitive data is masked out by “*****“. Thus the data is protected to be viewed from unauthorized personal.
Sensitive data types
The following data types are considered sensitive and masks them on display
- Requests attributes that are marked as confidential.
- Client IP addresses
- Exception messages
- URL query parameters
- HTTP Headers
- HTTP Post parameters
- Original captured method argument values (the resulting request attribute is treated separately)
Mark request attributes as confidential
Dynatrace allows you to decide whether a request attribute should be treated as confidential or not. For this and other obvious reasons users that define request attributes need to have the Configure capture of sensitive data permission
To mark a request attribute as confidential
- Go to Settings > Server-side service monitoring > Request attributes.
- Click the Edit button of the relevant request attribute.
- Select the Request attribute contains confidential data option box.
View sensitive data
Users with the View sensitive request data permission can view masked data.
Sensitive data summary
The following data gives an overview about data being captured by Dynatrace that may contain sensitive data:
- May contain PII data: Whether PII data may be captured intentionally or accidentially by capturing this type of data.
- Configurable capture: Whether this data can configured to be not captured at all.
- Captured by default: Will this data by default (i.e. applying the default configuration) be captured or not.
- Masked by default: Is this data masked by default if captured.
- Masking on display: If data is captured, is it masked on display?
- Masking on storage: If data is captured and masking configured, is it masked on storage?
- Masking on capture If data is captured and masking configured, is it masked on capture?
|Product feature||Data being captured||May contain PII data||Configurable capture||Captured by default||Masked by default||Masking on display||Masking on storage||Masking on capture||Comment|
|Real User||User clicks||yes||no||yes||yes||no||configurable||future|
|Real User||IP and Location||yes||no||yes||yes||no||configurable||future|
|Server side requests||URL||yes||no||yes||no||no||configurable||future|
|Server side requests||URL Query parameter||yes||yes||yes||yes||yes||configurable||future||³|
|Server side requests||Client IP||yes||no||yes||yes||yes||configurable||future|
|Server side requests||HTTP request/response header||yes||yes||only some||no||yes||configurable||future||¹|
|Server side requests||HTTP post parameter||yes||yes||no||no||yes||configurable||future||²|
|Server side requests||Exception messages||yes||yes||yes||no||yes||no||yes|
|Server side requests||Method arguments/return values||yes||yes||no||no||yes||future||no||²|
|Server side requests||SQL literals and bind variables||yes||no||no||yes||no||future||yes|
- only certain headers are captured automatically, all others are only captured when requested by user - see request attributes. The ones that are captured are not masked by default
- all values are captured when requested by user - see request attributes
- Query parameters are always confidential (masking on view) and can be masked at storage as well. They can be explicitly captured by request attributes in which case their confidentiality depends on the request attribute configuration