Host monitoring (DPS)

Host monitoring consumption varies depending on which OneAgent monitoring mode is in use.

Dynatrace OneAgent offers Full-Stack Monitoring, Infrastructure Monitoring, and Foundation & Discovery modes for the hosts and containers in your digital infrastructure. To learn more about the OneAgent monitoring modes, see Infrastructure and Discovery monitoring modes.
For Kubernetes clusters, Dynatrace offers Kubernetes Monitoring.
Dynatrace provides a dedicated DPS model for Mainframe Monitoring.

Full-Stack Monitoring

Full-Stack Monitoring mode offers comprehensive application performance monitoring, including distributed tracing, code-level visibility, CPU profiling, memory profiling, and deep process monitoring. That is true for hosts and containers. For hosts, all Infrastructure Monitoring functionality is included with Dynatrace Full-Stack Monitoring. A host is defined as a single physical or virtual server or cloud instance running an operating system, whereas a container is defined as an isolated space on a host or any cloud infrastructure for running individual application processes.

A full-stack monitored host has OneAgent installed in Full-Stack Monitoring mode, actively sending data to Dynatrace. Billing of full-stack monitored hosts (whether run in the cloud or on-premises) depends on a host's memory size and the duration a host was monitored by OneAgent.

GiB-hours

Dynatrace uses GiB-hours (referred to as "memory-gibibyte-hours" in your rate card) as the unit of measure for calculating your organization's consumption of host monitoring in Full-Stack Monitoring mode. The more memory that a host has, and the longer that the host is monitored, the higher the number of GiB-hours that the host consumes.

The advantage of the GiB-hour approach to monitoring consumption is its simplicity and transparency. Technology-specific factors (for example, the number of JVMs or the number of microservices hosted on a server) don't affect consumption. It doesn't matter if a host runs .NET-based applications, Java-based applications, or something else. You can have 10 or 1,000 JVMs; such factors don't affect an environment's monitoring consumption.

Billing granularity for GiB-hour consumption

Dynatrace is built for dynamic cloud-native environments where hosts and services are rapidly spun up and destroyed. Therefore, billing granularity for GiB-hour consumption is calculated in four 15-minute intervals per hour. When a host or container is monitored for fewer than 15 minutes in an interval, GiB-hour consumption is rounded up to 15 minutes before consumption is calculated.

GiB-hour calculation for physical hosts and virtual machines (VMs)

Each installed instance of Dynatrace OneAgent running on an operating system instance (deployed on either K8s, a container platform, or a physical or virtual machine) in Full-Stack Monitoring mode consumes GiB-hours based on the monitored host's physical or virtual RAM, calculated in 15-minute intervals (see the diagram example below).

The RAM of each VM or host is rounded to the next multiple of 0.25 GiB (which equates to 256 MiB) before monitoring consumption is calculated. A 4 GiB minimum is applied to GiB-hour consumption for physical and virtual hosts. For example, a host with 8.3 GiB memory is counted as an 8.5 GiB host, being the next multiple of 0.25 GiB, while a host with 2 GiB memory is counted as a 4 GiB host (no rounding needed, but application of the 4 GiB minimum).

GiB-hour calculation for application-only container monitoring

In cloud-native environments, services and hosts are often short-lived. Therefore calculating monitoring consumption in 15-minute time intervals, rather than full hours, better reflects actual usage. Containers, which are an essential mechanism in cloud-native environments, are typically smaller in memory size than hosts. Therefore, the minimum memory threshold for containers is 256 MiB, rather than 4 GiB, the minimum memory threshold for hosts.

The same rounding as for hosts, to the next multiple of 0.25 GiB, also applies to containers. For example, a container with 780 MiB memory is counted as a 1 GiB container (780 MiB, which equals 0.76 GiB, being rounded up to the next multiple of 0.25 GiB).

The diagram below illustrates how memory is counted for GiB-hour consumption calculations at 15-minute intervals.

Full-Stack consumption

Figure 1. GiB-hour consumption for hosts and containers is based on memory size, calculated in 15-minute intervals each hour. Each interval is divided by 4 in order to reach the GiB-hour consumption unit of measure.

