4.1 Monitoring Modes: Full-Stack vs. Infrastructure-Only vs. Discovery
Key Takeaways
- 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.
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) orINFRA_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-onlyor--set-monitoring-mode=fullstack - On Windows:
.\oneagentctl.exe --set-monitoring-mode=infra-onlyor--set-monitoring-mode=fullstack - Following the
oneagentctlcommand, the OneAgent operating system service must be restarted (systemctl restart oneagentorRestart-Service "Dynatrace OneAgent").
- On Linux:
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
.soor.dlllibrary 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.
A financial institution deploys Dynatrace OneAgent across its database tier hosting production Oracle Database servers on Red Hat Enterprise Linux. Corporate compliance policies strictly prohibit injecting third-party shared libraries or profiling hooks into the Oracle database engine memory space. However, the database administration team requires continuous visibility into host CPU saturation, disk I/O latency, network packet retransmission rates, and per-process memory consumption of each Oracle background process. Which deployment approach correctly fulfills these technical and compliance requirements?
An enterprise operations team decides to upgrade an existing fleet of Linux microservice hosts from Infrastructure-Only Monitoring to Full-Stack Monitoring. The systems administrator executes oneagentctl --set-monitoring-mode=fullstack on each host and restarts the OneAgent service using systemctl restart oneagent. Three hours later, the administrator inspects the Dynatrace console and discovers that while host metrics continue to report, no services, database calls, or PurePath transaction traces appear for the running Java applications. What is the root cause of this issue, and what corrective action must be taken?
A cloud engineering team operates a high-density Kubernetes node hosting forty containerized microservices alongside a mission-critical, proprietary C++ transaction daemon. The proprietary C++ daemon experiences stability crashes whenever external shared libraries hook into its process memory. The engineering team requires Full-Stack distributed tracing across all forty microservices, but must guarantee that the proprietary C++ daemon is completely exempt from code-level sensor injection. Which strategy correctly accomplishes this goal?