Calculated service metrics upgrade guide

Latest Dynatrace

This guide explains how to upgrade your existing calculated service metrics to Grail.

Creating new calculated service metrics

When creating new calculated service metrics, we recommend using OpenPipeline, which uses metric extraction from span data to provide more flexibility and control.

You can continue using the existing classic calculated service metrics functionality if needed, but OpenPipeline will eventually become the default method for creating calculated service metrics. At that point, the current calculated service metrics functionality will be deprecated. Currently, no deprecation date is set.

What's in the scope of the upgrade?

Most existing metrics are upgraded automatically to Grail, where they can be leveraged in the new Dashboards Dashboards or Notebooks Notebooks, or analyzed in apps such as the Services app.

Metrics created using the classic calculated service metrics feature remain accessible via Dashboards Classic and the classic Multidimensional analysis.

Some metrics are not auto-upgraded but can be upgraded manually by using a toggle on the Calculated service metrics page to enable or disable the metric being sent to Grail. For details, see Set metric to enabled or disabled on Grail.

There are also some metrics that are not eligible for upgrade. These can be recreated in OpenPipeline or, if long-term historical analysis is not required, in Notebooks.

To determine if a metric can be upgraded, its cardinality—the number of distinct dimensions created by a metric—is taken into account. It is checked over the last two weeks in 5-minute windows, which means any distinct dimension created within those 5 minutes is counted. The resulting sum is the cardinality of that window. The cardinality that is used is the maximum value of all windows. This happens on a per-service basis if the calculated service metric is written for more than one service.

The following applies if you have enabled Split by dimension for the chosen metric. Any metric without this feature will be automatically upgraded. For details on dimensions for calculated service metrics, refer to Calculated service metrics.

  • Auto-upgraded: If the calculated service metric's cardinality is less than the value defined in the "top X" value and less than 500 within any 5-minute window in the past two weeks, and the metric has existed for longer than two weeks, it is auto-upgraded.

    • Only new data is written to calculated metrics; retrospective data is not included.
    • You can have up to 500 enabled calculated metrics per environment and up to 100 enabled calculated metrics per service.
    • Classic calculated metrics support at most 100 dimension values. This is referred to as the "top X" rule, as you can select fewer depending on your configuration. However you choose the top 100 dimension values, the remaining dimensions are aggregated into a single timeseries and the dimension value is accessible through a special remainder dimension. The remainder filter condition allowing you to filter on this remainder dimension.
    • Grail calculated service metrics with cardinality higher than 2000 within any 5-minute window in the past 2 weeks or since the last metric change are automatically disabled in Grail. Enabling such metrics on Grail is not allowed. If the metric is already enabled on Grail, you are informed of the metric rejection via the Metric & Dimensions Usage + Rejections ready-made dashboard. To enable a Classic metric on Grail and keep collecting incoming data on Grail, make sure cardinality stays below the limit.

  • Not auto-upgraded:

    • If the metric's cardinality exceeds the value defined in the "top X" value, the upgrade has to be triggered manually. This upgrade is not automatic because Grail offers enhanced precision and stores the metric's full dimension cardinality, not just the "top X" values. This is a powerful capability, but without a "top X" limit, it may increase the stored metric data points and license consumption compared to the classic metric.
    • If the metric's cardinality is above 500, the upgrade also has to be triggered manually. The upgrade is not automatic because many high-cardinality metrics are used for one-off reporting without the need for a long-term historical analysis. With Notebooks Notebooks, you can use DQL to recreate those metrics as useful and effective reports.

  • Not eligible for upgrade: Metrics with cardinality exceeding 2,000 can't be upgraded. In such cases, the upgrade button is not active, and an information message is displayed. You can recreate the metric using OpenPipeline to extract metrics from span data or use DQL in Notebooks Notebooks for one-off reports without long-term historical analysis. Alternatively, you can edit the definition of your classic calculated service metric to reduce its cardinality to below 2,000, resulting in fewer data points.

    Find the cardinality of a metric

    For metrics that are not automatically upgraded, Dynatrace displays the current cardinality of the classic metric in the warning box of the calculated service metric.

    You can also find the cardinality by running the following expression in the Data Explorer Data Explorer app.

    dsfm:server.metrics.calculated_metrics.number_of_values:filter(eq(metric_key, "calc:service.<your_metric_key>")):splitBy(metric_key):max

    Replace <your_metric_key> with the key of your calculated service metric to retrieve its cardinality.

How to upgrade manually?

On the Calculated service metrics page, you can see which metrics are already written to Grail and which are not.

Set which calculated service metrics will be enabled on Grail

To enable or disable classic calculated service metrics on Grail

  1. Go to Settings Classic > Server-side service monitoring > Calculated service metrics.
  2. Choose the calculated service metric you want to configure.
  3. optional Select to open the metric's details and edit its settings, and then select Save metric.
  4. Toggle the option to enable or disable the metric being sent to Grail.
  5. Select Save changes.

What happens after the upgrade?

All calculated service metrics that are enabled on Grail get a corresponding Grail metric key service.xxx. The metric key of the classic metric remains unchanged. The upgraded metrics get new dimensions that make them more powerful and easier to use in Dashboards Dashboards. For details, refer to Calculated service metrics.

Explore a calculated service metric in Notebooks/DQL

To open a calculated service metric in Notebooks Notebooks

  1. Go to Settings Classic > Server-side service monitoring > Calculated service metrics.
  2. Choose the calculated service metric from the list and select Open with.
  3. Select Notebooks.
  4. In Select destination, choose a notebook and then select Confirm.

The Notebooks Notebooks app opens with the calculated service metric data displayed. You can choose how to visualize the data from the options. For details, refer to Notebooks.

Some calculated service metrics may need manual adjustments to display correctly. For details, refer to section Differences between Grail and Classic metrics.

Differences between Grail and Classic metrics

For the metrics below, the recommended approach is to go to the metric's details, select Open with, and choose to open the metric in Notebooks Notebooks. This way, the necessary adjustments are automatically applied and a DQL query is provided that can be used as a basis for other queries or dashboards.

  • Failure rate metrics: In Grail, these metrics count the number of failed and successful requests by using an additional Boolean dimension "failed" (true or false). The failure rate needs to be calculated using DQL.

    For example, here is a DQL query for the AEM content failure rate metric. It calculates the percentage of failed requests by dividing the number of failed requests per minute by the total number of requests per minute.

    timeseries {
      failedNum = sum(service.aemcontentfailurerate, default: 0.0, filter: failed == true),
      totalNum = sum(service.aemcontentfailurerate)
    },
    by: { dt.entity.service }, union:true
    | fieldsAdd failure_rate = (failedNum[] / totalNum[]) * 100
    | fieldsRemove totalNum, failedNum

  • Request count metrics: Classic metrics used a datatype that combined a counter with a rolling average functionality. This data type does not exist in Grail. To chart a rolling average in Grail correctly requires an additional DQL parameter.

    timeseries {
      avg(service.wkndrequestcount, rollup: sum)
    }

Handling calculated service metrics than can't be upgraded

The following DQL query returns the top 10 URLs with most failed attempts on wallet-services if a payment is involved. Payments are indicated by the request attribute PaidAmount. The high cardinality is due to URL splitting.

fetch spans


// filter for "failed requests"
| filter isNotNull(endpoint.name) and request.is_failed == true


// conditions on service display name and request attribute
| filter contains(entityName(dt.entity.service), "wallet-service")
| filter exists(request_attribute.PaidAmount)


// count requests and split by service and url
| makeTimeseries failed_request_count=count(), by: { dt.entity.service, url.full }


// only show top 10 timeseries
| sort arraySum(failed_request_count) desc | limit 10

Licensing considerations

  • Calculated service metrics continue to consume your license like custom metrics—there are no changes with the upgrade.
  • You are not billed twice. When a calculated service metric is upgraded to Grail, you're only billed for the classic or the Grail metric, not both, even if the metric is available in both versions.