Latest Dynatrace
This guide explains how to upgrade your existing calculated service metrics to Grail.
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.
Most existing metrics are upgraded automatically to Grail, where they can be leveraged in the new Dashboards or
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.
remainder
dimension. The remainder filter condition allowing you to filter on this remainder
dimension.Not auto-upgraded:
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 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.
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 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.
On the Calculated service metrics page, you can see which metrics are already written to Grail and which are not.
To enable or disable classic calculated service metrics on Grail
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. For details, refer to Calculated service metrics.
To open a calculated service metric in Notebooks
The 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.
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. 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)}
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