15.3 Choosing Visualizations: Data Explorer, Chart Types & Metric Selection

Notebooks and dashboards are containers. This section is about what goes inside them: choosing the right metric, the right aggregation, and the right chart. The official learning path's call to action makes the point directly — explore metric data in a Notebook or Dashboard, then look at the same data in the Data Explorer and consider how the presentation differs.

---

The Data Explorer

The Data Explorer is the metric-first building surface. You select a metric, choose how to aggregate it, split it by dimensions, filter it, and preview the result immediately — then pin the finished query to a dashboard or carry it into a notebook.

Its value is iteration speed. Writing a DQL timeseries query is precise but slow when you do not yet know which metric key or dimension you need; the Data Explorer lets you find that out by clicking, then hands you a query you can refine.

The equivalent DQL for metric data is the timeseries command:

timeseries p90_latency = percentile(dt.service.request.response_time, 90),
  by: { dt.entity.service },
  from: now() - 6h
| sort arrayMax(p90_latency) desc
| limit 10

Same data, different workflow. Neither is "more correct" — the exam expects you to know both routes exist and that metrics are reachable in DQL alongside logs, spans, and business events.

---

Aggregation: The Percentile Rule

The single most consequential choice is aggregation, and it is heavily tested.

Consider an authentication endpoint handling 10,000 requests per minute:

• 9,900 requests are served from cache in 10 ms
• 100 requests hit a lock and take 10,000 ms

$\text{mean} = \frac{(9{,}900 \times 10) + (100 \times 10{,}000)}{10{,}000} = \frac{99{,}000 + 1{,}000{,}000}{10{,}000} = 109.9\text{ ms}$

A dashboard showing 110 ms average looks healthy. Meanwhile 100 users per minute are waiting ten seconds. The 99th percentile would read 10,000 ms and tell the truth.

The rule to carry into the exam: use percentiles for latency, averages for utilization. An answer proposing an average response time threshold is usually the distractor.

---

Splitting by Dimension

An aggregate line answers "is anything wrong?" A split answers "where?"

A service response-time chart that rises 20% overall is ambiguous. Split by geo.region and one region may have doubled while the rest are flat. Split by k8s.workload.name and a single deployment may be responsible. The mechanism is identical to the business event segmentation in Section 14.2 — the aggregate hides the finding, the split exposes it.

The cost of splitting is cardinality: splitting by a high-cardinality dimension such as user ID or trace ID produces thousands of series, which is unreadable on a chart and expensive when the metric is a custom ingested one (Section 1.4). Split by things with tens of values, not millions.

---

Matching Chart Type to Question

Two failure modes appear in exam scenarios:

• A time-series chart used for a ranking question. Fifteen overlapping lines cannot be read; a sorted bar chart or table answers "which service is slowest" in one glance.
• A single-value tile used for a trending question. A number gives no indication whether it is improving or degrading.

The honeycomb deserves specific mention because it is Dynatrace-distinctive: it renders hundreds of entities as coloured cells, so a fleet-wide health question — which of my 400 hosts are unhealthy? — is answered at a glance in a way no line chart can match.

---

Timeframe and Comparison

Every chart carries a timeframe, and the exam expects you to know that comparing against a previous period is what distinguishes a real regression from normal variation. A 40% traffic drop is alarming on its own and completely unremarkable when the same drop appears every Sunday. This is the manual counterpart to the automatic seasonal baselining Davis performs (Chapter 7): when you chart by hand, you must supply the comparison Davis would otherwise supply for you.