Dynatrace DEM provides availability and performance monitoring to help ensure that your applications and services are available, functional, fast, and efficient across all channels, including mobile, web, IoT, and APIs.
Dynatrace RUM is a performance monitoring process that collects detailed data about each user's interactions with your application, whether it be a browser-based application or a mobile app deployed on Android or iOS. Real User Monitoring collects data on a variety of metrics. For example, data collected on load actions can include navigation start, request start, and speed index metrics.
The unit of measure for calculating your organization's consumption of RUM (web and mobile) is sessions per application per hour, excluding replay capture. A user action is a mouse-click, finger tap, or app start that triggers a web request (for example, a page load or a page-view navigation). A user who interacts with more than one web application or app during the same session consumes one session per hour for each application. For sessions that last longer than one hour, one session is consumed per hour.
For complete details on when RUM user sessions start and end, see User session timings. RUM session consumption is not capped.
Sessions that include only one user action are considered "bounced" and aren't counted. A user who interacts with more than one application at the same time consumes one session for each of those applications.
Interactions with hybrid mobile apps, that for technical reasons include a web application and a mobile app, will only be considered as a single session.
For details about the respective monitoring-consumption metrics, see Built-in Real User Monitoring metrics.
Session Replay helps capture and visually replay the complete digital experience of your end users. User interactions with your application are recorded and can be replayed in a movie-like experience. Session Replay makes it easy to reproduce production issues and errors, and to understand problems such as malformed pages and infinite spinners.
When Session Replay is activated for a given RUM session, the unit of measure is one session per application (web and mobile) per hour with Session Replay activated (also referred to as "Session Replay Capture" in your rate card). Depending on the session, you are billed for a RUM session or a RUM session with Session Replay, but not both. If a session is longer than one hour, the session is counted multiple times (once per hour).
For details about the respective monitoring-consumption metrics, see Built-in Real User Monitoring metrics.
Dynatrace captures extensive performance information about your applications. This information can be enriched with valuable metadata and converted into user action and user session properties. These properties enable powerful queries, segmentation, and aggregations on the captured metadata.
Any RUM property can be configured for an application. Dynatrace measures the consumption of RUM properties using defined properties within individual user sessions. Up to 20 properties per application are included in the volume. Any additional properties will be charged according to the total number of individual user sessions that use this property.
((# billable properties) - (20 included properties)) * (# individual user sessions) = Consumption
For details about the respective monitoring-consumption metrics, see Built-in Real User Monitoring metrics.
A browser monitor simulates a user visiting your application using a modern, updated web browser to monitor your application's business-critical workflows. Browser monitors can be configured to run from any Dynatrace public or private locations at frequencies of up to every five minutes and sends alerts when the application becomes inaccessible or when performance degrades significantly. In addition, they can be used to check the availability of internal resources that are inaccessible from outside your network.
The Dynatrace recorder is used to capture an exact sequence of clicks and user inputs, availability, and performance. Alternatively, a defined sequence can be scripted to accomplish the same goal.
The unit of measure for browser monitors is a synthetic action. A synthetic action is an interaction with a synthetic browser that triggers a web request that includes a page load, navigation event, or action that triggers an XHR or Fetch request performed during private and public executions of Synthetic Browser Monitors.
The following interactions are not counted:
A synthetic action is charged as soon as the action is made, no matter if it is successful or fails. If an action fails and therefore subsequent actions are not executed, these subsequent actions are not charged.
The following calculation gives you an estimate of the maximum possible consumption, assuming that all Synthetic actions were executed. Actual consumption may vary depending on if some actions failed subsequent actions were not executed.
# Synthetic actions consumed per monitor = (# Synthetic actions included in monitor) × (# Executions per hour) × (# Locations) × # Hours
For details about the respective monitoring-consumption metrics, see Built-in Real User Monitoring metrics.
The third-party endpoints of the Synthetic API enable the pushing of third-party synthetic data and events to Dynatrace. The API also facilitates adjustments of results which were previously pushed to Dynatrace.
The unit of measure is a third-party synthetic result where the number of test results ingested with Third-Party Synthetic API are added together.
For details about the respective monitoring-consumption metrics, see Built-in Real User Monitoring metrics.
Synthetic HTTP monitors can be created to check the availability of resources—websites or API endpoints.
In addition, they can be used to check the availability of internal resources that are inaccessible from outside your network.
An HTTP monitor consists of one or multiple HTTP(S) requests (for example, GET, POST, and HEAD requests).
The unit of measure for HTTP monitors is a synthetic request. Each HTTP(S) request consumes one synthetic request.
A synthetic request is charged as soon as the request is made, no matter if it is successful or fails. If a request fails and therefore subsequent requests are not executed, these subsequent requests are not charged.
The following calculation gives you an estimate of the maximum possible consumption, assuming that all Synthetic requests were executed. Actual consumption may vary depending on if some requests failed subsequent requests were not executed.
# Synthetic requests consumed per monitor = (# Synthetic requests included in monitor) × (# Executions per hour) × (# Locations) × # Hours
For details about the respective monitoring consumption metrics, see Built-in Real User Monitoring metrics.
Network availability monitoring (NAM) monitors don't have a separate line on the Dynatrace rate card. Instead, you're billed based on the number of metric data points generated during each execution of a NAM test. For more information, please contact your Dynatrace account manager.
The following details apply to metric data points: