Dynatrace OneAgent: Full-Stack vs Infrastructure-Only Monitoring

You install the Dynatrace OneAgent on a host, but the host appears healthy while the application still fails. The missing context usually comes down to one deployment choice: Full-Stack versus Infrastructure-only monitoring. Choosing Full-Stack on a locked third-party appliance wastes effort and risks stability; choosing Infrastructure-only on your own microservices leaves you with CPU and memory graphs but no code-level explanation for errors.

The useful rule is simple: monitor the application code when you own the runtime and can restart processes; monitor only the host when you cannot touch the application layer.

Decision constraints

Before selecting a mode, confirm these constraints on the target host:

• Do you control the application startup command?
• Can you restart processes after the OneAgent is installed?
• Is the language or runtime supported for bytecode instrumentation?
• Does the host run a third-party appliance where modifying software is prohibited?

Full-Stack monitoring means the OneAgent injects instrumentation into application runtimes using bytecode modification. This captures services and traces, such as PurePaths, which show how a request moves through methods and dependencies. Infrastructure-only monitoring collects host metrics—CPU, memory, disk, and network—without touching application processes.

Supported options compared

Factor	Full-Stack	Infrastructure-only
Visibility	Host metrics, processes, services, distributed traces	Host metrics only
Instrumentation	Automatic bytecode injection into runtimes	None
Process restart	Required for existing processes after enabling	Not required
Installation privileges	Elevated; must modify process startup parameters	Standard host access
Typical overhead	Minor CPU and memory increase from instrumentation	Negligible
Best fit	Owned applications, microservices, APIs	Third-party appliances, legacy systems, locked databases

Trade-offs

Full-Stack monitoring gives the most actionable data because Dynatrace can correlate a slow database call with a specific service method. The cost is a small performance overhead and the need for administrative rights to change how applications start. Existing processes do not pick up instrumentation until they are restarted.

Infrastructure-only monitoring avoids code-level risk entirely. It is appropriate for appliances where the vendor prohibits agent injection or for operating systems where restarting services is not allowed. The trade-off is visibility: you will see that memory is high, but not which query or function is consuming it.

Implementation: enabling Full-Stack on a host group

In Dynatrace, monitoring mode is configured at the host or host-group level. Exact menu labels vary by product version, so confirm the current navigation in your environment before proceeding.

1. Open the Dynatrace UI and go to the host group settings for the target hosts.
2. Find the Monitoring mode option.
3. Change the value from Infrastructure-only to Full-Stack.
4. Save the configuration.
5. Restart each application process on the affected hosts so the OneAgent can load its instrumentation module at startup.

This is a state-changing operation. To roll back, repeat the same steps and select Infrastructure-only, then restart the processes again to unload instrumentation.

Validation

After the restart, verify that instrumentation is active using these checks:

• UI check: Open the Host entity page and confirm Monitoring mode displays Full-Stack. Then open Services and PurePaths for that host. Generate traffic to the application and confirm that service entries and traces appear.
• Log check on Linux: Run the following command on the monitored host to inspect OneAgent startup logs.

sudo tail -n 100 /var/lib/dynatrace/oneagent/log/oneagent.log

Run this command in a root shell or with sudo on the Linux host. The path assumes a standard OneAgent installation; it may differ by version or operating system. Look for entries indicating that the instrumentation module loaded successfully. Absence of such entries, or repeated errors about failed injection, means Full-Stack is not active despite the UI setting.

Limitations

• Full-Stack is not available for every language or custom runtime.
• Enabling Full-Stack on existing processes requires a restart; there is no live injection for already-running code.
• Infrastructure-only mode cannot show exceptions, method calls, or distributed traces.

Practical confirmation: If Services and PurePaths remain empty after traffic and restarts, re-check the host monitoring mode and OneAgent logs before opening a support case.