Study guide
11.3 DQL Aggregations: Summarize, MakeTimeseries, Sorting & Visualizations
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
11.3 DQL Aggregations: Summarize, MakeTimeseries, Sorting & Visualizations
Key Takeaways Explain This Topic AI
The summarize command aggregates discrete records across one or more dimensions into tabular summary statistics, serving as the core engine for operational metrics and categorical group-by analytics.
The makeTimeseries command aggregates discrete events into continuous, equidistant time-series buckets, outputting native time-series data structures required for line charts, area charts, and alerting.
High-performance statistical aggregation functions in DQL include count(), countIf(), sum(), avg(), min(), max(), median(), percentile(), collectDistinct(), and collectArray().
The default: parameter in makeTimeseries prevents visualization gaps and mathematical errors across sparse data intervals by defining explicit fallback values such as default: 0.
DQL query outputs map directly to Dynatrace Dashboards and Notebooks visualizations, translating tabular summarize outputs into tables, bar charts, and stat tiles, and makeTimeseries outputs into line and area charts.
Last updated: September 2026
While filtering and parsing individual log records is essential for ad-hoc debugging, enterprise observability demands high-level statistical aggregation and continuous trend analysis. Site reliability engineers and operations teams must answer questions such as: Which microservices are producing the highest volume of errors? What is the 95th percentile request latency across API gateways? How has the error rate evolved hour-over-hour following the latest Kubernetes canary deployment?
Dynatrace Query Language (DQL) provides two fundamental aggregation commands to synthesize millions of granular log events into actionable analytical insights:
summarize : Aggregates records into a collapsed tabular summary across grouping dimensions (analogous to SQL GROUP BY ).
makeTimeseries : Aggregates records into a continuous time-series dataset segmented into fixed time buckets (such as 1 minute or 5 minutes), generating the native temporal data structure required for line charts, stacked area charts, and dynamic alerting.
Understanding the mathematical functions, dimensional grouping mechanics, sparse data handling, and visual tile mappings of these commands is essential for the Dynatrace Certified Associate examination.
1. Tabular Grouping & Statistical Aggregations: The summarize Command
The summarize command collapses multiple incoming records into single summary rows based on one or more grouping dimensions declared in the by: { ... } clause.
- General Syntax fetch logs
- | filter status in ("ERROR", "WARN")
- | summarize <alias> = <aggregation_function>(<expression>), by: { <field1>, <field2> }
- Core Aggregation Functions
DQL offers a rich suite of statistical and set aggregation functions:
- Function Category Function Syntax Description Example Usage
- Counting count() Counts total matching records in the group total_logs = count()
Conditional Counting countIf(<boolean>) Counts records only if condition evaluates to true error_count = countIf(status == "ERROR")
- Arithmetic Sum sum(<numeric>) Calculates the total sum of a numeric field bytes_served = sum(response_bytes)
- Arithmetic Mean avg(<numeric>) Computes the average value avg_latency = avg(duration_ms)
- Extrema min(<val>) , max(<val>) Identifies minimum and maximum values slowest_req = max(duration_ms)
Percentiles percentile(<numeric>, <p>) Calculates the p-th percentile value (e.g., P50, P95, P99) p95_latency = percentile(duration_ms, 95)
Median median(<numeric>) Computes the 50th percentile (median) median_dur = median(duration_ms)
Distinct Values collectDistinct(<field>) Returns a deduplicated array/set of unique values active_users = collectDistinct(user_id)
Distinct Count countDistinct(<field>) Returns the total count of distinct values unique_ips = countDistinct(client_ip)
Array Collection collectArray(<field>) Collects all values (including duplicates) into an array error_codes = collectArray(http_code)
Multi-Dimensional Grouping Example
In the following query, DQL groups application errors simultaneously by host name and service name, computing total errors, unique users affected, and the 99th percentile request duration: fetch logs
- | filter status == "ERROR"
- | parse content, "LD 'duration=' DOUBLE:duration_ms ' user=' WORD:user_id"
- | summarize total_errors = count(),
- affected_users = countDistinct(user_id),
- p99_duration = percentile(duration_ms, 99),
- by: { host.name, dt.entity.service }
- | sort total_errors desc
- 2. Continuous Time-Series Generation: The makeTimeseries Command
A common misconception among engineers learning DQL is attempting to build line charts by grouping a summarize query with a binned timestamp (e.g., summarize count(), by: { bin(timestamp, 5m) } ). While this produces a table with timestamp columns, it does not create a true time series.
The Need for makeTimeseries
In a distributed computing environment, event streams are naturally sparse. During off-peak periods (such as 3:00 AM), a critical microservice may emit zero error logs for several consecutive intervals. A standard summarize query simply omits those zero-count intervals, resulting in missing rows. When fed into a charting visualizer, these missing rows produce broken, fragmented line segments or misaligned comparative metrics.
The makeTimeseries command solves this by enforcing an equidistant temporal grid spanning the entire query window. It guarantees that every single time bucket exists in the output array, automatically bridging inactive periods. fetch logs
- | filter status == "ERROR"
- | makeTimeseries error_rate = count(), by: { dt.entity.service }, interval: 5m, default: 0
- Key Parameters of makeTimeseries
Metric Definition: One or more aggregation expressions, such as count() , avg(duration) , or percentile(latency, 90) .
by: { ... } : Dimensional slicing attribute. Grail creates a separate, independent time-series stream for each unique value of the grouping fields (e.g., one line per service).
interval: <duration> : Specifies the temporal resolution of the buckets (e.g., 1m , 5m , 15m , 1h , 1d ). If omitted, Grail dynamically calculates an optimal interval based on the global query timeframe.
default: <value> : The fallback value used to populate empty intervals where zero matching records were detected. Setting default: 0 ensures that inactive time buckets are explicitly populated with zero, producing a continuous, unbroken baseline on line and area charts.
3. Advanced Analytical Pipelines: Top-N Analysis & Slicing
A critical pattern in operations dashboards is Top-N Analysis —isolating the top 5 or 10 entities responsible for the majority of errors or latency, rather than overwhelming dashboards with hundreds of lines.
- The Tabular Top-N Pattern
- To find the top 5 error-producing Kubernetes namespaces over the last 24 hours: fetch logs, from: now() - 24h
- | filter status == "ERROR"
- | summarize error_count = count(), by: { k8s.namespace.name }
- | sort error_count desc
- | limit 5
In this pipeline, summarize first aggregates the entire dataset across all namespaces; sort error_count desc orders the aggregated records from highest to lowest; and limit 5 truncates the stream to the top 5 offenders.
The Time-Series Top-N Slicing Pattern
When visualizing multi-series line charts, displaying 50 lines simultaneously creates unreadable "spaghetti" charts. DQL supports combining makeTimeseries with subqueries or dimensional limits to display only the Top-N series over time while grouping the remainder into an "Other" category or filtering them out.
4. Mapping DQL Outputs to Dynatrace Visualizations
In Dynatrace Dashboards and Notebooks , DQL serves as the unified data engine. The visual tile rendering options available to an engineer depend directly on the structural data type produced by the terminal command in the DQL pipeline. +---------------------------------------------------------------------------------------------------+
- | DQL COMMAND TO VISUALIZATION MAPPING MATRIX |
- +---------------------------------------------------------------------------------------------------+
- | DQL Pipeline Output Available Visualization Types Primary Operational Purpose|
- +---------------------------------------------------------------------------------------------------+
- | Raw / Projected Records • Table Ad-hoc log search, audit |
- | (fetch | filter | fields) forensics, individual traces
- +---------------------------------------------------------------------------------------------------+
- | Tabular Aggregation • Table SLA scorecards, Top-N lists|
- | (summarize ... by: {..}) • Single Value (Stat/Metric Tile) KPI counters, health meters|
- | • Honeycomb Cluster/host fleet health |
- | • Donut / Pie Chart Status code proportions |
- | • Categorical Bar Chart Cross-service comparisons |
- +---------------------------------------------------------------------------------------------------+
- | Continuous Time-Series • Line Chart Trend analysis, baselines |
- | (makeTimeseries ... • Stacked Area Chart Cumulative volume over time|
- | interval: .. default: 0) • Time-binned Bar Chart Hourly/daily error spikes |
- +---------------------------------------------------------------------------------------------------+
- Choosing the Optimal Visualization
Single Value (Stat Tile): Best used when summarize outputs a single scalar value without grouping dimensions (e.g., summarize total_errors = count() ). Displays a prominent numeric badge with optional threshold coloring (green, yellow, red).
Honeycomb View: Ideal for representing fleet-wide health across hundreds of nodes or services. Each hexagon represents a grouping dimension value (e.g., host), shaded by error density or CPU saturation.
Donut / Pie Chart: Best used to visualize proportional categorical distributions (e.g., HTTP response codes: 2xx vs 3xx vs 4xx vs 5xx), provided the number of slices is small (under 7).
Line Chart: The gold standard for continuous trend tracking over time. Requires makeTimeseries to provide equidistant temporal points.
Stacked Area Chart: Visualizes both the total volume and the proportional composition of multi-series metrics over time (e.g., total log volume stacked by log severity: INFO , WARN , ERROR ).
Dashboards vs. Notebooks
Dynatrace Notebooks: Interactive, exploratory document workspaces where engineers chain DQL queries, markdown documentation, and interactive charts. Used primarily for post-incident root cause forensics, exploratory data science, and team runbooks.
Dynatrace Dashboards: Structured, auto-refreshing operational control planes designed for NOC displays, team overview monitors, and executive KPI tracking. Queries powering dashboard tiles should be strictly optimized using temporal bounds, partition pruning, and efficient aggregation to minimize continuous compute consumption.