Used memory logic

Memory-size calculations for containers monitored in an application-only approach are based on each container's used memory.

Memory-size calculations based on a container's used memory require OneAgent version 1.275+ (for Kubernetes containers) or OneAgent version 1.283+ (for other serverless containers).

Older OneAgent versions use the customer-defined memory limit. If no memory limit is set, the memory of the underlying virtual machine is used instead.

Exceptions

For Azure App Services running on the App Service (Dedicated) plan for Windows, instances are counted as hosts and the defined memory of all instances is aggregated to determine total memory—regardless of how many applications run on those instances.
For Azure App Service on Linux and Azure App Service for Linux Containers with OneAgent version 1.283+, memory consumption is calculated using the memory of each plan instance. In these cases, there is no ability to set container resource limits.
Solaris Zones are counted as hosts.
Monitored containers that are not detected as containers are counted as hosts.

Metrics

Full-Stack Monitoring includes all Infrastructure Monitoring metrics, application performance monitoring metrics, and other built-in metrics. In addition, Full-Stack Monitoring includes a fixed number of custom metric data points for each GiB that contributes to your environment's GiB-hour consumption. As of April 26, 2023, Dynatrace offers 900 included custom metric data points for each GiB of host memory, calculated at 15-minute intervals.

Your environment's included metric data points are applied automatically to metrics that originate at hosts and containers that are monitored by OneAgent in Full-Stack Monitoring mode. You will only be billed for consumed metric data points if you exceed your included volume of metric data points.

Included metric datapoints that are not consumed within the 15-minute interval in which they are granted do not roll over to subsequent intervals.

Included metric data point calculation example

Considering the example shown in Figure 1, here are the calculations for the included metric data point volumes for each of the four 15-minute intervals, assuming a volume of 900 included metric data points for each 15-minute interval.

First 15-minute interval
900 (included metric data points) × 13.5 (GiB memory) = 12,150 included metric data points

Second 15-minute interval
900 (included metric data points) × 9.5 (GiB memory) = 8,550 included metric data points

Third 15-minute interval
900 (included metric data points) × 8.75 (GiB memory) = 7,875 included metric data points

Fourth 15-minute interval
900 (included metric data points) × 0.25 (GiB memory) = 225 included metric-data-points

How metric data points are consumed in Full-Stack Monitoring mode

Metric data-point consumption takes many forms. An equal number of data points can be consumed:

By a few high-resolution metrics or numerous low-resolution metrics.
Equally across multiple 15-minute intervals or all at once in a single minute.
By all monitored hosts, a subset of all Full-Stack monitored hosts, or a single host.

Additional metric data points that your environment consumes (beyond those data points that are included with each GiB of memory that contributes to your consumed GiB-hours) are billed as Custom Metrics Classic.

Distributed traces

Full-Stack Monitoring includes Dynatrace PurePath® distributed tracing. OneAgent automatically manages the volume of captured trace data. For details, see Adaptive Traffic Management documentation. The peak trace volume available in an environment at any time depends on how many GiB of memory contribute to your GiB-hour consumption. Every contributing GiB of host memory adds peak trace volume of 45 KiB/min. Each environment has a minimum trace peak volume of 14 MiB/min.. This trace volume is available for all traces sent by OneAgent code modules or via OneAgent Trace API.

Taking the hosts shown in Figure 1 as an example, the peak trace volume for each minute equals the environment minimum (14 MiB/min). For the calculation of trace data volume in this next example, we'll apply a multiplier (100) to host memory size to generate a more realistic scenario. This assumes there are 100 times more GiB contributing within each 15-minute interval.

Peak trace volume/minute calculation example

First 15-minute interval
45 KiB (peak trace volume) × 13.5 (GiB memory) × 100 (example multiplier) = 59.32 MiB/min

Second 15-minute interval
45 KiB (peak trace volume) × 9.5 (GiB memory) × 100 (example multiplier) = 41.75 MiB/min

