Study guide
1.3 Core Telemetry Components: OneAgent, ActiveGate & Grail Lakehouse
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
1.3 Core Telemetry Components: OneAgent, ActiveGate & Grail Lakehouse
Key Takeaways Explain This Topic AI
OneAgent is a single, unified binary that automatically discovers host architecture, injects bytecode sensors into running processes, and streams full-stack telemetry without manual coding.
ActiveGate operates as an intelligent proxy, message router, and perimeter endpoint that consolidates OneAgent traffic, executes private synthetics, and polls cloud provider APIs.
Environment ActiveGates serve individual tenant environments and run extensions/synthetics, whereas Cluster ActiveGates provide multi-tenant routing in Dynatrace Managed deployments.
Grail is Dynatrace's causally connected, schema-on-read data lakehouse that stores logs, metrics, traces, and business events without indexing overhead or rigid schemas.
Telemetry routing employs Network Zones to ensure OneAgents prioritize local ActiveGates within their network segment before attempting cross-zone or direct failover.
Last updated: September 2026
The Dynatrace platform operates on a tightly integrated telemetry architecture designed for automated full-stack observability. Rather than assembling disparate open-source collectors, log forwarders, and network profilers, Dynatrace unifies instrumentation, routing, and analytics through three core foundational components: Dynatrace OneAgent , Dynatrace ActiveGate , and the Grail Causally Connected Data Lakehouse .
OneAgent: Architecture and Dynamic Injection Mechanics
Dynatrace OneAgent revolutionizes application performance monitoring through its single binary paradigm. A single OneAgent package installed on an operating system delivers host metrics, network flow analysis, process discovery, deep application code profiling, and log forwarding without requiring distinct, siloed agents.
Modular Internal Architecture
When OneAgent installs on a host, it operates through a collection of specialized sub-components coordinated by an internal supervisor:
oneagentwatchdog (Supervisor Process): A resilient supervisor daemon that monitors the health of all OneAgent child modules. If a module crashes, stalls, or encounters an unexpected exception, the watchdog automatically terminates, isolates, and restarts it without disrupting the underlying host operating system.
oneagentos (Operating System Module): Gathers host-level infrastructure performance data, including physical and virtual CPU consumption, memory allocation, disk read/write throughput, storage queue lengths, and network interface statistics.
oneagentnet (Network Driver): A low-overhead kernel driver that analyzes TCP socket connections, packet loss, retransmission rates, and round-trip time (RTT) at the operating system level, mapping inter-process communications across the data center.
Language-Specific Sensor Modules: Specialized instrumentation runtimes compiled for Java, .NET, Node.js, Go, Python, PHP, Apache HTTP Server, NGINX, and Microsoft IIS. +-----------------------------------------------------------------------------------------+
- | ONEAGENT ARCHITECTURE STACK |
- +-----------------------------------------------------------------------------------------+
- | [oneagentwatchdog] <-- Supervises, monitors health, enforces resource safety limits |
- +-----------------------------------------------------------------------------------------+
- | [oneagentos] <-- Host metrics: CPU, RAM, Disk I/O, Storage, Host Processes |
- | [oneagentnet] <-- Network driver: TCP metrics, RTT, retransmissions, socket maps |
- +-----------------------------------------------------------------------------------------+
- | INJECTED RUNTIME SENSORS (Active Bytecode Hooks Inside Process Memory Spaces) |
- | • Java Virtual Machine (JVM) • .NET CLR / Core • Node.js / V8 Engine |
- | • Go Runtime (Dynamic Hooks) • Python Interpreter • PHP Engine |
- | • NGINX Web Server Modules • Apache HTTP Modules • Microsoft IIS Modules |
- +-----------------------------------------------------------------------------------------+
- Automatic Injection: Zero Code Modification
Unlike traditional APM solutions that require developers to import proprietary SDKs, edit build pipelines, or alter container entrypoints, OneAgent employs dynamic runtime injection :
Operating System Hooking: On Linux systems, OneAgent registers itself within /etc/ld.so.preload . On Windows systems, it leverages user-mode hooking, AppInit DLLs, and runtime environment hooks (e.g., COR_ENABLE_PROFILING for .NET CLR).
Process Spawn Interception: When the operating system initializes any new process executable, the dynamic linker loads the OneAgent bootstrap library directly into the virtual address space of the process before main() executes.
Runtime Recognition: The bootstrap library examines the process signature. If the process is a supported runtime (e.g., a JVM, Node.js process, or Python script), OneAgent activates the corresponding language sensor.
Bytecode Instrumentation: The sensor dynamically injects lightweight inspection instructions (probes) into the compiled bytecode in memory. It instruments entry points, exit points, parameter values, exceptions, and database calls, capturing complete PurePath transaction traces without modifying source code on disk.
Protective Circuit Breakers
To ensure zero negative impact on production workloads, OneAgent incorporates built-in resource guards. If host CPU utilization exceeds safe thresholds (e.g., OneAgent consuming > 5% of host CPU) or if process memory becomes severely constrained, OneAgent automatically throttles its sampling rate or temporarily suspends deep code inspection, safeguarding application availability.
ActiveGate: Topologies, Capabilities, and Use Cases
While OneAgents can theoretically communicate directly with Dynatrace SaaS, enterprise architectures rarely permit thousands of internal servers to access the public Internet directly. Dynatrace ActiveGate resolves this challenge by acting as a secure proxy, data consolidator, and edge intelligence appliance.
Environment ActiveGate vs. Cluster ActiveGate
ActiveGates are deployed in two distinct operational roles depending on platform architecture:
- Feature / Attribute Environment ActiveGate Cluster ActiveGate
- Deployment Model Dynatrace SaaS & Dynatrace Managed Dynatrace Managed exclusively
- Scope of Service Bound to a single Dynatrace Environment Shared across multiple Environments in a Cluster
- Network Placement Customer DMZ / Internal Network Segments Ingress DMZ in front of Managed Cluster nodes
OneAgent Traffic Proxy Proxies and compresses OneAgent telemetry Balances OneAgent traffic across cluster nodes
- Cloud Provider API Polling Supported (AWS, Azure, GCP APIs) Not used for Cloud API polling
- Private Synthetic Monitoring Executes HTTP & Browser Synthetic tests Does not execute Synthetic monitors
- Dynatrace Extensions 2.0 Runs SNMP, WMI, Prometheus, JMX collectors Does not execute Extensions 2.0 collectors
- Default Listening Port TCP 9999 (TLS encrypted) TCP 9999 (TLS encrypted)
- Core Capabilities of Environment ActiveGates
Deploying Environment ActiveGates provides four major architectural benefits:
Firewall Perimeter Consolidation: Instead of permitting hundreds or thousands of application hosts to establish outbound connections to the Internet, only the ActiveGate requires outbound access over port 443. All OneAgents route internally to the ActiveGate on port 9999.
WAN Traffic Compression and Buffering: ActiveGate compresses incoming telemetry before streaming it across WAN links to Dynatrace, reducing bandwidth consumption by up to 70%. Furthermore, if the WAN link experiences transient packet loss or a temporary outage, ActiveGate buffers telemetry in memory and local storage, re-transmitting once connectivity recovers.
Private Synthetic Monitoring: An Environment ActiveGate equipped with the Synthetic Engine module can execute simulated synthetic HTTP requests and full Chromium browser clickpaths from within private networks, validating internal APIs and intranets inaccessible from public cloud testing locations.
Cloud API & Extension Ingestion: ActiveGates serve as the polling engine for external infrastructure. They query cloud provider metrics (AWS CloudWatch, Azure Monitor, Google Cloud Monitoring) and execute Extensions 2.0 to monitor legacy network switches (SNMP), Windows infrastructure (WMI), and container metrics (Prometheus scraping).
Network Zones: Deterministic Routing
In complex multi-datacenter or multi-region enterprise environments, administrators organize ActiveGates and OneAgents using Network Zones . A Network Zone is a logical string identifier (e.g., us-east-aws or frankfurt-dc ) configured on collectors:
OneAgents always route traffic to an ActiveGate sharing their identical Network Zone.
If all local ActiveGates in the primary zone become unavailable, OneAgent falls back to configured alternative zones.
This prevents telemetry from unnecessarily crossing expensive inter-region cloud backbones or high-latency WAN links during normal operations.
Grail: The Causally Connected Data Lakehouse
In modern observability, traditional index-based storage systems (such as legacy Elasticsearch or Lucene clusters) suffer from architectural collapse under massive cloud scale. They require rigid schema definitions, consume massive disk space for inverted search indices, suffer from severe indexing lag (minutes before logs appear), and trigger costly index maintenance during high-cardinality spikes.
Dynatrace Grail replaces legacy indexing architectures with a causally connected, schema-on-read data lakehouse . +-----------------------------------------------------------------------------------------+
- | LEGACY INDEXING VS. DYNATRACE GRAIL |
- +-------------------------------------------------------------+---------------------------+
- | LEGACY INDEX-BASED LOG & METRIC STORES | DYNATRACE GRAIL LAKEHOUSE |
- +-------------------------------------------------------------+---------------------------+
- | • Rigid Schema-on-Write (data dropped if schema mismatches) | • Schema-on-Read (store |
- | • Heavy inverted indices consume 50-100% extra disk storage | raw, project on query) |
- | • Indexing latency: seconds to minutes before searchable | • Zero inverted indices |
- | • Index re-building required when data fields change | • Sub-second availability |
- | • Telemetry silos: logs, traces, and metrics stored apart | • Instant schema evolution|
- | • Manual correlation via regex and timestamps | • Unified causal context |
- +-------------------------------------------------------------+---------------------------+
- Principles of Grail Architecture
Schema-on-Read Mechanics: Telemetry—including unstructured log files, structured JSON records, distributed trace spans, and business events—is ingested in its raw, compressed format. No upfront schema definition is required. Field extraction, type casting, and pattern matching occur dynamically at query execution time via the Dynatrace Query Language (DQL) .
Massively Parallel Processing (MPP): Grail utilizes a distributed, serverless compute engine capable of scanning terabytes of compressed columnar data per second across parallel worker nodes.
Causal Topology Binding: Every log record, metric sample, and PurePath trace ingested into Grail is automatically stamped with underlying Smartscape topology identifiers ( dt.entity.host , dt.entity.process_group_instance , dt.entity.service ). This allows the Davis AI causation engine to immediately link log anomalies and trace errors to hardware incidents without relying on brittle string searches or time-window correlations.