Study guide
3.1 OneAgent Architecture, Components & Automatic Injection
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
3.1 OneAgent Architecture, Components & Automatic Injection
Key Takeaways Explain This Topic AI
Dynatrace OneAgent operates as a single unified binary containing specialized modular sub-processes supervised by the oneagentwatchdog daemon.
On Linux, automatic code-level injection is orchestrated via the dynamic linker preloading liboneagentproc.so from /etc/ld.so.preload into newly spawned processes.
Host operating system metrics, network throughput, and running process lists are discovered immediately without restarts, but deep code-level tracing (PurePath) requires an application process restart.
Deep monitoring modules utilize Dynamic Bytecode Instrumentation (BCI) for JVM and .NET runtimes, as well as native web server modules for Apache, NGINX, and IIS.
Last updated: September 2026
OneAgent Architecture, Components & Automatic Injection
Exam Focus: Understanding the internal process model of Dynatrace OneAgent, the mechanics of dynamic library hooking via the operating system dynamic linker, and the exact boundary between immediate host discovery and capabilities that require an application restart is essential for the Dynatrace Certified Associate exam.
In traditional Application Performance Monitoring (APM) tools, monitoring a multi-tier enterprise stack required deploying separate, disjointed agents: one agent for host infrastructure metrics, a distinct profiler for the Java Virtual Machine (JVM), a separate plugin for web server metrics, an operating system daemon for log collection, and a network sniffing tap. This multi-agent sprawl introduced significant maintenance overhead, version compatibility matrix nightmares, and unpredictable resource footprints.
Dynatrace eliminates this complexity through OneAgent : a single, unified agent binary installed per host or container node. Once deployed, OneAgent automatically discovers the host environment, analyzes network topology, discovers running process groups, and injects deep monitoring sensors into supported application runtimes without requiring code changes, proprietary SDK modifications, or manual binary recompilation.
OneAgent Process Architecture and Subsystem Modules
While OneAgent is packaged and installed as a unified binary, it executes internally as a coordinated collection of modular sub-processes and runtime sensors. This separation ensures operational resilience: if a specific language sensor encounters an unhandled edge case, the host-level operating system monitoring remains fully operational.
Process / Module Name Execution Context Primary Operational Responsibility
oneagentwatchdog Root / Administrator Service Supervises all agent sub-processes, monitors CPU and memory consumption against safety thresholds, and restarts failed modules.
oneagentos Host OS Daemon Collects host-level infrastructure telemetry: CPU utilization, physical and virtual memory, disk I/O, storage saturation, and OS process lists.
oneagentnet Kernel / Network Module Captures network socket metrics, TCP round-trip time (RTT), retransmission rates, connection resets, and process-to-process network traffic.
Deep Monitoring Modules Application Process Memory Space Injected into language runtimes (Java, .NET, Node.js, Go, PHP) to capture method execution times, call stacks, PurePath traces, and database statements.
Web Server Modules Web Server Worker Processes Native plugins for Apache HTTP Server, NGINX, and Microsoft IIS that capture incoming HTTP requests, headers, and inject Real User Monitoring (RUM) JavaScript.
Log Analytics Module Host OS Daemon Discovers system and application log files, streams log records to Dynatrace Grail, and performs local log masking and filtering.
Extension Execution Agent Host OS Daemon Executes Dynatrace Extensions 2.0 (SNMP, WMI, Prometheus, custom JMX) to ingest third-party and domain-specific telemetry.
The Watchdog Daemon ( oneagentwatchdog )
The OneAgent watchdog is the master supervisory daemon running as an operating system service. It acts as the guardian of host system stability. The watchdog performs three critical functions:
Lifecycle Management: It spawns, stops, and updates the child monitoring daemons ( oneagentos , oneagentnet , plugin engines).
Self-Protection and Resource Throttling: It continuously measures the CPU and memory consumption of all OneAgent components. If an agent component exceeds predefined resource thresholds, the watchdog throttles or temporarily suspends monitoring to prevent impacting host workloads.
Automatic Crash Recovery: If a sub-process terminates unexpectedly due to a system crash or out-of-memory event, the watchdog logs the failure diagnostic data and automatically restarts the affected module.
Linux Automatic Injection Mechanics: Dynamic Linker & ld.so.preload
One of the most foundational capabilities tested on the Dynatrace Certified Associate exam is Automatic Injection —how OneAgent injects deep monitoring sensors into running processes without touching source code.
On Linux systems, OneAgent utilizes the native dynamic linker mechanism ( ld-linux.so ). During installation, OneAgent registers its bootstrap loader library in the system-wide preloading configuration file: /etc/ld.so.preload
Inside /etc/ld.so.preload , OneAgent appends the path to its process agent bootstrap library, typically: /opt/dynatrace/oneagent/agent/lib64/liboneagentproc.so
- The Step-by-Step Linux Injection Sequence 1. Kernel Syscall ==> Executable invoked via execve()
- 2. Dynamic Linker Load ==> ld-linux.so reads /etc/ld.so.preload before application libraries
- 3. Bootstrap Hook ==> liboneagentproc.so loads into the new process address space
- 4. Technology Check ==> Inspects ELF header, process arguments, and environment variables
- 5. Runtime Match ==> Identifies supported runtime (e.g., /usr/bin/java or /usr/bin/node)
- 6. Sensor Mapping ==> Loads language-specific module (e.g., liboneagentjava.so)
- 7. Bytecode Hook ==> Injects runtime bytecode instrumentation (BCI) into classloader
When any new process is launched via the execve() system call, the Linux dynamic linker inspects /etc/ld.so.preload before loading the application's own shared objects ( libc , etc.). The linker preloads liboneagentproc.so directly into the process memory address space.
At this stage, the OneAgent bootstrap library performs a rapid, lightweight signature inspection of the process:
It examines the executable binary's ELF headers and symbol tables.
It checks the command-line arguments and process environment variables.
If the process is a standard shell utility (such as ls , grep , or cat ), the bootstrap library unhooks immediately and unloads with negligible overhead (sub-millisecond).
If the process matches a supported application runtime (such as Java, Node.js, .NET Core, Python, or Go), the bootstrap loader maps the appropriate technology code module (for example, liboneagentjava.so ) into the process address space.
Once loaded into the runtime process, the code module uses Dynamic Bytecode Instrumentation (BCI) . For Java Virtual Machines, it hooks into the Java Virtual Machine Tool Interface (JVMTI) and modifies class bytecode dynamically at class-loading time. For .NET, it attaches via the CLR Profiling API. This allows Dynatrace to intercept method entries and exits, capture method arguments and exceptions, time database queries, and propagate PurePath trace context across thread boundaries and network hops.
Windows Injection Architecture: AppInit_DLLs, Detours & Profiling APIs
On Microsoft Windows operating systems, OneAgent achieves transparent injection through a combination of native Windows subsystem mechanisms:
User-Mode API Hooking (Dynatrace Detours Engine): OneAgent utilizes an advanced memory-hooking framework to intercept native Win32/NT system APIs. When new processes launch, OneAgent inspects their PE (Portable Executable) headers and determines whether monitoring hooks should be established.
.NET CLR Profiling Interface: For .NET Framework and .NET Core / .NET 5+ applications, OneAgent leverages Microsoft's native CLR Profiling APIs. When an instrumented .NET process boots, environment variables tell the Common Language Runtime to load the Dynatrace profiler COM object into memory:
- COR_ENABLE_PROFILING=1 and COR_PROFILER={GUID} (for .NET Framework)
- CORECLR_ENABLE_PROFILING=1 and CORECLR_PROFILER={GUID} (for .NET Core)
Internet Information Services (IIS) Module Injection: For Microsoft IIS web servers, OneAgent installs a native C++ HTTP module into the IIS core pipeline via applicationHost.config . This module intercepts every incoming HTTP request, measures request durations, captures HTTP response status codes, correlates incoming requests with backend database transactions, and automatically injects the Real User Monitoring (RUM) JavaScript tag before closing the HTML <head> tag.
Container Runtime Discovery and Namespace Traversal
When deployed on a containerized host running Docker, containerd, or CRI-O, OneAgent does not require container images to be rebuilt or altered. The host-level OneAgent monitors containers from the underlying operating system by traversing Linux kernel namespaces:
PID Namespace Traversal: OneAgent accesses the host PID namespace, allowing it to view every process executing inside every container running on the node.
Mount Namespace Injection: OneAgent discovers running container runtimes by communicating with local runtime control sockets (e.g., /var/run/containerd/containerd.sock or /var/run/docker.sock ). When a container launches, OneAgent maps its instrumentation libraries directly into the container's mount namespace ( mnt ), making the agent libraries accessible inside the container filesystem.
Network Namespace Inspection: The network module attaches to the container's virtual ethernet interfaces ( veth ) and network namespace ( net ) to measure round-trip times, bandwidth consumption, and TCP connection metrics per container.
Immediate Discovery vs. Process Restart Requirements
A critical, heavily tested distinction on the certification exam is understanding what data Dynatrace discovers immediately upon OneAgent installation versus what capabilities strictly require an application process restart .
The Golden Rule of OneAgent Injection
Host Infrastructure & OS Metrics = No Restart Required: The OS monitoring daemon ( oneagentos ) and network daemon ( oneagentnet ) begin inspecting system states, cgroups, network interfaces, and process tables immediately upon service startup.
Deep Code-Level Monitoring & PurePaths = Application Restart Mandatory: Because dynamic preloading ( /etc/ld.so.preload ) and bytecode instrumentation occur when a process initializes its runtime and classloaders, already-running application processes must be restarted for OneAgent to inject its sensors into memory.
Capability / Feature Immediate (No Restart) Requires Application Restart Technical Rationale
Host CPU, Memory & Disk I/O Yes No Captured by oneagentos directly from OS kernel statistics and /proc filesystem.
Host Network Interface Throughput Yes No Captured by oneagentnet from host network drivers and socket tables.
Running Process Discovery & Resource Usage Yes No OneAgent enumerates existing process trees and tracks per-process CPU/RAM via OS counters.
Process Listening Ports & Network Connections Yes No Discovered by inspecting host network socket tables and TCP connection states.
PurePath Distributed Tracing No Yes Requires code modules to inject into the JVM/CLR runtime at process startup to hook method execution.
Service Detection & Entry Points No Yes Web request endpoints and RPC services are detected by code-level sensors running inside the application.
Database Query & SQL Capture No Yes JDBC, ADO.NET, and database drivers must be instrumented at class-loading time.
Real User Monitoring (RUM) Tag Injection No Yes Web server and application HTTP filters must be hooked into the request/response processing pipeline.
Method Hotspots & Thread CPU Diagnostics No Yes Requires JVMTI or CLR thread profiling hooks loaded during runtime boot.
Handling Agent Updates and Restarts
When OneAgent automatic updates are enabled, the host OS agent and watchdog update immediately in the background without rebooting the host operating system. However, the deep code modules running inside target application memory spaces continue running the previous agent version until those application processes are restarted. Upon the next scheduled maintenance window or rolling restart, the newly updated code modules are injected automatically.