Third 15-minute interval
45 KiB (peak trace volume) × 8.75 (GiB memory) × 100 (example multiplier) = 38.45 MiB/min

Fourth 15-minute interval
45 KiB (peak trace volume) × 0.25 (GiB memory) × 100 (example multiplier) = 14.00 MiB/min (the minimum trace volume)

Note that traces sent via the Custom Trace API are billed as Custom Traces Classic.

Dynatrace retains the total amount of ingested trace volume from your environment for ten days, with index-level access for 35 days. For an average host with 16 GiB memory, this translates to 10 GiB of retained trace volume (45 Kib per GiB/min × 16 GiB memory × 60 min × 24h × 10 days / 1024 / 1024).

CPU, memory, and thread profiling

Full-Stack Monitoring includes CPU, memory, and thread profiling for technologies like Java, .NET, Go, Node.js, and PHP. OneAgent uses an intelligent patented mechanism to manage the volume of profiling data. Dynatrace retains the total amount of ingested profiling data from your environment for ten days.

Consumption details: Full-Stack

Dynatrace provides built-in usage metrics that help you understand and analyze your organization's consumption of Full-Stack Monitoring. To use these metrics, in Data Explorer, enter DPS in the Search field. These metrics are also available via the Environment API and in Account Management (Usage summary > Full-Stack Monitoring > Actions > View details).

Here are the metrics you can use to monitor the consumption of Dynatrace Full-Stack Monitoring.

(DPS) Full-Stack Monitoring billing usage

Key: builtin:billing.full_stack_monitoring.usage

Dimension: count

Resolution: 15 min

Description: Total GiB memory of all hosts monitored in Full-Stack Monitoring mode counted in 15-min intervals.

(DPS) Full-Stack Monitoring billing usage per host

Key: builtin:billing.full_stack_monitoring.usage_per_host

Dimension: Host (dt.entity.host)

Resolution: 15 min

Description: GiB memory per host monitored in Full-Stack Monitoring mode counted in 15-min intervals.

(DPS) Full-stack usage by container type

Key: builtin:billing.full_stack_monitoring.usage_per_container

Dimension: application_only_type; k8s.cluster.uid; k8s.namespace.name

Resolution: 15 min

Description: GiB memory per container monitored in Full-Stack application-only Monitoring mode counted in 15-min intervals.

(DPS) Total metric data points reported by Full-Stack monitored hosts

Key: builtin:billing.full_stack_monitoring.metric_data_points.ingested

Dimension: Count

Resolution: 15 min

Description: Number of reported metric data points aggregated over all Full-Stack monitored hosts.

(DPS) Metric data points reported and split by Full-Stack monitored hosts

Key: builtin:billing.full_stack_monitoring.metric_data_points.ingested_by_host

Dimension: Host (dt.entity.host)

Resolution: 15 min

Description: Number of reported metric data points split by Full-Stack monitored hosts.

(DPS) Available included metric data points for Full-Stack monitored hosts

Key: builtin:billing.full_stack_monitoring.metric_data_points.included

Dimension: Count

Resolution: 15 min

Description: Total number of included metric data points that can be deducted from the consumed metric data points reported by Full-Stack monitored hosts.

(DPS) Used included metric data points for Full-Stack monitored hosts

Key: builtin:billing.full_stack_monitoring.metric_data_points.included_used

Dimension: Count

Resolution: 15 min

Description: Number of consumed included metric data points for Full-Stack monitored hosts.

Monitor memory-GiB-hour consumption for Full-Stack monitored hosts

You can monitor the total memory-GiB-hour consumption aggregated across all Full-Stack monitored hosts for different intervals (15 min, hour, day, or week) for any selected timeframe using the (DPS) Full-Stack Monitoring billing usage metric. The example below shows memory GiB monitored in 1-hour intervals. Between 11:00 and 14:00, 523 memory-GiB were monitored each 1 hour. This results in 523 memory-GiB-hours consumed.

Full-Stack Monitoring (DPS)

You can break down the total memory-GiB-hour consumption using the (DPS) Full-Stack Monitoring billing usage per host metric. The example below shows the list of all hosts that contributed to the 523 memory-GiB-hour consumption between 13:00 and 14:00. The respective number of memory-GiB-hours per host is displayed as well.

