Tutorial · Dynatrace

How to Install Dynatrace OneAgent and Monitor a Server

Install Dynatrace OneAgent on a server, choose the monitoring mode, verify host and process visibility, and troubleshoot common installation issues.

By PerfMonitoring · Published September 10, 2026 · Last verified September 10, 2026 · Editorial Policy

Last verified: September 10, 2026
By: PerfMonitoring

Dynatrace OneAgent server monitoring begins with a decision that many short installation guides skip: which monitoring mode do you actually need? In the current Latest Dynatrace experience, OneAgent defaults to Full-Stack monitoring, while Infrastructure and Discovery modes are lighter alternatives. Dynatrace lets you choose the mode during installation and change it later. [1][2]

This tutorial uses a Linux server as the reference path, but the main Dynatrace onboarding flow also covers Windows and AIX. Instead of publishing a tenant-specific download command or token, it follows Dynatrace's current Discovery & Coverage > Install OneAgent workflow, then verifies the resulting installation from the host and from the Dynatrace UI.

What You'll Accomplish

You will:

  1. choose Full-Stack, Infrastructure, or Discovery mode intentionally;
  2. generate the current OneAgent installer and token from your Dynatrace environment;
  3. verify the Linux installer signature using the command Dynatrace provides;
  4. install OneAgent with the selected monitoring mode;
  5. confirm the active mode with oneagentctl;
  6. restart monitored processes when deep injection is required; and
  7. verify the host and process coverage in Dynatrace.

Prerequisites

Dynatrace's current first-install guide requires:

  • a Dynatrace environment;
  • administrator access to the server;
  • no conflicting existing OneAgent installation for the first-install workflow; and
  • network connectivity that supports SSL communication. [1]

For Linux, you also need permission to run the downloaded installer and the signature-verification command generated by Dynatrace. If your environment routes outbound traffic through a proxy or ActiveGate, confirm that design before installation rather than troubleshooting it after a fleet rollout.

Quick Answer

In Latest Dynatrace, open Discovery & Coverage, choose Install > Install OneAgent, select Linux, architecture, and monitoring mode, generate the required token, download the installer, run the provided signature-verification command, then run the generated installation command. After installation, check the current mode with /opt/dynatrace/oneagent/agent/tools/oneagentctl --get-monitoring-mode, restart application processes that need OneAgent injection, and confirm the host under Infrastructure & Operations > Hosts. [1][3]

Step 1: Choose the Monitoring Mode Before Installing

The current OneAgent modes are:

  • Full-Stack — the default mode and the broadest host/process/service/application monitoring path;
  • Infrastructure — a lighter infrastructure-focused mode; and
  • Discovery — a lightweight discovery-oriented mode. [2]

Do not choose Full-Stack merely because it is the default. Choose it when you actually want deep application/process observability and are comfortable with code-module/process injection where applicable.

Use Infrastructure mode when your objective is primarily infrastructure health and runtime visibility without the same application-performance scope. Dynatrace documents the installer parameter --set-monitoring-mode=infra-only for this mode. [2][4]

Use Discovery mode when topology/discovery is the primary goal and you deliberately do not need the full application/user performance dataset. The documented command-line value is discovery. [2][3]

A useful pre-install question is: What evidence do I expect to see after this installation? If the answer is only host CPU, memory, disks, and basic process visibility, a lighter mode may be sufficient. If the answer includes deep service traces, choose a mode and process-restart plan that supports that outcome.

Step 2: Open the Current OneAgent Deployment Flow

Dynatrace's Latest documentation currently directs first-time server installs to:

  1. Discovery & Coverage;
  2. Install > Install OneAgent;
  3. select the operating system;
  4. select the Linux architecture where applicable;
  5. select the monitoring mode; and
  6. optionally define a custom host name. [1]

Use this generated flow rather than copying a download URL from another tenant. The download endpoint and access token are environment-specific.

Dynatrace then asks you to generate an API token for the installation. Store it securely. The documentation warns that the generated token cannot simply be retrieved again from that step, so treat it like a credential rather than ordinary setup text. [1]

Step 3: Download and Verify the Linux Installer

Use the download command shown in your Dynatrace environment or choose the UI download option. On Linux and AIX, the current first-install flow includes a separate signature verification step with a CLI command supplied by Dynatrace. [1]

Run the provided verification before installation.

This is intentionally more conservative than embedding a fixed checksum or certificate command in this article. The installer filename, version, and generated command can change, while the security goal remains stable: verify the installer using the current command from the same trusted Dynatrace deployment flow that produced the package.

Do not upload the installer token or generated command into a public issue tracker or screenshot.

