16.1 Metrics on Grail: Built-in Metrics, Granularity & Retention

Reporting and Analysis is its own scored line on the Dynatrace Associate exam score report, and it is broader than it sounds: it covers metrics, dashboard reports, data export through APIs, user behaviour analysis, and session segmentation. This chapter covers all four. We start with metrics, because every report is ultimately built on them.

---

Where Metrics Come From

Dynatrace metrics arrive from four places:

1. Automatically from OneAgent — host CPU, memory, disk, network; process metrics; service response time, failure rate, and throughput. Nothing is configured.
2. From cloud integrations and extensions — CloudWatch, Azure Monitor, SNMP, JMX, Prometheus (Chapter 13).
3. Calculated — metrics derived from request attributes, logs, or business events.
4. Custom-ingested — pushed via the metric ingest API, metered at 0.001 DDU per data point (Section 1.4).

The first category is the one to emphasize on the exam: a very large fraction of what a candidate might assume needs configuration is produced automatically by OneAgent.

---

Granularity and Retention — The Numbers That Get Tested

Retention is where exam questions become concrete, because different data types keep data for very different periods.

Metrics Classic downsamples on a published schedule, and the tiers are worth memorizing because scenarios are built directly on them:

Two consequences follow, and both appear as scenarios:

1. Long-range questions must be answered with metrics. "Show me how host memory utilization has trended over the past two years" is answerable from Metrics Classic history — at day granularity — but is not answerable from sessions or traces, which are long gone. A question offering "query the user sessions from eighteen months ago" is testing this.

2. Granularity coarsens with age. The 5-year figure for Metrics Classic does not mean five years of minute-by-minute detail. By the time data is a year old it is stored at a coarse interval suitable for trend analysis, not for incident forensics. Answers claiming "detailed per-minute data for five years" overstate what is retained.

Grail Metrics and Metrics Classic Differ by More Than Retention

The practical reading: a question that asks for minute-level detail two years back is answerable only on Metrics powered by Grail with an extended bucket retention. Metrics Classic still holds two-year-old data, but by then it is stored at one point per day.

---

Reading Metrics with DQL

Grail metrics are queried with the timeseries command, which returns a series rather than a record list:

timeseries mem = avg(dt.host.memory.usage),
  by: { dt.entity.host },
  from: now() - 30d,
  interval: 1h

Compare that to fetch, which returns records (logs, spans, business events). Knowing which command applies to which data type is a reasonable exam expectation: timeseries for metrics, fetch for records.

Metrics can also be created from records. A DQL query over logs or business events can be converted into a metric so that it becomes chartable, alertable, and long-lived — which is how a business KPI (Chapter 14) becomes something Davis can baseline.

---

Metric Semantics

Dynatrace metric keys follow a semantic dictionary — a governed naming convention such as dt.host.cpu.usage or dt.service.request.response_time. Two practical consequences:

• Built-in metric keys are stable and portable. A dashboard built on dt.host.cpu.usage works in any tenant.
• Custom metrics should follow the same convention. Ad-hoc names such as myteam_cpu_thing make estate-wide queries impossible.
• The dt. prefix is reserved. Grail reserves dt. for Dynatrace-controlled metrics and fields. Metric data ingested under a dt. key is dropped, and dimensions ingested with a dt. prefix are ignored. Custom metrics imitate the dotted namespace style — acme.checkout.orders.count — but never borrow the prefix itself.

Metrics also carry dimensions — the labels you split and filter by (host, service, region, endpoint). Dimensions are what make a metric analytically useful and simultaneously what drives its cost, since each unique dimension combination is a separate series.

Cardinality and the One-Minute Bucket

Two ingest rules decide what a dimension choice actually costs:

• Cardinality limits are enforced, and enforcement means rejection. Metrics Classic caps each metric at 1 million dimension tuples, evaluated over a 30-day sliding window. Once the cap is reached, data points carrying new, previously unseen tuples are simply rejected — the metric does not fail loudly, it just stops accepting new series. The classic self-inflicted wound is a dimension that changes on every write: a measured_at epoch timestamp, which merely duplicates information the data point already carries, reaches a million tuples in roughly 11 days.
• A series is billed at most once per minute. Measurements arriving faster than once a minute are aggregated into fixed one-minute buckets, so no time series is billed for more than one data point per minute. At 0.001 DDU per data point, that sets a ceiling of 525.6 DDUs per series per year (Section 1.4) however aggressively an exporter pushes.

The planning corollary is worth stating plainly: metric cost is driven by cardinality, not by scrape frequency. Doubling the push rate above one-per-minute changes nothing, while adding one dimension with a thousand distinct values multiplies the series count by a thousand.

---

Choosing the Right Data Type for a Reporting Question

Work it from the retention and shape of the question:

The recurring exam trap is proposing a metric for a question that needs a record — metrics cannot tell you which customer or what message, only how many and how fast.