Troubleshooting

Latest Dynatrace

Renaming count metrics

In some circumstances custom metrics with a .count suffix have different names in Classic and Grail. While the automatic converter automatically performs the necessary correction, some exceptional scenarios require additional steps. This section helps you identify if you are one of these customers and what to do about it.

Classic metrics ingested with the count format must must be suffixed with .count (or _count) suffix.

http_requests count,delta=10

In this example, using the metric ingest protocol, http_requests is ingested with the count format. Furthermore, as it does not already have a .count suffix, Classic metrics appends the suffix after ingest.

http_requests.count:splitBy():value

Consequently, the metric can be queried as http_requests.count in Classic.

What's different in Grail?

Grail no longer distinguishes between gauge and count formats, and consequently this suffixing behavior is no longer applied at ingest. The automatic converter compensates for the suffixing behavior to create the correct DQL:

timeseries sum(http_requests)

The DQL now uses http_requests as originally specified.

What if you ingest http_requests.count? How does it appear in Grail?

http_requests.count count,delta=10

If you ingest your metric with the .count suffix, the automatic converter recognizes the correct usage:

timeseries sum(http_requests.count)

Ultimately, your Grail metric matches what you ingested.

But what if you ingest both http_requests and http_requests.count? For example, you may have setup a second server long after setting up your first server.

http_requests, host.name="My Server 2019" count,delta=5
http_requests.count, host.name="My Server 2024" count,delta=5

In these examples, two hosts are monitoring HTTP requests. Classic makes the adjustment and maps both to http_requests.count.

http_requests.count:splitBy():value

You may be querying http_requests.count and never know about the difference.

Again, your Grail metric matches what you ingested. In this example you're ingesting two different metrics, and so they must be queried as two separate metrics using DQL.

timeseries
with_suffix = sum(http_requests.count),
no_suffix = sum(http_requests)
| fieldsAdd http_requests = with_suffix[] + no_suffix[]

As a workaround, you can combine the metrics with DQL. Nevertheless, as a best practice you should align your custom metrics on a single metric key.

Ultimately there are five scenarios which can lead to a Classic suffix like .count or even .gauge. The table below lists these scenarios and what you can expect on Grail and Classic respectively.

Grail metric key
Classic metric key
Metric format
Ingested metric key
http_requests
http_requests.count
count
http_requests
http_requests_count
http_requests_count
count
http_requests_count
http_requests.count
http_requests.count
count
http_requests.count
http_requests_count
http_requests_count.gauge
gauge
http_requests_count
http_requests.count
http_requests.count.gauge
gauge
http_requests.count

Management zone conversion

Management zones are not supported on Grail, and so classic metric selector queries depending on management zones cannot be converted today. In the future, the permission management model for logs will be extended to work across Grail data sources, including metrics.