Built-in Metrics on Grail

Metrics on Grail introduces guidelines to improve clarity, consistency, and readability for Dynatrace-provided metrics, dimensions, and entities across the Dynatrace Platform:

By taking advantage of Grail's improved scalability, it's no longer necessary to split, distribute, or pre-aggregate your data. Let's illustrate with an example.

The Metrics Classic metric builtin:host.net.bytesRx represents bytes received by hosts in your environment, measured in bytes per second. It's a pre-aggregated metric based on builtin:host.net.nic.bytesRx, which measures bytes received by host-network interface pairs. Pre-aggregating the metric helps you to optimize queries and helps classic metrics distribute query load.

Consequently, the following two metric selectors return equivalent results with Metrics Classic metrics, but the query on builtin:host.net.bytesRx is faster (especially in large environments) because the host-level aggregation has already taken place.

// queries pre-aggregated host-level data
builtin:host.net.bytesRx:splitBy("dt.entity.host"):avg

// queries host- and network interface-level data
builtin:host.net.nic.bytesRx:splitBy("dt.entity.host"):avg

Grail, however, is already optimized for such high cardinality queries. Since the pre-aggregated metric builtin:host.net.bytesRx is no longer necessary, only builtin:host.net.nic.bytesRx is supported by metrics on Grail, and it can be queried as

timeseries avg(dt.host.net.nic.bytes_rx), by:{dt.entity.host}

There are three kinds of Metrics Classic extension metrics to consider:

For details, see below.

Type 1: Extension metrics with the builtin:tech prefix

Extension 1.0 metrics appear in Metrics Classic metrics with the prefix builtin:tech. These metrics appear in Grail instead with a legacy prefix. For example:

This renaming applies to all Extension 1.0 metrics with the prefix builtin:tech, except for the following:

Type 2: Extension metrics with the ext: prefix

Extension metrics with the ext: prefix are either provided by OneAgent or ActiveGate extensions, or are classic metrics for AWS integration. Regardless of the source, they behave the same way.

These can be found in Grail according to the following renaming rules:

As shown in the following examples, snake case renaming depends on the context. AWS's route53resolver and other components are proper nouns and are not renamed:

Type 3: Extension metrics with no common prefix

These have no special renaming and can be queried as is in many cases.

cloud.gcp.cloudfunctions_googleapis_com.function.active_instances:splitBy():avg

timeseries avg(cloud.gcp.cloudfunctions_googleapis_com.function.active_instances)

Extension metrics with special characters are an exception. Escape these metrics with backticks (``) to use them in DQL.

com.dynatrace.extension.snmp-generic-cisco-device.cpm.cpu.loadavg."5min":splitBy():avg

timeseries avg(`com.dynatrace.extension.snmp-generic-cisco-device.cpm.cpu.loadavg.5min`)

You can query custom metrics with both metric selectors and DQL. However, your custom metric key might have a different name in DQL queries. For example, if you ingest a count metric with the coffees.brewed key, as shown below using the metric ingest protocol

coffees.brewing count,delta=2

Dynatrace creates and stores two metrics:

You can query the Grail metric via DQL using the original metric key:

timeseries sum(coffees.brewing)

This is different from Metrics Classic, which automatically appends count metrics with the .count suffix. You still need to use the coffees.brewing.count metric key to query the Metrics Classic metric.

coffees.brewing.count:splitBy():value

While calculated service metrics are supported, other calculated metrics are not yet supported on Grail.