Dynatrace monitoring consumption is based on various types of monitoring units that are consumed by your Dynatrace environment during the monitoring of your applications and related services. Details of these monitoring unit types and how these units are consumed are outlined below.
Unless otherwise stated, the consumption details explained here apply to both SaaS and Managed deployments. To get started using Dynatrace, contact Dynatrace Sales. Your sales representative will provide you with further details.
This page is provided for informational purposes only. The terms of the Dynatrace free trial offer and/or your Dynatrace license will be applied to any use of Dynatrace products or services.
Application and infrastructure monitoring
Dynatrace application and infrastructure monitoring is provided via installation of a single Dynatrace OneAgent on each monitored host in your environment. OneAgent is licensed on a per-host basis (virtual or physical server).
However, not all hosts are of equal size. Larger hosts consume more host units than do smaller-sized hosts. We use the amount of RAM on a monitored server as a measuring stick to determine the size of a host (i.e., how many host units it comprises). The advantage of this approach is its simplicity—we don’t take technology-specific factors into consideration (for example, the number of JVMs or the number of microservices that are hosted on a server). It doesn't matter if a host is .NET-based, Java-based, or something else. You can have 10 JVMs or 1,000 JVMs; such factors don't affect the amount of monitoring that an environment consumes.
OneAgent can operate in two different modes. By default, OneAgent operates in full-stack mode. Alternatively, you can use infrastructure monitoring mode to monitor hosts that don't require full-stack visibility. Infrastructure mode consumes fewer host units than full-stack mode.
Refer to the host unit weighting table below to see how many host units are consumed based on the amount of RAM a monitored server has.
|Max. RAM||Host units (Full-stack*)||Host units (Infrastructure**)|
* When the amount of RAM on a host falls between the values listed in the table above, the number is rounded up. For example, a host with 12 GB RAM consumes 1 host unit because 12 GB falls between 8 GB and 16 GB.
** For infrastructure monitoring mode, the same rounding principle applies, but the number of host units consumed by a host is capped at 1.0. If you have an existing agreement that doesn't reflect the
1.0 cap on host units per host, please contact your Dynatrace Sales representative.
When OneAgent is integrated using Universal injection, operation of OneAgent is based on the application level (i.e, application-only monitoring). In such cases, where OneAgent isn't installed on the host level (physical or virtualized), the memory detection for host unit calculation is done per operating system instance (for example, container, Azure AppService instance, Solaris Zone) that the application runs on, with consideration of the memory limits that are set on this layer (for example, container memory limits).
If no memory limit is set, higher host-unit requirements may result as the reported available memory is typically the underlying host memory.
A Docker host with 16 GB RAM running 2 containers, monitored with application-only:
Variant-1: Without a memory limit set, 2 host units will be consumed in total as 16 GB RAM per container are reported.
Variant-2: With a memory limit set to 4 GB per container, 0.5 host units will be consumed in total as 4 GB RAM per container are reported.
Monitoring the Docker host in full-stack monitoring mode would consume 1 host unit because the memory reported from the Docker host is used for licensing (1x 16 GB RAM).
If you've arranged for an allotment of host units to monitor your hosts and you're entitled to exceed this number (i.e., overages are allowed for your account), the overages will be calculated in host unit hours. For example, if you've arranged to monitor up to 10 host units (a maximum of 160 GB total RAM) and your account allows for overages, if you connect another host that equates to 2 host units you'll have 12 host units in total and will, therefore, have exceeded your quota by 2 host units. If you continue to monitor your hosts using 12 host units for a full week, you'll accrue an overage of 336 host unit hours.
2 (host units) x 24 (hours a day) x 7 (days) = 336 (host unit hours overage)
To add or remove overages from your account, contact Dynatrace Sales.
Total host-unit consumption is calculated based on the sum of all host units of all modes and monitored systems.
Host unit hours
A host unit hour represents the consumption of a host unit over a time period. 1 host unit hour equates to 1 host unit being consumed for 1 hour. A host with 16 GB of RAM (i.e., 1 host unit) running for a full day consumes 24 host unit hours.
For example, say you have 1,000 host unit hours available and you want to monitor a host that has 64 GB RAM (which equates to 4 host units). If you keep the host running for a full day, it will consume 96 host unit hours.
4 (host units) x 24 (hours a day) = 96 (host unit hours)
The 1,000 host unit hours will be consumed in slightly more than 10 days.
4 (host units) x 24 (hours) x 10 (days) = 960 host unit hours
Each minute, Dynatrace calculates host unit consumption based on true concurrency. This means that two hosts running within the same hour will only count as 2 hosts units if both hosts run at the same time.
If a host runs for less than 5 minutes, it doesn't count against your host unit hour quota. A host running for 5 minutes or longer is rounded up to
1 host unit hour.
You have a host with 16 GB RAM (which equals 1 host unit) running from 10:00-10:30 AM. At 10:30 you spin up another host of the same size. Dynatrace considers this a single host unit because the hosts don't run concurrently.
You start the first host at 10:00 AM and launch another host at 10:30 AM. Then, both hosts run together for 30 minutes and are shut down at the same time. Dynatrace considers this to be 2 host units because both hosts run at the same time.
One host of size 16 GB RAM is started and stopped three times within an hour:
12:10 - Server start
12:20 - Server stop
12:30 - Server start
12:40 - Server stop
12:50 - Start
13:00 - Stop
Such a scenario equates to
1 host unit hour because true concurrency is taken into account.
Host unit hours are used for Dynatrace free trials. When you sign up for a Dynatrace free trial, you receive a certain number of host unit hours to evaluate Dynatrace.
If you know in advance that your base quota of host units will be exceeded due to holiday demand or a short-lived project (for example, on Black Friday or during a one-time testing initiative), you can use host unit hours rather than host units to manage variable traffic spikes. For example, if you have a pool of 9,000 host unit hours and 100 host units, during Black Friday, you'll need more hosts to scale up for the increased traffic on your site. In such a case, you have the option of using all 9,000 host unit hours in a single day. This would enable you to connect an additional 375 host units (475 total maximum) to Dynatrace for one day.
9,000 (host unit hours) / 24 (hours) + 100 (base quota of host units) = 475 (max. host units)
If your account has multiple monitoring environments, for example, one for development and the other one for production, then overages are calculated per account and not per environment. Only when the account quota is exceeded, then overages are incurred.
For example, you licensed 100 host units and you have two environments, one for production and one for testing. You assign 80 host units to the production environment and 20 host units to the testing environment. Your license entitles you for overages (you can see this in the account overview below the host units circle). If production uses 70 host units but testing uses 30 host units, the total account quota of 100 host units is not exceeded thus no overages are incurred. Only if both environments use more than 100 host units overages are incurred.
Digital Experience Monitoring
In addition to the application and infrastructure monitoring provided by OneAgent, you may also require Dynatrace Synthetic Monitoring, Real User Monitoring, and Session Replay. These capabilities are consumed based on Digital Experience Monitoring units, otherwise known as DEM Units. The amount of DEM Units you need depends on how many synthetic monitors you want to run and how many user sessions you need to monitor. The table below explains the rate at which DEM Units are consumed per each capability type and unit of measure.
|Unit of measure||Capability||Consumption per unit of measure|
|Synthetic action||Browser monitors, browser clickpaths||1.0 DEM|
|Synthetic request||HTTP monitor||0.1 DEM|
|User session per application*||Real User Monitoring (Without Session Replay playback)||0.25 DEM|
|User session per application*||Real User Monitoring session captured with Session Replay||1.0 DEM|
|Session property**||Real User Monitoring||0.01 DEM|
|Action property**||Real User Monitoring||0.01 DEM|
|Third-party synthetic result||Third-party synthetic API ingestion||0.1 DEM|
* User sessions are charged per application, even if a session spans multiple applications from the same domain. Only user sessions from real users are counted in your consumption of user sessions. User sessions from synthetic users and "robots" aren't counted when calculating your monitoring consumption.
** Data types for properties are weighed differently and affect billing, monitoring, as well as consumption. Short strings (fewer than 100 characters) and numeric (long strings, double, or dates) data types are counted as 1 property each. Long string data types are counted as 1 property per 100 characters.
A single Real User Monitoring session (i.e., a "user session") is defined as a sequence of interactions between a user with a browser-based web application or a native iOS or Android mobile app within an interval and with at least two user actions. A user action is a button click or app start that triggers a web request (for example, a page load or a page-view navigation). Interactions that include only one user action are considered “bounced” and aren't counted. A user who interacts with more than one web application or app at the same time consumes one session for each of those web applications or apps, except when the interaction is considered “bounced”.
A session ends either when (1) the browser running a web application is closed or has been inactive for more than 30 minutes, (2) when a mobile app is closed or the client is inactive for more than 30 minutes, or (3) after 60 minutes of continuous interaction with the web application or mobile app.
If you've set up an annual RUM sessions quota, your usage will reset annually.
Real User Monitoring DEM consumption example
Say, for example, that a user has been interacting with a web application or mobile app for a period 4 continuous hours. From a license perspective, a session ends after 60 minutes of continuous interaction, after which a new session is resumed for the next 60 minutes. Therefore, a 4-hour session is the equivalent of 4 licensed sessions. Without Session Replay data, this session costs
4 * 0.25 = 1 DEM Unit. With Session Replay data, the session costs
4 * 1 = 4 DEM Units.
A browser monitor or browser clickpath “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. Browser monitors perform a single synthetic interaction (for example, measuring the performance and availability of a single URL) and consume one synthetic action per execution. Clickpath monitors are sequences of pre-recorded synthetic actions. Clickpaths consume one action per each interaction that triggers a web request. Scroll downs, keystrokes, or clicks that don't trigger web requests aren't counted as actions.
An HTTP monitor consists of one or multiple HTTP(S) requests (for example, GET, POST, HEAD requests). Each request executed by an HTTP monitor equates to one synthetic request.
# Synthetic actions/requests consumed per monitor = (# Synthetic actions included in monitor) x (# Executions per hour) x (# Locations) x # Hours
XHR or Fetch requests that are made by a synthetic browser as the result of a user action like a page load, which isn't directly triggered by user input, don't result in user actions and therefore aren't counted. Such XHR and Fetch calls are considered child requests of synthetic actions.
Synthetic actions/requests calculation example
For example, a recorded browser clickpath that navigates through 2 pages and clicks 1 button that triggers an XHR or Fetch request consumes 3 synthetic actions. If such a synthetic monitor runs every 15 minutes from 2 locations for 1 day, the browser clickpath will consume 576 synthetic actions per day.
3 (synthetic actions) x 4 (monitor executions per hour) x 2 (locations) x 24 (hours per day) = 576 (synthetic actions)
For more details, see Synthetic Monitoring.
If you've arranged for Digital Experience Monitoring overages (i.e., your account allows you to exceed the maximum limit of DEM Units), the units you consume as overage are counted just as with regular DEM Unit consumption; each additional overage session or synthetic test increases the amount of DEM Units consumed by your account. To add or remove overages from your account, contact Dynatrace Sales.
You can gain more information from a session or user action by configuring additional defined properties. We currently offer a free tier of 20 defined properties per application. As shown in the table, the DEM unit cost per session increases by 0.01 DEM units for each additional defined property.
For example, 100 sessions with 25 defined properties consume
100 * (25 - 20) * 0.01 = 5 DEM units for additional defined properties. The total DEM unit cost in this case is 30 DEM units (`5 DEM units (additional defined properties) + 25 DEM units (100 sessions; 1 session = 0.25 DEM units) = 30 DEM units'.
For full details on the setup and consumption of custom metrics in Dynatrace, see Custom metrics ingestion and analysis.
How custom metrics affect monitoring consumption
Custom metrics typically consume Davis data units (DDUs). However custom metrics from OneAgent-monitored hosts are first deducted from your quota of included metrics per host unit, so they don't necessarily deduct DDUs from your quota. For complete details, see Davis data units.
Log Monitoring consumption is based on anticipated GiB of annual average log storage size, which is calculated as the average annual daily ingestion of uncompressed log data multiplied by the number of days. Once this limit is reached, you need to contact Dynatrace Sales to arrange for additional capacity.
Annual average daily log storage = Actual annual storage / (# of days)
Log storage calculation example
Say, for example, that your Log Monitoring agreement is configured for 90 days and you've arranged for 450 GiB of annual daily average storage. The anticipated average daily ingestion of log data in this case would be 5 GiB.
450 (GiB; base quota of annual average storage) / 90 (days) = 5 (GiB; anticipated average daily ingestion)
Once the annual equivalent of 1,825 GiB is ingested and exceeded, the annual average storage size of 450 GiB is also reached.
5 (GiB; anticipated average daily ingestion) x 365 (days) = 1,825 (GiB; anticipated average annual ingestion)
Continuing with the example above, if after six months your actual log ingestion is only 912.5 GiB (50% of the anticipated 1,825 GiB), then you might decide to re-configure your Log Monitoring allotment down to 45 days while leaving the annual average storage capacity unchanged at 450 GiB. In this case, the anticipated average daily ingestion of log data for the subsequent six months would be 10 GiB.
450 (GiB; average annual capacity) / 45 (days) = 10 (GiB; anticipated average daily ingestion)
Once the annual equivalent of 2,737.5 GiB is ingested, the annual average storage size of 450 GiB is also reached.
(5 x 182.5) + (10 x 182.5) = 2,737.5
If you've arranged for annual log storage capacity, your usage will reset annually (Dynatrace SaaS only).
Log Monitoring overages (optional) - SaaS deployments
If you've arranged for Log Monitoring overages so that you can exceed your agreed upon maximum limit of anticipated annual average storage size, your overages will be calculated based on the difference between your storage size limit and your actual storage size.
For example, if you have an agreed upon storage limit of 450 GiB and your actual consumption is 500 GiB, you'll have 50 GiB in overages.
500 (GiB; actual average storage size) - 450 (GiB; average storage size limit) = 50 (GiB; overages)
To add or remove overages from your account, contact Dynatrace Sales.
Log Monitoring consumption is based on anticipated GiB per day of annual average log ingestion, which is calculated as the average annual daily ingestion of uncompressed log data. Once this limit is reached, you need to contact Dynatrace Sales to arrange for additional capacity.
For example, if during an annual period the total log data sent to your Dynatrace Managed Cluster is 730 GiB, then the "per day" rate of annual average ingestion would be 2 GiB.
730 (GiB; actual annual ingestion) / 365 (days) = 2 (GiB; annual average daily ingestion)
If you've arranged for annual log storage capacity, your usage will reset annually.
Log Monitoring overages (optional) - Managed deployments
If you've arranged for Log Monitoring overages so that you can exceed your agreed upon maximum limit of daily log storage, your overages will be calculated based on the difference between your daily storage limit and your actual daily storage size.
For example, if you have an agreed upon storage limit of 10 GiB/day and your actual consumption is 12 GiB/day, you'll have 2 GiB/day in overages.
12 (GiB; actual daily log storage) - 10 (GiB; daily log storage limit) = 2 (GiB; daily overage)
To add or remove overages from your account, contact Dynatrace Sales.
Each Dynatrace environment (SaaS or Managed) comes with 5 GB of log data storage, per year at no cost to you.
Mainframe monitoring on IBM z/OS
Code modules running on IBM z/OS (CICS & IMS) are licensed separately based on MSUs and don't contribute to the consumption of host units or host unit hours.
The number of license MSUs needs to match the cumulative MSU capacity of the Dynatrace-instrumented CICS or IMS regions. Dynatrace doesn't provide a MSU consumption/metric. Therefore, consumption needs to be assessed manually via SMF records.
Premium High Availability
The Premium High Availability deployment model is licensed separately based only on the concurrent host units limit. Premium High Availability doesn't contribute to the consumption of concurrent host units or host unit hours.