Study guide
15.3 Choosing Visualizations: Data Explorer, Chart Types & Metric Selection
Dynatrace Certified Associate Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Overview, Deployment Models & Architecture
1.1 Dynatrace Platform Capabilities, Web UI Navigation & the Dynatrace Hub 1.2 SaaS vs. Dynatrace Managed Architecture & Security 1.3 Core Telemetry Components: OneAgent, ActiveGate & Grail Lakehouse 1.4 Licensing Models: Dynatrace Platform Subscription (DPS) & Davis Data Units (DDUs)
2 Chapter 2: ActiveGate Architecture & Network Topologies
2.1 ActiveGate Types: Environment vs. Cluster ActiveGates 2.2 ActiveGate Capabilities: Proxying, Private Synthetic, Cloud Integrations & Extensions 2.3 Network Zones, Multi-DC Routing & Firewall Traversal
3 Chapter 3: OneAgent Deployment, Configuration & Management
3.1 OneAgent Architecture, Components & Automatic Injection 3.2 Host Installation on Linux, Windows & Containerized Hosts 3.3 Cloud-Native Deployment: Dynatrace Operator on Kubernetes & OpenShift 3.4 Kubernetes Observability: Clusters, Nodes, Namespaces, Workloads & Events
4 Chapter 4: Monitoring Modes, Process Groups & Infrastructure Observability
4.1 Monitoring Modes: Full-Stack vs. Infrastructure-Only vs. Discovery 4.2 Process Groups, Process Instances & Custom Process Group Detection Rules 4.3 Host Groups, Host Naming Rules & Environmental Metadata Extraction 4.4 Infrastructure & Operations: Host Health, Disk, Network & Availability Analysis 4.5 Database Observability: The Databases App, Connection Pools & Storage Latency
5 Chapter 5: Smartscape Topology & Service Flow
5.1 The 5-Layer Smartscape Topology: Datacenter to Application 5.2 Service Detection: Web Services, Background Tasks & Custom Services 5.3 Service Flow, Backtrace Analysis & Horizontal/Vertical Dependency Mapping
6 Chapter 6: PurePath Distributed Tracing & Code-Level Diagnostics
6.1 PurePath Architecture, Distributed Tracing & Request Context Propagation 6.2 Method Hotspots, CPU Profiling & Memory Allocation Thread Analysis 6.3 Database Service Diagnostics, Slow Queries & Exception Analysis
7 Chapter 7: Davis AI Engine, Baselining & Causation
7.1 Davis Deterministic Causation Engine vs. Pure Correlation 7.2 Automated Dynamic Baselining, Percentiles & Traffic Seasonality 7.3 Event Ingestion, Event Types & Event Hierarchy in Problem Evolution
8 Chapter 8: Problem Lifecycle, Root Cause Analysis & Alerting
8.1 Problem Lifecycle, Severity Categories & Root Cause Cards 8.2 Alerting Profiles, Delay Filters & Management Zone Routing 8.3 Problem Notification Integrations: Webhooks, Slack, ServiceNow & ITSM
9 Chapter 9: Digital Experience Monitoring: Synthetic Monitoring
9.1 Synthetic Monitors: HTTP, Single-Step Browser & Multi-Step Clickpaths 9.2 Private Synthetic Locations, ActiveGate Engines & Credential Vault 9.3 Outage Detection, Performance Baselining & Maintenance Suppression
10 Chapter 10: Digital Experience Monitoring: Real User Monitoring (RUM)
10.1 RUM Architecture, OneAgent Script Injection & Mobile/OpenKit Telemetry 10.2 User Actions: Load vs. XHR/Fetch Actions, Visually Complete & Speed Index 10.3 Apdex Performance Ratings, User Sessions & Session Replay Masking
11 Chapter 11: Log Management and Analytics on Grail with DQL
11.1 Log Management on Grail: Storage, Ingestion Pipelines & Log Masking 11.2 Dynatrace Query Language (DQL): Fetch, Filter, Fields & String Operations 11.3 DQL Aggregations: Summarize, MakeTimeseries, Sorting & Visualizations
12 Chapter 12: Platform Governance, OpenTelemetry & Automation
12.1 Management Zones: Scoping Observability, Dashboards & Access Control 12.2 Tagging Strategies: Automated Rule-Based Tags, Manual Tags & AWS/K8s Metadata 12.3 OpenTelemetry Ingestion, OpenPipeline & Dynatrace Workflows Automation
13 Chapter 13: Cloud Integrations & Agentless Infrastructure Ingestion
13.1 AWS, Azure & Google Cloud Integrations 13.2 VMware vSphere, Extensions & Other Agentless Ingestion Paths
14 Chapter 14: Business Analytics & Business Events
14.1 Business Events: Capture, Ingestion & the bizevents Grail Table 14.2 Business Analytics: Connecting Performance to Revenue, Conversion & KPIs
15 Chapter 15: Notebooks, Dashboards & Data Visualization
15.1 Notebooks: Section-Based Investigation & Shareable Analysis 15.2 Dashboards: Tiles, Variables, Segments & Continuous Monitoring 15.3 Choosing Visualizations: Data Explorer, Chart Types & Metric Selection
16 Chapter 16: Reporting, Metrics & User Behavior Analysis
16.1 Metrics on Grail: Built-in Metrics, Granularity & Retention 16.2 Dashboard Reports, Subscriptions & Exporting Data via APIs 16.3 User Behavior Analysis: Bounce Rate, Landing & Exit Pages, Conversion Goals 16.4 Session Segmentation, User Journeys & Funnel Drop-Off Analysis
17 Chapter 17: Security, Vulnerability Analytics & Application Protection
17.1 Platform Security: Data Privacy, Encryption & Access Control 17.2 Third-Party Vulnerabilities, the Davis Security Score & Security Advisor 17.3 Code-Level Vulnerabilities, Attacks & Runtime Application Protection 17.4 Security Investigator, Notifications & the Remediation Workflow
15.3 Choosing Visualizations: Data Explorer, Chart Types & Metric Selection
Key Takeaways Explain This Topic AI
The Data Explorer is the metric-first exploration surface that lets you build and compare metric queries before committing them to a tile or notebook.
Chart type should follow the question: time series for trends, single value for current state against a target, bar or table for ranked comparisons, and honeycomb for many entities at once.
Percentiles, not averages, are the correct aggregation for latency, because averages conceal the tail that users actually experience.
Splitting a metric by a dimension is what turns an uninformative aggregate line into a diagnosis.
The same underlying metric data can be reached through the Data Explorer, a DQL timeseries query, a dashboard tile, or a notebook section — the choice is about workflow, not about different data.
Last updated: September 2026
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 mean = ( 9,900 × 10 ) + ( 100 × 10,000 ) 10,000 = 99,000 + 1,000,000 10,000 = 109.9 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} mean = 10 , 000 ( 9 , 900 × 10 ) + ( 100 × 10 , 000 ) = 10 , 000 99 , 000 + 1 , 000 , 000 = 109.9 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.
- Aggregation Use it for
- Average Resource utilization (CPU, memory) where the distribution is genuinely central
- Median (p50) The typical experience
- p90 / p95 The service-level target most SLOs are written against
- p99 The worst experience you still consider acceptable
- Max Capacity headroom questions — did anything ever cross the limit
- Count / Sum Throughput, error counts, revenue
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
- Question shape Visualization
- "How has this changed over time?" Time series line chart
- "What is it right now, against a target?" Single value with threshold colouring
- "Which are the worst N?" Bar chart or table , sorted
- "How is this distributed across many entities?" Honeycomb
- "What proportion of the whole?" Pie — sparingly, and never with many slices
- "What are the raw records?" Table
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.