Step 4: Install OneAgent with the Chosen Mode

Run the installation command generated by Dynatrace.

If you need to override the monitoring mode on Linux, Dynatrace documents installer arguments such as:

--set-monitoring-mode=fullstack
--set-monitoring-mode=infra-only
--set-monitoring-mode=discovery

The current Linux customization documentation demonstrates passing settings to the installer, for example: [4]

Dynatrace-OneAgent-Linux.sh \
  --set-host-group=my_host_group \
  --set-monitoring-mode=infra-only

Do not replace the generated environment-specific install command with this generic example. It only illustrates how verified installer arguments are appended.

For a first host, keep optional settings minimal. Host groups, proxy settings, custom install paths, log-access behavior, and other options should reflect an existing operational standard rather than being enabled because a tutorial listed them.

Step 5: Verify the Active Monitoring Mode with oneagentctl

Dynatrace's current command-line reference places oneagentctl under the default Linux installation path:

/opt/dynatrace/oneagent/agent/tools

Root privileges are required on Linux. [3]

To check the active mode:

cd /opt/dynatrace/oneagent/agent/tools
sudo ./oneagentctl --get-monitoring-mode

The documented output values are:

  • fullstack
  • infra-only
  • discovery [3]

This is a useful guardrail after automated deployment. It confirms what the host is actually configured to use rather than what the deployment ticket claimed was selected.

If the result is wrong, change the mode through the supported Dynatrace UI, Settings API, or oneagentctl workflow documented for your environment. Avoid editing internal OneAgent files directly.

Step 6: Restart Processes That Need OneAgent Injection

A host appearing in Dynatrace does not automatically mean already-running application processes have deep monitoring.

Dynatrace's current install guide states that OneAgent cannot inject itself into processes that were already running before installation. To monitor those processes, restart them after the Agent is installed. [1]

Plan this deliberately. On a production server, do not restart every application immediately simply to make a tutorial checklist green. Use a maintenance window and restart the services that actually require the selected monitoring depth.

For Apache in particular, Dynatrace's troubleshooting guide warns that a partial/graceful restart may not be enough: the main process must be completely stopped and started for injection to take effect. [5]

This is a good example of why “OneAgent installed successfully” and “application is fully monitored” are different states.

Step 7: Verify the Host in Dynatrace

The current server-install guide uses Infrastructure & Operations > Hosts as the post-install verification location. [1]

Find the expected host and check:

  • the host name/identity is correct;
  • the last-seen telemetry is recent;
  • host resource metrics are updating;
  • the selected monitoring mode matches your intended coverage; and
  • expected application processes appear after any required restart.

If you selected Infrastructure mode, do not treat the absence of Full-Stack application data as a failure. Verify against the capability you chose.

If you selected Full-Stack but only host metrics appear, check process restart/injection state before reinstalling OneAgent.

Verify the Setup

Consider the server onboarding complete only when:

  1. the Dynatrace-generated installer was downloaded and verified through the current deployment workflow;
  2. installation completed without an unresolved error;
  3. oneagentctl --get-monitoring-mode returns the mode you intended;
  4. the host is visible in Dynatrace with fresh infrastructure telemetry;
  5. processes that require deep monitoring have been fully restarted when necessary; and
  6. process/service visibility matches the selected mode.

If the host exists but does not match the intended monitoring mode, stop and correct the configuration before using the host as the basis for dashboards or alerts.

Common Problems and Fixes

Problem: The installer cannot communicate with Dynatrace

Likely causes: outbound SSL/TLS connectivity, proxy/firewall restrictions, wrong environment-specific endpoint, or token problems.

Fix: return to the generated install flow and compare the endpoint/token setup with your network path. If a proxy is required, use the supported --set-proxy/configuration method from the current Linux customization docs rather than modifying generated URLs manually. [4]

Problem: The host appears, but deep process monitoring is missing

Likely cause: processes were already running before OneAgent installation or injection is disabled.

Fix: first confirm the monitoring mode. Then perform a complete restart of the affected process during an approved window. For Apache, do not assume a graceful reload is equivalent to a full restart. [1][5]

Problem: The host is in Infrastructure mode but the team expected Full-Stack

Likely cause: the lighter mode was selected during installation or applied later through host settings/API/CLI.

Fix: verify with:

cd /opt/dynatrace/oneagent/agent/tools
sudo ./oneagentctl --get-monitoring-mode

Then change the mode using a supported method. Dynatrace documents fullstack, infra-only, and discovery as valid mode values. [3]

Problem: OneAgent needs to be restarted after configuration changes

Dynatrace's Linux operation documentation supports restarting the OneAgent service through oneagentctl --restart-service when used with settings, and documents the service name oneagent for systemd start/stop operations. [6]

