Latest Dynatrace
count
metricsIn 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.
timeserieswith_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.
count
count
count
gauge
gauge
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.