Full-Stack Monitoring (DPS)

Monitor memory-GiB-hour consumption for Full-Stack monitored containers

Platform and cluster owners can monitor their Kubernetes clusters using Kubernetes Monitoring. Application owners can leverage Full-Stack Monitoring in application-only mode to monitor applications running within Kubernetes clusters.

To get consumption insights for monitored Kubernetes clusters or namespaces, you can query memory-GiB-hour consumption by leveraging the (DPS) Full-Stack Monitoring billing usage per container metric, as shown in the following query:

builtin:billing.full_stack_monitoring.usage_per_container:filter(eq("application_only_type","kubernetes")):splitBy()

In the example below, 1.58 TiB of memory was consumed by the Kubernetes cluster within the past 30 days.

Kubernetes monitoring

Of course, you can filter your analysis for deeper insights (for example, add a split for Kubernetes namespaces).

Kubernetes monitoring

Monitor metric consumption for Full-Stack monitored hosts

To monitor your metrics budget for the whole pool of metric data points in your environment, you can track available included metric data points against total reported metrics data points using these two metrics: (DPS) Available included metric data points for Full-Stack monitored hosts and (DPS) Total metric data points reported by Full-Stack monitored hosts. The example below shows data for a full day. At no time was the number of included metrics for this environment's metric pool (purple line) overspent.

Full-Stack Monitoring (DPS)

In cases where the number of included metrics for an environment's metric pool are overspent, the following analysis can help you to identify the hosts that are contributing to the overspending. Use the metric (DPS) Metric data points reported and split by Full-Stack monitored hosts for this analysis.

The example below shows that between 10:45 and 11:00, each of the first 3 hosts in the list reported far more than 2,000 metric data points. In the same period, each of these 3 hosts shows a memory-GiB-hour consumption of 2 GiB. Dynatrace offers 900 included custom metric data points for each GiB of host memory, calculated at 15-minute intervals. This means that the first 3 hosts contribute 1,800 (2*900) metric data points to the environment's pool of available data points. However these hosts consumed more data points than they contributed during the same time period.

Full-Stack Monitoring (DPS)

When using the metric (DPS) Total metric data points billed for Full-Stack monitored hosts from Custom Metrics Classic you can see that no overspending occurred for this environment's Full-Stack Monitoring metric pool between 10:45 and 11:00 because no metric data points were billed.

Full-Stack Monitoring (DPS)

Infrastructure Monitoring

Dynatrace OneAgent can be configured for Infrastructure Monitoring mode, which provides comprehensive host monitoring for physical and virtual hosts.

In addition to all features of Foundation & Discovery, Infrastructure Monitoring also includes detailed process performance metrics, disk performance metrics, process-to-process network analysis, and per process memory analysis. Dynatrace Extensions can be enabled on hosts with Infrastructure Monitoring mode and may consume custom metric data points and Log Management and Analytics.

Host hours

The unit of measure for calculating consumption of host monitoring in Infrastructure Monitoring mode is a host-hour. Each instance of Dynatrace OneAgent installed and running on an operating system instance (deployed on either a physical or virtual machine) with Infrastructure Monitoring mode enabled consumes host hours. The longer that a host is monitored, the more host-hours you consume. Consumption is independent from a host's memory size.

Billing granularity for host-hour consumption

Dynatrace is built for elastic cloud-native environments where hosts and services are rapidly spun up and destroyed. Therefore, billing granularity for host-hour consumption is based on 15-minute intervals. When a host is monitored for fewer than 15 minutes in an interval, host-hour consumption is rounded up to 15 minutes before consumption is calculated.

Figure 2 below illustrates how host-hour consumption per host is calculated.

Infrastructure Monitoring consumption

Figure 2. Host hour consumption per host, calculated at 15-minute intervals.

Metrics