Use the product-supported method associated with the change you made. Remember that restarting OneAgent is not always the same as restarting an application process that needs injection.

Problem: A cloned VM creates identity problems

Do not assume a hot-cloned machine with OneAgent can be treated like a fresh independent host. Dynatrace's Linux operation documentation notes host-ID considerations and gives a specific stop/clone/start/restart-process sequence for hot cloning. [6]

Follow the current cloning guidance for image-based fleet provisioning rather than baking a running OneAgent state blindly into server images.

Best Practices

Decide mode from requirements, not defaults. Full-Stack provides the broadest visibility, but infrastructure-only or discovery can be the correct operational choice.

Use generated environment-specific commands. They reduce the risk of stale endpoints, tokens, or options copied from another tenant.

Separate Agent installation from application restarts. Plan deep-monitoring activation as a change to application processes, not just an Agent package deployment.

Record the chosen mode in configuration management. A host that is silently switched later can produce confusing gaps in dashboards and alerts.

Pilot before fleet rollout. Install on one representative server, validate connectivity, mode, host identity, process coverage, and security controls before automating hundreds of hosts.

Protect generated tokens. Do not store token-bearing commands in public CI logs or documentation.

When This Setup Makes Sense

OneAgent server installation is appropriate when you manage virtual machines or physical servers and want Dynatrace to observe those hosts directly.

For Kubernetes, use the Dynatrace Operator onboarding workflow instead of installing a conventional host Agent manually on cluster nodes. The companion tutorial How to Monitor Kubernetes with Dynatrace covers that path.

For conceptual context and tool evaluation, see the Dynatrace software profile, infrastructure monitoring guide, server monitoring category, Datadog vs Dynatrace, and New Relic vs Dynatrace.

FAQ

Which Dynatrace OneAgent monitoring mode should I choose?

Choose Full-Stack when you need deep application/service visibility, Infrastructure when host/process infrastructure is the primary goal, and Discovery when lightweight topology discovery is sufficient. Verify current capability details in Dynatrace's monitoring-mode documentation before standardizing the choice. [2]

Why is the host visible but application data missing?

The most common first check is whether you selected Full-Stack and whether the application processes were completely restarted after OneAgent installation. OneAgent cannot retroactively inject into already-running processes. [1]

Does OneAgent require a process restart?

The Agent itself can install while applications are running, but processes that need OneAgent injection must be restarted after installation. Some software, such as Apache, needs a full stop/start rather than a partial reload. [1][5]

Conclusion

A trustworthy OneAgent rollout is not “download, run, done.” Choose the monitoring mode, use the current Dynatrace-generated installer and token workflow, verify the mode locally, restart only the processes that require injection, and prove the resulting host/process telemetry in Dynatrace.

That sequence makes later troubleshooting much easier because you know whether a missing signal comes from installation, mode selection, process injection, or network connectivity.

References

  1. Dynatrace Docs — Install OneAgent on a serverhttps://docs.dynatrace.com/docs/ingest-from/dynatrace-oneagent/installation-and-operation — updated March 16, 2026; accessed September 10, 2026.
  2. Dynatrace Docs — Enable OneAgent monitoring modeshttps://docs.dynatrace.com/docs/platform/oneagent/monitoring-modes/enable-monitoring-modes — updated August 5, 2026; accessed September 10, 2026.
  3. Dynatrace Docs — OneAgent configuration via command-line interfacehttps://docs.dynatrace.com/docs/ingest-from/dynatrace-oneagent/oneagent-configuration-via-command-line-interface — updated August 3, 2026; accessed September 10, 2026.
  4. Dynatrace Docs — Customize OneAgent installation on Linuxhttps://docs.dynatrace.com/docs/ingest-from/dynatrace-oneagent/installation-and-operation/linux/installation/customize-oneagent-installation-on-linux — updated May 13, 2026; accessed September 10, 2026.
  5. Dynatrace Docs — Troubleshooting OneAgent installationhttps://docs.dynatrace.com/docs/ingest-from/dynatrace-oneagent/oneagent-troubleshooting/troubleshoot-oneagent-installation — updated July 22, 2026; accessed September 10, 2026.
  6. Dynatrace Docs — Stop/restart OneAgent on Linuxhttps://docs.dynatrace.com/docs/ingest-from/dynatrace-oneagent/installation-and-operation/linux/operation/stop-restart-oneagent-on-linux — updated May 20, 2026; accessed September 10, 2026.

Editorial note: This tutorial was fact-checked against current Latest Dynatrace documentation. No live Dynatrace tenant or production server was used to claim hands-on test results.