Application and Infrastructure Monitoring (Host Units)
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 (that is 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 Monitoring 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.
Host units
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. Total host-unit consumption is calculated based on the sum of all host units of all modes and monitored systems. For details about the host unit quota split, see Quotas and overages.
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 GiB RAM consumes 1 host unit because 12 GiB falls between 8 GiB and 16 GiB.
For Infrastructure Monitoring mode, the same rounding principle applies. If a host unit cap is enabled for your Cloud Infrastructure license, 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), not the host level. Such cases occur when you don’t have access to the underlying server or host, whether physical or virtual, and therefore can't install OneAgent directly on the hosts. Examples include, but are not limited to, AWS Fargate (serverless containers), Red Hat OpenShift Container Platform (PaaS), Pivotal Web Services (PaaS), and Solaris Zone.
For these technologies, host units are calculated based on memory detected at the operating system instance or container level using Full-Stack host-unit value weighting. Calculations take into account the detected memory limit, such as container memory limits. If no memory limits are detected, calculations may use the underlying host memory, which may reflect a higher number of host units.
- For Azure App Services running on the App Service (Dedicated) plan for Windows, host unit consumption is calculated upon the number and memory of the plans instances, regardless of how many applications run on the instances.
- For Azure App Service on Linux and Azure App Service for Linux Containers, host unit consumption is calculated upon the memory of a plans instance by the number of running containers, due to lack of ability to set container ressource limits.
Examples
- 4 Serverless containers run concurrently for 1 hour. Each container has a memory limit of 1 GiB RAM.
4 hosts × 0.1 host unit weighting = 0.4 host units - 2 Docker containers run on a host that has 16 GiB RAM for 1 hour in application-only monitoring mode. Without a memory limit detected, the containers will consume 2 host units in total as 16 GiB RAM per container will be detected.
2 hosts × 1.0 host unit weighting = 2 host units - An Azure premium v2 App Service plan containing 16 GiB of memory and running 4 App Services on Windows scaled out on 2 instances will consume
2 instances × 1.0 host unit weighting = 2 host units. - An Azure App Service Premium Plan V2 containing 16 GiB of memory and running 8 containers consumes 8 host units.
8 containers × 16 GiB memory = 8 host units.
Host unit overages (optional)
If you've arranged for an allotment of host units to monitor your hosts and you're entitled to exceed this number (that is 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 GiB 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) × 24 (hours a day) × 7 (days) = 336 (host unit hours overage)
To add or remove overages from your account, contact Dynatrace Sales.
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 GiB of RAM (that is 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 GiB 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) × 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) × 24 (hours) × 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 consume two hosts units if both hosts run at the same time. Host-unit hours are counted in calendar hours (for example, 10:00 – 11:00 AM) and not usage hours (for example, 10:23 – 11:23 AM).
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.
When the monitoring of a host stops for any reason, that host's consumed host units are released and made available to another host within about five minutes.
Example 1
You have a host with 16 GiB 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.
Example 2
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.
Example 3
One host of size 16 GiB 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.
Example 4
You have a host with 16 GiB RAM (which equals 1 host unit) running from 10:23-11:23 AM. Since the host is running for 2 calendar hours (10:00 – 11:00 AM and 11:00 – 12:00 AM), it equates to 2 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.
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.
Distributed traces
Full-Stack Monitoring includes Dynatrace PurePath® distributed tracing. OneAgent automatically manages the included volume of captured trace data via Adaptive traffic management (ATM). For details, see Adaptive Traffic Management documentation.
The included peak trace volume available in an environment at any time depends on the active host units in that environment. Depending on your ATM version every host unit either adds 250 full-service calls/minute (v2) or 720 KiB/min (v3) to the peak trace volume. Switching between ATM versions is possible. For details, see How can I change from Adaptive traffic management with Classic License v2 to v3?.
Serverless monitoring
Cloud services that are monitored using cloud vendor integrations such as Amazon CloudWatch, Azure Monitor or Google Cloud Operations, consume custom metrics. For details, see DDUs for custom metrics.
Dynatrace allows for the ingestion of log files from your serverless cloud services, which consumes Davis data units. For details, see DDUs for log files.
Serverless compute services
Dynatrace OneAgent integrations for serverless compute services consume host units.
Example serverless compute services
Serverless functions
Tracing integrations for serverless functions such as AWS Lambda, Azure Functions, and Google Functions, operate on a consumption model (for example, billed based on used memory and CPU consumption) and consume Davis data units. For details, see DDUs for serverless monitoring.
Mainframe monitoring on IBM z/OS
Monitoring of the CICS, IMS, and z/OS Java code modules that run on IBM z/OS are consumed based on million service units (MSUs). Therefore, mainframe monitoring doesn't contribute to the consumption of host units or host unit hours.
An MSU is an IBM measurement of the amount of processing workload an IBM Z mainframe can perform per hour. The amount of consumed MSUs in sub-capacity licensing is calculated based on peak rolling 4-hour average MSU values of the most recent month from IBM system management facility data per monitored logical partition (LPAR) or subsystem.
The peak rolling 4-hour average MSU values per monitored LPAR can be derived from Dynatrace or section N5 of the sub-capacity reporting tool (SCRT) report. The peak rolling 4-hour average MSU values per subsystem can be derived from section P5 of the SCRT report.
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.