Dynatrace Infrastructure Monitoring includes important built-in metrics. In addition to built-in metrics, Infrastructure monitoring includes a fixed number of custom metrics data points (we currently offer 1,500) for each 15-minute interval of monitoring per host. This equates to 100 custom metrics data points per minute at no additional cost. This "included" data point volume is available for all Infrastructure-monitored hosts in your environment. It applies only to metrics that originate at hosts that are monitored by OneAgent in Infrastructure Monitoring mode.

Looking at Figure 2 above, the included custom metric data point volume for the four 15-minute intervals is shown below.

Included custom metric data points calculation example

First 15-minute interval
1 (hosts monitored) × 1,500 (metric data points) = 1,500 Included custom metric data points

Second 15-minute interval
2 (hosts monitored) × 1,500 (metric data points) = 3,000 Included custom metric data points

Third 15-minute interval
1 (hosts monitored) × 1,500 (metric data points) = 1,500 Included custom metric data points

Fourth 15-minute interval
1 (hosts monitored) × 1,500 (metric data points) = 1,500 Included custom metric data points

How custom metric data points are consumed in Infrastructure Monitoring mode

Custom metric data-point consumption takes many forms. An equal number of custom metric data points can be consumed:

By a few high-resolution metrics or numerous low-resolution metrics.
Equally across multiple 15-minute intervals or all at once in a single minute.
By all Infrastructure-monitored hosts, a subset of all Infrastructure-monitored hosts, or a single infrastructure-monitored host.

Additional custom metric data points that your environment consumes (beyond those data points that are included with each Infrastructure-monitored host) are billed as Custom Metrics Classic.

Consumption details: Infrastructure

Dynatrace provides built-in usage metrics that help you understand and analyze your organization's consumption of Infrastructure Monitoring. To use these metrics, in Data Explorer, enter DPS in the Search field. These metrics are also available via the Environment API and in Account Management (Usage summary > Infrastructure Monitoring > Actions > View details).

Here is the list of metrics you can use to monitor the consumption details for Infrastructure Monitoring.

(DPS) Infrastructure Monitoring billing usage

Key: builtin:billing.infrastructure_monitoring.usage

Dimension: Count

Resolution: 15 min

Description: Total number of host hours consumed in Infrastructure Monitoring mode.

(DPS) Infrastructure Monitoring billing usage per host

Key: builtin:billing.infrastructure_monitoring.usage_per_host

Dimension: Host (dt.entity.host)

Resolution: 15 min

Description: Consumed host hours in Infrastructure Monitoring mode per host.

(DPS) Total metric data points reported by Infrastructure hosts

Key: builtin:billing.infrastructure_monitoring.metric_data_points.ingested

Dimension: Count

Resolution: 15 min

Description: Number of metric data points consumed by all Infrastructure-monitored hosts.

(DPS) Metric data points reported and split by Infrastructure hosts

Key: builtin:billing.infrastructure_monitoring.metric_data_points.ingested_by_host

Dimension: Host (dt.entity.host)

Resolution: 15 min

Description: Number of metric data points, split by Infrastructure-monitored hosts.

(DPS) Available included metric data points for Infrastructure-monitored hosts

Key: builtin:billing.infrastructure_monitoring.metric_data_points.included

Dimension: Count

Resolution: 15 min

Description: Total number of included metric data points deductible from the metric data points reported by all Infrastructure-monitored hosts.

(DPS) Consumed included metric data points for Infrastructure hosts

Key: builtin:billing.infrastructure_monitoring.metric_data_points.included_used

Dimension: Count

Resolution: 15 min

Description: Number of consumed included metric data points for Infrastructure-monitored hosts.

(DPS) Total metric data points billed for Infrastructure hosts

Key: builtin:billing.custom_metrics_classic.usage.infrastructure_hosts

Dimension: Count

Resolution: 15 min

Description: Number of metric data points billed for all Infrastructure-monitored hosts.

Monitor host-hour consumption

You can monitor the total host-hour consumption for different intervals (15 min, hour, day, or week) for any selected timeframe using the (DPS) Infrastructure Monitoring billing usage metric. The example below shows that 5 hosts were monitored, leading to total consumption of 5 host-hours for each hour.