Calculate your consumption of Mainframe Monitoring (DPS)

  • Latest Dynatrace
  • Explanation
  • 1-min read

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 in Account Management.
  • The usage of Distributed Tracing Distributed Tracing and Services Services is included with Dynatrace. No query consumption is generated by these apps.

The technical prerequisites for DPS are:

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.

Distributed tracing

Included and extended Trace retention

Dynatrace retains the total amount of ingested trace volume from your environment for 10 days.

Dynatrace provides the ability to extend trace retention on a selective basis for up to 10 years. This is achieved by creating custom buckets in Grail. The first 10 days of retention are always included. Any trace data retained longer than 10 days is charged on a per-Gibibyte basis as Trace Retain.

Metrics

Mainframe Monitoring includes application performance monitoring and related built-in metrics, except custom metrics, which are measured in metric data points and charged as Metrics powered by Grail. For example, custom JMX metrics consume metric data points.

How are metrics charged in DPS prior to Metrics powered by Grail

If Metrics powered by Grail does not exist on your rate card, metric data points are charged as 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 Data Explorer 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.

(DPS) Mainframe Monitoring billing usage

Key: builtin:billing.mainframe_monitoring.usage

Dimension: Host (dt.entity.host)

Resolution: 15 min

Description: 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.

DPS Mainframe Monitoring billing metric

You can also view the usage metric in Account Management. Go to Account Management > Subscription > Overview > Cost and usage details > Usage summary and select the Mainframe Monitoring capability.

MSU Usage Summary

Consumption estimate: Mainframe

Use the IBM Sub-Capacity Reporting Tool (SCRT) report to estimate the required MSU-hour consumption per year.

  1. In Section C5, check the Reporting Period of the SCRT report. Typically, it contains one month of data.
  2. In Section N7, sum the Total MSU Consumed value for each LPAR to be monitored.
  3. If the reporting period is one month, multiply the Total MSU Consumed by 12 months to get annual consumption.

SCRT report example

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.

Network availability monitoring (NAM) monitors don't have a separate line on the Dynatrace rate card. Instead, you're billed based on the number of metric data points generated during each execution of a NAM test. For more information, please contact your Dynatrace account manager.

Metric data point calculations

The following details apply to metric data points:

  • Metric data points related to monitor and step execution are non-billable.
  • Only the consumption of metrics produced at the request level affects your billing.
  • Each request execution within ping tests generates 6 metric data points.
    • The number of packets used in a ping test does not impact the number of metrics produced or your billing.
    • The number of packets does not affect the price.
  • Each request execution within TCP/DNS tests generates 3 metric data points.
  • The price stays the same regardless of whether you create several tests containing a single request, or you create one test with numerous requests for the same set of hosts or devices.
Related tags
Dynatrace PlatformInfrastructure Observability