Study guide
4.1 Monitoring Modes: Full-Stack vs. Infrastructure-Only vs. Discovery
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
4.1 Monitoring Modes: Full-Stack vs. Infrastructure-Only vs. Discovery
Key Takeaways Explain This Topic AI
Full-Stack Monitoring provides end-to-end observability, including distributed PurePath tracing, code-level execution hotspots, database query inspection, and automated Real User Monitoring (RUM) tag injection.
Infrastructure-Only Monitoring captures host operating system telemetry, network interface metrics, TCP socket statistics, and process-level resource consumption without injecting monitoring hooks into application runtimes.
Discovery Mode delivers lightweight hardware, operating system, and process inventory enumeration for initial estate assessment and migration planning without collecting continuous deep telemetry.
Switching an existing host from Infrastructure-Only to Full-Stack monitoring requires restarting running application processes so the dynamic linker can inject runtime bytecode instrumentation sensors.
Last updated: September 2026
Monitoring Modes: Full-Stack vs. Infrastructure-Only vs. Discovery
Exam Focus: Mastering the functional boundaries, resource overhead, licensing consumption, and configuration workflows of Dynatrace OneAgent monitoring modes is a core requirement for the Dynatrace Certified Associate exam. Candidates must understand exactly what telemetry is captured in each mode, when to choose Infrastructure-Only versus Full-Stack, and why restarting application processes is mandatory when elevating monitoring modes.
Enterprise IT landscapes encompass heterogeneous workloads: mission-critical microservices requiring deep code-level profiling, legacy monolithic mainframes running proprietary runtimes, high-throughput database clusters governed by strict security policies, and ephemeral cloud nodes requiring basic inventory tracking. Deploying uniform, heavyweight monitoring across such diverse infrastructure is neither operationally viable nor cost-effective.
Dynatrace addresses this spectrum through three distinct OneAgent Monitoring Modes :
- Full-Stack Monitoring (FSM)
- Infrastructure-Only Monitoring (Infra-Only / IM)
- Discovery Mode (Host & Cloud Discovery)
Understanding how OneAgent operates in each mode enables organizations to optimize licensing expenditure (Host Units or Dynatrace Platform Subscription / DPS GiB-hour consumption), adhere to corporate security and regulatory compliance mandates, and maintain complete visibility across the enterprise topology.
Full-Stack Monitoring (FSM)
Full-Stack Monitoring represents the standard, comprehensive observability tier of Dynatrace. In this mode, OneAgent acts as an all-inclusive sensor platform operating simultaneously at the host operating system level, the container orchestration layer, the network socket layer, and deep inside the application runtime memory space.
Operational Architecture & Code-Level Injection
When a host runs in Full-Stack mode, OneAgent initializes all background daemons ( oneagentwatchdog , oneagentos , and oneagentnet ) and registers its dynamic preloader ( liboneagentproc.so on Linux via /etc/ld.so.preload or user-mode detours and CLR profiling hooks on Windows). Whenever an application process boots:
The OneAgent bootstrap loader inspects the process ELF or PE binary headers.
If a supported application runtime is identified (such as Java, .NET, Node.js, PHP, Go, or Python), OneAgent dynamically injects language-specific code modules (sensors) directly into the process address space.
The code module leverages Dynamic Bytecode Instrumentation (BCI) to rewrite class definitions on the fly, instrumenting method entries, exits, database driver calls, and external network requests without modifying source code on disk.
Core Capabilities Delivered Exclusively by Full-Stack Monitoring
Distributed Tracing (PurePath Technology): Captures end-to-end transactional execution paths across microservices, asynchronous message queues, and cross-host HTTP/gRPC boundaries.
Code-Level Hotspot Diagnostics: Identifies exact methods, class hierarchies, and execution line numbers causing CPU starvation, thread lock contention, or memory allocation churn.
Database Statement & Parameter Capture: Captures exact SQL statements, stored procedure invocations, NoSQL key lookups, and round-trip execution times from client-side database drivers.
Automated Service Detection: Groups web request endpoints, messaging listeners, and background workers into discrete, monitored Service entities in Smartscape.
Real User Monitoring (RUM) Auto-Injection: Automatically modifies HTTP responses in web servers (Apache, NGINX, IIS) to inject the Dynatrace RUM JavaScript agent tag ( ruxitagentjs ) into the HTML <head> section.
Causal Davis AI Problem Analysis: Full-Stack entities participate in automated topological root-cause analysis, allowing Davis AI to pinpoint code regressions, slow database queries, or method memory leaks as the primary fault in an incident.
Infrastructure-Only Monitoring (Infra-Only)
Infrastructure-Only Monitoring provides robust host-level and process-level observability while intentionally suppressing deep code-level instrumentation. In this mode, OneAgent monitors physical hardware, virtualized operating systems, container runtimes, and process health counters, but does not inject sensors into application runtimes .
Operational Architecture & Injection Suppression
In Infrastructure-Only mode:
The master supervisor daemon ( oneagentwatchdog ), the OS telemetry daemon ( oneagentos ), and the network kernel module ( oneagentnet ) run with full functionality.
OneAgent reads host-level counters from /proc , system APIs, and container control groups ( cgroups ).
Crucially, the dynamic bootstrap loader either unhooks immediately upon process execution or suppresses the loading of language-specific instrumentation libraries ( liboneagentjava.so , liboneagentdotnet.so , etc.).
The target application runtimes (JVM, CLR, V8) run completely untouched. No class bytecode is rewritten, no profiling APIs are activated, and no memory overhead is added to the application runtime heap.
Telemetry Collected in Infrastructure-Only Mode
Host Health Metrics: CPU utilization (User, System, Steal, I/O wait), physical and virtual memory saturation, disk read/write throughput, storage latency, and filesystem space exhaustion.
Network Performance: Physical interface throughput, TCP packet transmission rates, TCP round-trip time (RTT), packet retransmission percentages, and connection reset states.
Process-Level Resource Consumption: OneAgent enumerates all running processes on the host, tracking CPU percentage, resident set size (RSS) memory, page faults, and process uptime for every process instance.
Process Network Connections & Listening Ports: Discovers which processes are listening on specific TCP/UDP ports and maps inbound/outbound connection topology.
Container Infrastructure Telemetry: Monitors container-level CPU usage, memory limits, throttled CPU cycles, and network traffic across Docker, containerd, and Kubernetes pod namespaces.
What Is Missing in Infrastructure-Only Mode
In Infrastructure-Only mode, Dynatrace cannot capture:
PurePath transaction traces or cross-tier service calls.
Service-level response times, failure rates, or request throughput.
Database query text, slow query execution times, or JDBC connection pool metrics.
Method-level CPU consumption or thread dump analyses.
Garbage collection pauses, heap memory generation metrics, or memory leak allocation paths.
Real User Monitoring JavaScript tag injection.
Discovery Mode (Host & Cloud Discovery)
Discovery Mode is an ultra-lightweight operational posture primarily utilized during enterprise onboarding, data center migration assessments, or broad cloud footprint audits.
Characteristics of Discovery Mode
Inventory Enumeration: Discovers hardware attributes, operating system distributions, hypervisor details, IP configurations, and installed software packages.
Process Presence Identification: Detects the presence and execution state of process groups to assist architects in sizing application environments and planning full deployment rollouts.
Resource & Licensing Impact: Operates with minimal CPU and memory consumption. In modern Dynatrace licensing (DPS), discovery capabilities allow infrastructure teams to scan large server fleets to evaluate application dependencies before committing full-stack licensing resources.
No Continuous Performance Telemetry: Unlike Infrastructure-Only mode, Discovery mode does not maintain high-resolution, continuous metric streaming for operating system counters or network socket metrics.
Feature & Capability Comparison Matrix
The following table summarizes the technical capabilities across all three monitoring modes for the Dynatrace Certified Associate exam:
- Feature / Metric Dimension Full-Stack Monitoring Infrastructure-Only Discovery Mode
- Host CPU, Memory & Disk I/O Yes Yes Basic OS Info Only
- Network Interface Throughput & Saturation Yes Yes No
- TCP Retransmission Rates & Socket RTT Yes Yes No
- Process List Enumeration & Uptime Yes Yes Yes (Snapshot)
- Process-Level CPU & RAM (RSS) Yes Yes No
- Process Listening Ports & Socket Connections Yes Yes No
- Container / Cgroup Resource Metrics Yes Yes No
- PurePath Distributed Tracing Yes No No
- Service Detection & Entry Points Yes No No
- Database Query Text & Execution Times Yes No No
- Method Hotspots & Thread Lock Profiling Yes No No
- JVM / CLR Heap & Garbage Collection Yes No No
- Automatic RUM JavaScript Tag Injection Yes No No
- Davis AI Problem Causality Level Full Code & Service Root Cause Host & Network Root Cause Only None
Relative License Consumption Ratio Standard Host Units (1.0 HU per 16 GB) Reduced Infra Units (~0.3 HU per 16 GB) Minimal / Free Tier
Selective Process Monitoring on Full-Stack Hosts
In enterprise operations, hosts frequently run mixed workloads. For example, an application server might host a critical Java microservice alongside an unmanaged, memory-constrained third-party caching utility. To balance visibility against risk, Dynatrace enables Selective Process Group Monitoring on Full-Stack hosts.
Instead of monitoring every running process in Full-Stack mode, administrators can:
Disable Automatic Deep Monitoring Globally: In Dynatrace Settings ( Processes and containers > Process group monitoring ), toggle automatic deep monitoring off.
Define Declarative Monitoring Rules: Establish rules that explicitly enable deep monitoring only for processes matching specific criteria (e.g., matching executable path /opt/apps/ or containing Java property -Dmonitored=true ).
Manual Process Group Overrides: Open the specific Process Group Settings page in the Dynatrace UI and manually toggle deep monitoring on or off for that individual process group.
When deep monitoring is disabled for a specific process on a Full-Stack host, OneAgent captures host and process-level CPU and memory for that process, but withholds bytecode instrumentation, preventing PurePath tracing and service creation for that specific workload.
Transitioning Between Monitoring Modes & The Application Restart Mandate
A critical, heavily tested operational lifecycle concept is the procedure and implications of switching monitoring modes on live hosts.
Setting the Mode at Installation Time
Linux Installer Flag: --set-infra-only=true (for Infrastructure-Only) or --set-infra-only=false (for Full-Stack, default).
Windows MSI Property: INFRA_ONLY=1 (for Infrastructure-Only) or INFRA_ONLY=0 (for Full-Stack, default).
Switching Modes Post-Installation
Administrators can alter monitoring modes post-deployment via two mechanisms:
Dynatrace Web UI: Navigate to Host settings > Monitoring mode and toggle between Full-Stack and Infrastructure Monitoring.
Command-Line Utility ( oneagentctl ):
On Linux: /opt/dynatrace/oneagent/agent/tools/oneagentctl --set-monitoring-mode=infra-only or --set-monitoring-mode=fullstack
On Windows: .\oneagentctl.exe --set-monitoring-mode=infra-only or --set-monitoring-mode=fullstack
Following the oneagentctl command, the OneAgent operating system service must be restarted ( systemctl restart oneagent or Restart-Service "Dynatrace OneAgent" ).
The Golden Rule: Why Application Restarts Are Mandatory When Elevating
Switching Full-Stack to Infra-Only: The OneAgent code modules can be instructed to cease transaction capture. However, complete removal of the loaded .so or .dll library from the application process address space generally requires an application restart.
Switching Infra-Only to Full-Stack (Crucial Exam Rule): If an application was already running while OneAgent was in Infrastructure-Only mode, that application process MUST BE RESTARTED to achieve Full-Stack monitoring. The operating system dynamic linker ( ld-linux.so ) loads shared libraries and executes bytecode instrumentation hooks exclusively at process initialization time ( execve ). An existing running process cannot retroactively load the OneAgent code sensors into its runtime memory space without a restart.
Architectural Strategy: Enterprise Decision Framework
When architecting an enterprise Dynatrace rollout, adopt the following decision criteria:
Deploy Full-Stack Monitoring When:
The application is customer-facing, revenue-generating, or part of a core business service.
Distributed transaction tracing across microservice boundaries is required.
Development or operations teams require database statement timing and method-level hotspot diagnostics.
End-user experience tracking (RUM) must be correlated with backend performance.
Deploy Infrastructure-Only Monitoring When:
The host is a commercial off-the-shelf (COTS) database appliance (e.g., Oracle Exadata, SAP HANA bare-metal) where vendor support policies prohibit third-party shared library injection.
The host serves purely as network routing infrastructure, bastion jump hosts, or storage gateways.
Application runtimes on the host are unsupported or proprietary legacy binaries.
Budgetary constraints mandate monitoring broad infrastructure health while reserving Full-Stack licensing for Tier-1 application tiers.