Define applications for Real User Monitoring

After OneAgent is installed on a host, it monitors all applications running on that host. As a starting point, all monitoring data is encapsulated in a placeholder application called My web application. The reason we offer this placeholder application is to allow for more flexibility, as we leave it up to you how your application should be organized. To do so, Dynatrace provides you with the following options:

Option Injection type When to use
Automated approach Auto-injection When your web applications can be easily identified based on domains and you want to create an application from already captured RUM traffic.
Application detection rules Auto-injection When you want to create new applications or when dividing your traffic based on top domains isn't sufficient. Use application detection rules to define more complex patterns for your applications.
Manual approach (aka "agentless monitoring") Manual insertion When you don't have access to the host of your web application but you have access to the application code.
Browser extension approach Browser extension injection When you don't have access to either the host of your web application or the application code

Note that you can also choose the injection format for both auto-injected and manually inserted applications. For details, see RUM injection and available injection formats.

Define an application using the automated approach

The My web application placeholder RUM application aggregates the traffic from all detected Top domains. This application can serve as your starting point for mapping the identified domains to the separate applications in your environment.

  1. Select Applications from the navigation menu.
  2. Select the My web application placeholder application.
  3. Scroll down to find the Top 3 included domains panel. This panel shows the domains that contain the largest number of user actions that were automatically detected by OneAgent in your environment.
  4. Select View full details.
  5. Expand a domain entry in the Top domains list by selecting the arrow button in the Transfer domain column.
  6. Select Create new application. Your application will be created and listed on the Applications page. From now on, all user actions that are monitored on this domain will be mapped to this newly created application. (Alternatively, you can add the domain to an existing application by selecting Transfer.)

As you may want a more intuitive name for your application, you can replace the auto-generated name with a custom application name of your choosing.
To rename an application

  1. Select Applications from the left-hand menu.
  2. Select your newly created application to access the application's overview page.
  3. Select the Browse button (...) and choose Edit.
  4. Type in the name you prefer in the text box at the top of the page. Note that application names must be unique.

Define an application using application detection rules

If you want to create more applications, change existing application mappings, or if you need to define more complex rules looking at URLs and not only on domains, you can use the Application detection & RUM settings page.

  1. From the navigation menu, select Settings > Web and mobile monitoring > Application detection settings and RUM.
  2. In the Application detection rules section you can see the list of defined rules. For each application defined using the automated approach, a detection rule is automatically generated and added to the end of the list. Rules are applied sequentially, with rules at the top of the list taking priority over rules listed further down.
  3. Select Create application detection rule. Use the options offered on this page to create the appropriate detection rule for your application.

Define an application using an alternative approach

In cases where you don't have access to your web server and therefore can't install OneAgent on the host, you have two options:

Best practices and recommendations

  • Define your applications based on team ownership so you can easily make use of management zones for access restrictions.

  • It may make sense to define applications based on their technology stack so that the right settings are applied and the management of specific settings is easier. For example, activating support for specific XHR frameworks is typically required only for specific parts of a large application and for specific user action naming rules. It may help to separate such large applications into smaller applications based on the technologies in use or team ownership.

  • Avoid renaming the My web application placeholder application as it includes all user actions on all domains that are not included in an application rule. If you rename "My web application", it may be difficult to distinguish it from your other applications.

  • Separating applications based on top-level domains works best as Dynatrace cannot correlate user actions across top level domains with specific user sessions. This correlation is done via a cookie and therefore only works if the cookie can be set on the same top level domain. For example, user actions for www.dynatrace.com and blog.dynatrace.com can be captured in a single application as the cookie can be set to dynatrace.com, however traffic for www.dynatrace.com and www.internal-dynatrace.com cannot be captured in a single user session. You can still separate user actions based on the domain, but user sessions cannot include user actions from multiple domains.

  • Low traffic applications should be grouped together. If you create an application based on a domain that has less than 10 actions per minute, Dynatrace won't automatically detect anomalies for this newly created application. Dynatrace depends on steady application traffic to correctly learn multidimensional baselines and to automatically report application problems. Your current anomaly detection settings can be changed in the anomaly detection settings for applications. Although this recommendation contradicts with the one mentioned above, for low traffic applications, it may make sense to combine them.

  • The application rules are processed in sequence for each request. More rules means more processing time and as the rules are processed within the OneAgents, you should try to have the rules for the most used applications that have the most traffic at the top of the list. As soon as one rule matches, no further requests are processed.

  • The more specific application detection rules should be defined first, while the more generic rules should be at the bottom of the list. Let's assume that you want to create an application called "A" onto which the following two domains will be mapped:

    http://www.mydomain.com/cms/directory/shop/index.html
    http://shop.differentdomain.de/index.html

    and another application "B" for the following domain:

    http://newdomain.co.uk/hello/shop.html

    If you create a generic grouping rule based on the shop value, all three domains will be grouped into the same web application for monitoring. Therefore, you should first define a more specific rule, for example "If the URL ends with shop.html" so that only the third URL is mapped to application "B". Then you can safely define a generic rule based on the shop value, as the third URL will have already been mapped to the previous application and therefore won't be included in application "A".

  • Depending on your requirements, you can adjust the monitoring consumption and configure Real User Monitoring accordingly. To monitor traffic on a single application, you can opt to use user actions and session properties. To monitor separate applications and get complete insights into consumption per application, you can configure separate applications, use tagging to split the metrics, and define management zones.