Monitoring consumption calculation

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 monitoring-unit 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

For application and infrastructure monitoring provided through Dynatrace OneAgent, monitoring consumption is based on Host units.

Host units

A host unit is measured by the amount of RAM made available on the system where OneAgent is installed. 1 host unit equates to 16 GB of RAM (or any portion thereof).

Max. RAM Host units (Full-stack*) Host units (Cloud infrastructure**)
1.6 GB 0.10 0.03
4 GB 0.25 0.075
8 GB 0.50 0.15
16 GB 1 0.3
32 GB 2 0.6
48 GB 3 0.9
64 GB 4 1.0
80 GB 5 1.0
96 GB 6 1.0
112 GB 7 1.0
nx16 GB n 1.0

* 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 it's treated as a 16 GB host.
** For cloud-infrastructure monitoring mode, the same rounding principle applies, but the number of host units consumed by a host is capped at 1.

Full-stack vs. application-only

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 (e.g., 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.

Total host-unit consumption is calculated based on the sum of all host units of all modes and monitored systems.

Application-only 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.

Application-only monitoring (PaaS)

Application-only (PaaS) monitoring consumption (available for Kubernetes and OpenShift) is based on standard host-unit consumption calculations.

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.

Host unit hours calculation example

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

Free-trial host unit hours

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.

Apply host unit hours to demand spikes and select projects

(Dynatrace SaaS only) 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)

Host unit overages

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 (overage host unit hours)

Overages and multiple environments

If your account has multiple monitoring environments, e.g., 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.

Concurrency of host units

Dynatrace uses for calculation of host units true concurrency. All hosts that run at the same time in parallel are used for calculation of host units to check against the host units quota. The host units quota is checked every minute. For example, you have a host with 16 GB (which equals to 1 host unit) running from 10:00-10:30. At 10:30 you spin up another host with 1 host unit. Dynatrace would calculate 1 host units as the hosts do not run in parallel. If you start the first host at 10:00 and start another host at 10:30 and shutdown both at 11:00, then Dynatrace calculates 2 host units as both ran in parallel at the same time.

Digital Experience Monitoring

Digital Experience Monitoring (DEM) units are used to consume Dynatrace Real User Monitoring, Synthetic monitoring, and Session Replay. 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* Real User Monitoring (Session Replay disabled) 0.25 DEM
User session* Real User Monitoring (Session Replay enabled) 1.0 DEM

* Only the user sessions of real users are counted in your consumption of user sessions. The user sessions of synthetic users and "robots" aren't counted when calculating your monitoring consumption.

Real User Monitoring (RUM)

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 web application or app, except when the interaction is considered “bounced”. A session ends when a) the browser running a web application is closed or has been inactive for more than 30 minutes, b) the mobile app is closed or the client is inactive for more than 30 minutes, or c) after 60 minutes of continuous interaction with the web application or app.

If you've set up an annual RUM sessions quota, your usage will reset annually.

Synthetic actions and requests

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.

Digital Experience Monitoring overages

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.

Log Monitoring

Dynatrace SaaS - Annual average log storage (GiB)

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 - 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)

Dynatrace Managed - Annual average log storage (GiB)

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.

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 - 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)

Custom metrics

Limited custom metric ingestion and analysis is included in out-of-the-box Dynatrace technology support. To arrange for additional custom metric ingestion and analysis, contact Dynatrace Sales. For full details on setup and consumption of custom metrics within Dynatrace, see Custom metric ingestion and analysis.

Custom metrics are consumed per component and per collected dimensional value. Here are some examples:

  1. A File count metric actively collected for 2 hosts equates to 2 custom metrics.
  2. A File count metric actively collected for 5 different folders across 10 hosts equates to 50 custom metrics.
    5 * 10 = 50 (custom metrics)
  3. A File count metric actively collected for 5 different folders (with each folder representing a separate dimensional value) equates to 5 custom metrics.
    5 * 1 = 5 (custom metrics)

"Actively collected" means that at least one data point is reported for the custom metric within a sliding window of 24 hours. Custom metrics aren't factored into your consumption when no data is written to them for 24 hours or more.

Note that for Dynatrace versions earlier than 1.168, the sliding window was defined at 28 days.

Custom metrics overages

If your agreement specifies a maximum limit of 10K custom metrics ingested during any 24-hour period, and there's a risk that you'll exceed this amount during periods of peak traffic, consider setting up overages for custom metrics. With overages enabled, at peak times you can go beyond the maximum limit.

Say, for example, that you have an agreement for a limit of 100 custom metrics during any 24 hour period, you have overages enabled for custom metrics, and for the first 15 days of Dynatrace usage, your environment ingests 90 custom metrics that are reported by custom OneAgent plugins. If on day 16 your team enables a custom plugin that collects an additional 30 custom metrics (now 120 total custom metrics), you'll have 20 in custom metrics overages.
120 (actual custom metrics usage) - 100 (custom metrics limit) = 20 (custom metrics overages)

Free tier of custom metrics

Each Dynatrace environment (SaaS or Managed) comes with 100 free custom metrics. Additionally, 10 free custom metrics are provided for each of your allotted host units. For example, if you have 100 host units, you will be provided with 1,100 custom metrics.
100 + 10 * 100 = 1,100 (custom metrics)

There's a maximum free tier limit of 10,000 custom metrics.

If you have multiple Dynatrace SaaS environments under a single Dynatrace account, your free tier of custom metrics will be evenly distributed across your monitored environments.