Host monitoring (DPS)
Dynatrace offers Full-Stack Monitoring, Infrastructure Monitoring, and Mainframe Monitoring for the hosts and containers in your digital infrastructure. To switch between Full-Stack Monitoring and Infrastructure Monitoring modes, see Enable Infrastructure Monitoring Mode.
Full-Stack Monitoring
Full-Stack Monitoring 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 containers and application-only 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 your 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). Memory size calculations for containers are based on customer defined memory limits. If no memory limit is set for a container, the memory-size calculation is based on the maximum amount of memory detected within the container during monitoring.
This diagram illustrates how memory is counted for GiB-hour consumption calculations at 15-minute intervals.
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.
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 the Data Explorer, enter DPS
in the Search field. These metrics are also available via the Environment API and your Account Management portal (Usage summary > Full-Stack Monitoring > Actions > View details).
The table below shows the list of metrics you can use to monitor the consumption of Dynatrace Full-Stack Monitoring.
Metric key | Metric name | Metric dimension | Resolution | Description |
---|---|---|---|---|
builtin:billing.full_stack_monitoring.usage | (DPS) Full-Stack Monitoring billing usage | count | 15 min | Total GiB memory of all hosts monitored in Full-Stack Monitoring mode counted in 15-min intervals. |
builtin:billing.full_stack_monitoring.usage_per_host | (DPS) Full-Stack Monitoring billing usage per host | dt.entity.host[ME=HOST] | 15 min | GiB memory per host monitored in Full-Stack Monitoring mode counted in 15-min intervals. |
builtin:billing.full_stack_monitoring.metric_data_points.ingested | (DPS) Total metric data points reported by Full-Stack monitored hosts | count | 15 min | Number of reported metric data points aggregated over all Full-Stack monitored hosts. |
builtin:billing.full_stack_monitoring.metric_data_points.ingested_by_host | (DPS) Metric data points reported and split by Full-Stack monitored hosts | dt.entity.host[ME=HOST] | 15 min | Number of reported metric data points split by Full-Stack monitored hosts. |
builtin:billing.full_stack_monitoring.metric_data_points.included | (DPS) Available included metric data points for Full-Stack monitored hosts | count | 15 min | Total number of included metric data points that can be deducted from the consumed metric data points reported by Full-Stack monitored hosts. |
builtin:billing.full_stack_monitoring.metric_data_points.included_used | (DPS) Used included metric data points for Full-Stack monitored hosts | count | 15 min | Number of consumed included metric data points for Full-Stack monitored hosts. |
Monitor memory-GiB-hour consumption
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-hour consumption in 1-hour intervals. Between 11:00 and 14:00, 523 memory-GiB-hours were consumed each 1 hour. Please note that memory values are only measured in GiB hours, even when charts show "GB" as the unit of measure.
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.
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.
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.
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.
Infrastructure Monitoring
Dynatrace OneAgent can be configured for Infrastructure Monitoring mode, which provides physical and virtual infrastructure-centric monitoring, along with log monitoring and AIOps.
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.
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.
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 the Data Explorer, enter DPS
in the Search field. These metrics are also available via the Environment API and your Account Management portal (Usage summary > Infrastructure Monitoring > Actions > View details).
The table below shows the list of metrics you can use to monitor the consumption details for Infrastructure Monitoring.
Metric key | Metric name | Metric dimension | Resolution | Description |
---|---|---|---|---|
builtin:billing.infrastructure_monitoring.usage | (DPS) Infrastructure Monitoring billing usage | count | 15 min | Total number of host-hours consumed in Infrastructure-only mode |
builtin:billing.infrastructure_monitoring.usage_per_host | (DPS) Infrastructure Monitoring billing usage per host | dt.entity.host[ME=HOST] | 15 min | Consumed host-hours in Infrastructure-only mode per host |
builtin:billing.infrastructure_monitoring.metric_data_points.ingested | (DPS) Total metric data points reported by Infrastructure hosts | count | 15 min | Number of metric data points consumed by all Infrastructure monitored hosts. |
builtin:billing.infrastructure_monitoring.metric_data_points.ingested_by_host | (DPS) Metric data points reported and split by Infrastructure hosts | dt.entity.host[ME=HOST] | 15 min | Number of metric data points, split by Infrastructure hosts. |
builtin:billing.infrastructure_monitoring.metric_data_points.included | (DPS) Available included metric data points for Infrastructure hosts | count | 15 min | Total number of included metric data points deductible from the metric data points reported by all Infrastructure monitored hosts. |
builtin:billing.infrastructure_monitoring.metric_data_points.included_used | (DPS) Consumed included metric data points for Infrastructure hosts | count | 15 min | The number of consumed included metric data points for Infrastructure hosts. |
builtin:billing.custom_metrics_classic.usage.infrastructure_hosts | (DPS) Total metric data points billed for Infrastructure hosts | count | 15 min | 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 consumption aggregated in 1-hour intervals.
You can split the total host hour consumption using the metric (DPS) Infrastructure Monitoring billing usage per host. The example below shows the list of all hosts that reported consumption.
Monitor metric consumption for Infrastructure monitored hosts
Use the metric (DPS) Total metric data points billed for Infrastructure hosts to monitor the number of metric data points that are billed for Infrastructure monitored hosts, as shown in the example below.
To manage your metrics budget, you can monitor the number of available included metric data points against the number of total consumed metrics data points using these two metrics: (DPS) Available included metric data points for Infrastructure hosts and (DPS) Total metric data points reported by Infrastructure hosts. The example below shows that more metric data points were consumed that were included with these Infrastructure monitored hosts.
You can use the metric (DPS) Metric data points reported and split by Infrastructure hosts to track the number of metric data points consumed per Infrastructure monitored host. The split view helps in discovering the hosts that consume the most metric data points. The example below shows that one of the Infrastructure monitored hosts reported significantly more metrics data points than the others.
Mainframe Monitoring
Dynatrace Mainframe Monitoring provides automatic end-to-end application performance monitoring for transactions, regions, and apps deployed on IBM z/OS. It includes distributed tracing, metrics, topology, and code-level insight for 30+ supported technologies.
With the DPS capability for Mainframe Monitoring:
You get flexibility in licensing for incremental monitoring rollouts (for example, you can start small and expand coverage over time).
You only pay for the active monitoring period (for example, downtimes are not charged).
You get cost transparency and budget management via the Account Management portal.
The technical prerequisites for DPS are:
Dynatrace Cluster version 1.279+
- zRemote module version 1.265+
- zDC subsystem version 1.247+
A monitored Logical Partition (LPAR) is represented as a host in Dynatrace. The billing for monitoring an LPAR depends on the partition’s Million Service Unit (MSU) value and the duration of Dynatrace monitoring. An MSU is an IBM measurement of the amount of processing work an IBM Z mainframe can perform in one hour.
MSU hours
The unit of measure for Mainframe Monitoring is an MSU hour. Mainframe Monitoring consumption derives MSU hours based on the IBM Tailored Fit Pricing software consumption solution, retrieved per LPAR from SMF type 70 subtype 1 records (actual number of consumed MSUs).
The more MSUs an LPAR has, and the longer Dynatrace monitors it, the higher the MSU-hour consumption.
Billing granularity for MSU-hour consumption
The billing granularity for MSU-hour consumption is calculated in four 15-minute intervals per hour. If an LPAR is monitored for less than 15 minutes in an interval, MSU-hour consumption is rounded up to 15 minutes before consumption is calculated. The sum of MSU hours of all monitored LPARs represents the total consumption.
Metrics
Mainframe Monitoring includes application performance monitoring and related built-in metrics, except custom metrics, which are measured in metric data points and billed separately. For example, custom JMX metrics consume metric data points. For complete details, see Custom Metrics Classic.
Consumption details: Mainframe
Dynatrace provides a usage metric that helps you understand and analyze your MSU-hour consumption. To use this metric, in the Data explorer, enter the following metric key or name in the Search field.
Alternatively, you can query this metric via the Environment API - Metrics API v2.
Metric key | Metric name | Metric dimension | Resolution | Description |
---|---|---|---|---|
builtin:billing.mainframe_monitoring.usage | (DPS) Mainframe Monitoring billing usage | dt.entity.host[ME=HOST] | 15 min | The total number of MSU hours monitored, counted in 15 min intervals. |
You can break down the MSU-hour consumption per LPAR. The example below shows all LPARs that contributed to the consumption in 1-hour intervals within the last 24 hours.
You can also view the usage metric in your Account Management portal. In Account Management, go to Subscription > Overview > Cost and usage details > Usage summary and select the Mainframe Monitoring capability.
Consumption estimate: Mainframe
Use the IBM Sub-Capacity Reporting Tool (SCRT) report to estimate the required MSU-hour consumption per year.
- In Section C5, check the Reporting Period of the SCRT report. Typically, it contains one month of data.
- In Section N7, sum the Total MSU Consumed value for each LPAR to be monitored.
- If the reporting period is one month, multiply the Total MSU Consumed by 12 months to get annual consumption.
In this example, the three LPARs (S1LP01, S2LP02, and TF1LP1) consumed 99,000 MSU hours in September 2023.
Multiplied by 12 months, this equates to 1,188,000 MSU hours per year.
Notes:
This approach might not consider seasonal workload fluctuations, which can lead to deviations in actual consumption.
- Section N7 has been available since IBM SCRT version 25.2. It was released by IBM in December 2017.