How to Set Up Datadog Infrastructure Monitoring

Last verified: September 10, 2026
By: PerfMonitoring

Datadog infrastructure monitoring starts with the Datadog Agent on the host you want to observe. The Agent collects host-level telemetry and forwards it to your Datadog site, where you can inspect the host, explore metrics, and create monitors. Datadog's current documentation recommends using its in-app Fleet Automation flow for installation because it generates instructions for your platform and organization. [1][2]

This tutorial uses a Linux host as the reference path. It focuses on the part that matters operationally: installing the Agent, proving that it is healthy locally, confirming that fresh metrics reach Datadog, and only then creating a first monitor. It does not assume that seeing a successful installer message means monitoring is complete.

What You'll Accomplish

By the end of the procedure, you should have:

1. a Datadog Agent 7 installation on a supported Linux host;
2. the Agent service running locally;
3. the host visible in Datadog with fresh system metrics;
4. a clear way to diagnose API-key, site, proxy, TLS, or service failures; and
5. one conservative baseline metric monitor built from telemetry you have already verified.

This article is about infrastructure monitoring. Logs, APM traces, security features, and application auto-instrumentation are separate capabilities and should be enabled only when they are part of your monitoring plan.

Prerequisites

You need:

• a Datadog account;
• a Datadog API key for the organization that should receive the host data;
• the correct Datadog site/region for that organization;
• a supported Linux host with administrator or sudo access; and
• outbound HTTPS connectivity from the host to the Datadog endpoints required by your site.

Datadog's Linux documentation identifies /etc/datadog-agent/datadog.yaml as the main Agent configuration file. Two important connection values are the organization API key and the Datadog site. [2]

Treat the API key as a secret. Do not paste a real key into documentation, screenshots, tickets, public shell examples, or source control.

Quick Answer

Open Datadog's Agent installation workflow, choose Linux, and use the generated Agent 7 installation command for your account and Datadog site. After installation, run sudo systemctl status datadog-agent and sudo datadog-agent status. Then confirm that the host appears in Datadog and that a fresh system metric is arriving. Only after the data path is healthy should you create a metric monitor. Datadog's current monitor workflow is Monitors > New Monitor > Metric. [1][2][3]

Step 1: Confirm the Datadog Site and Credential Scope

Before installing anything, make sure you know which Datadog site your organization uses. This matters because the Agent must send telemetry to the correct regional endpoint. A valid API key paired with the wrong site can leave you with an Agent that runs locally but does not populate the expected organization.

In Datadog, use the Agent installation flow rather than copying a command from an old blog post. The current getting-started documentation directs users to Fleet Automation/in-app installation, where the command is generated for the selected environment. [1]

If you manage secrets centrally, retrieve the API key through your normal secret-management workflow. Avoid leaving it in a shared terminal transcript. The exact secret-injection method depends on your automation platform, so this tutorial does not prescribe a universal one.

Step 2: Install Datadog Agent 7 on Linux

Recommended path: use the generated in-app command

In Datadog, open the Agent installation workflow, select Linux, and copy the generated command for your environment. This is the safest default because the Datadog site and organization-specific values are filled in by Datadog rather than guessed.

Run the command on the target host with the privileges required by the installer.

Generic Agent 7 script pattern

Datadog's current documentation also shows the Agent 7 installation script pattern below for supported Linux distributions. Use it only after replacing the placeholders with values from your own Datadog organization. [4]

DD_AGENT_MAJOR_VERSION=7 \
DD_API_KEY="<DATADOG_API_KEY>" \
DD_SITE="<DATADOG_SITE>" \
bash -c "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)"

Do not copy datadoghq.com from a random example if your organization uses another Datadog site. Use the site shown in your own Datadog environment.

The installer should create and start the datadog-agent service on a supported systemd-based Linux distribution. A successful package install is only the first checkpoint; you still need to validate the service and the telemetry path.

Step 3: Verify the Agent Service Locally

First check the system service:

sudo systemctl status datadog-agent

On a healthy systemd host, you are looking for an active/running service rather than repeated restarts or an immediate failure. Datadog lists this as the standard Linux service-status command. [2]

Next, inspect the Agent's own status page:

sudo datadog-agent status

Datadog documents this as the Linux command for the running Agent status page. It reports the Agent version, configuration paths, checks, forwarder state, and other diagnostic information. [2][5]

Do not treat the absence of a red error line as sufficient proof. Look for signs that the forwarder can submit data and that expected checks are running without persistent warnings.

If the service failed, inspect the systemd journal:

sudo journalctl -u datadog-agent.service

This is a documented Datadog troubleshooting path for Agent startup failures. [5]

Step 4: Check the Agent Configuration Without Exposing Secrets

The main Linux configuration file is:

/etc/datadog-agent/datadog.yaml

The same directory normally contains integration configuration under conf.d. [2]

When reviewing configuration, verify the site, proxy settings if applicable, tags, and other host-wide settings. Do not print or publish the API key merely to prove that it exists.

After changing Agent configuration, restart the service:

sudo systemctl restart datadog-agent

Then rerun:

sudo datadog-agent status

This two-step pattern is useful because it separates a configuration edit from verification that the Agent successfully restarted with the new configuration.

Step 5: Verify the Host in Datadog

A local service can be running while the remote data path is broken. You therefore need a second verification layer in the Datadog application.

Open the infrastructure view and find the new host. Datadog's monitor getting-started guide explicitly uses a populated Infrastructure List as a way to verify that the Agent is running and sending host data. [3]

Then inspect a system metric from the host. The exact interface labels can move over time, so use Datadog's search/navigation if necessary. The important checks are:

• the metric timestamp is recent;
• the metric is scoped to the expected host;
• the hostname/tag set is what you expect; and
• values continue to update over several collection cycles.

Useful built-in system metrics include CPU and disk signals. Datadog's monitor tutorial, for example, uses system.disk.in_use for disk utilization. [3]

If the host appears but data is stale, do not create alerts yet. Fix the ingestion problem first.

Step 6: Create a First Baseline Metric Monitor

Once telemetry is confirmed, create one small, understandable monitor rather than enabling a large alert pack blindly.

Datadog's current flow for a metric monitor is:

1. go to Monitors;
2. choose New Monitor;
3. select Metric;
4. choose a detection method;
5. define the metric and scope;
6. set alert conditions; and
7. configure notifications and permissions. [3]

For a first infrastructure monitor, CPU or disk usage is easier to reason about than a composite condition. Datadog's documentation uses a threshold alert as the default static-threshold model and demonstrates disk monitoring with system.disk.in_use. [3]

Do not copy a universal threshold such as “CPU > 80%” and assume it is correct. A useful threshold depends on workload behavior, evaluation duration, host role, and what action the team can take. Start by observing the host's normal baseline, then pick a threshold and duration that represent sustained abnormal behavior rather than a harmless spike.

A monitor should answer three questions clearly:

• What signal is abnormal?
• How long must it stay abnormal before paging?
• Who can act on the alert, and what should they do next?

If you cannot answer the third question, the monitor is not ready to page someone.

Verify the Setup

Consider the initial setup complete only when all of the following are true:

• sudo systemctl status datadog-agent shows the service running;
• sudo datadog-agent status does not show a persistent forwarder/configuration failure;
• the expected host appears in Datadog;
• at least one known system metric has fresh timestamps and continues updating; and
• your first monitor evaluates the intended host/metric scope.

This is stronger than checking only that the installer exited successfully.

Common Problems and Fixes

Problem: The Agent service is running, but the host does not appear

Likely causes: wrong Datadog site, wrong API key, proxy/network restrictions, or TLS/connectivity problems.

Fix: compare the site with your Datadog organization, confirm that the API key belongs to the intended organization, inspect sudo datadog-agent status, and review the Agent journal. If your network uses a proxy, validate the proxy configuration in datadog.yaml. Datadog's Linux documentation explicitly supports HTTP/HTTPS proxy configuration there. [2]

Problem: datadog-agent fails to start

Likely causes: invalid YAML, a bad configuration change, package/service failure, or permissions.

Fix: run sudo systemctl status datadog-agent, then sudo journalctl -u datadog-agent.service. If the failure began after editing YAML, validate indentation and restore the last known-good configuration.

Problem: The host appears, but expected metrics are missing

Likely causes: an integration-specific check is not enabled, the metric belongs to a capability you have not configured, or the scope/host tags are different from what you expected.

Fix: inspect the Agent status output and its Running Checks section. For a specific integration check, Datadog documents the following Linux pattern: [5]

sudo -u dd-agent datadog-agent check <CHECK_NAME>

Use the check name from the current integration documentation rather than guessing it.

Problem: The first monitor alerts constantly

Likely causes: a threshold copied from another environment, an evaluation window that is too short, or an overly broad host scope.

Fix: return to the metric history, establish the normal operating range, narrow the scope with stable tags, and use a duration that reflects a sustained condition. The goal is actionable monitoring, not maximum alert volume.

Best Practices

Tag before you scale. Add stable environment, service, team, or role tags before hundreds of hosts arrive. Clean tags make dashboards, monitors, ownership, and incident routing easier later.

Keep installation and feature enablement separate. Installing the core Agent does not mean every Datadog capability should be enabled. Add logs, APM, process monitoring, or security features deliberately, with their own data-volume and security review.

Pilot first. Validate a small number of representative hosts before deploying at fleet scale. This helps catch proxy, site, tagging, or package-policy issues while the blast radius is small.

Avoid secrets in examples. Use placeholders in runbooks and screenshots. If a credential is exposed, rotate it rather than merely deleting the screenshot.

Alert on symptoms that require action. A monitor should represent a condition worth human attention. High-frequency telemetry is useful for diagnosis; it does not all need a page.

When This Setup Makes Sense

This Agent-based path fits Linux servers or virtual machines where you want detailed host telemetry and can install software on the operating system. It is also the foundation for many Datadog integrations.

Choose a different onboarding path when the workload is primarily Kubernetes, serverless, managed cloud infrastructure, or a container-only host where the Docker Agent is the more natural deployment model. For Docker hosts, see How to Monitor Docker Containers with Datadog.

For broader context before deploying an agent estate, see PerfMonitoring's guides to infrastructure monitoring and server monitoring tools. You can also review the Datadog software profile or the Datadog vs New Relic comparison without mixing those commercial/evaluation intents into this setup guide.

FAQ

Does installing the Datadog Agent automatically enable APM?

No. The core Agent is the host-side foundation, but application tracing requires its own instrumentation/configuration path. Datadog also offers Single Step APM Instrumentation, but that is outside this infrastructure-only tutorial. [1]

Why is my Datadog host not appearing?

Start with the local Agent status, then verify the Datadog site and API key, followed by outbound network/proxy/TLS connectivity. A running Linux service does not prove that the Agent is successfully forwarding data to the intended Datadog organization.

Should I create alerts immediately after installing the Agent?

Create them only after you have verified the data and observed enough baseline behavior to choose a meaningful threshold. An automatic or copied threshold can create noise before you understand the host's normal workload.

Conclusion

A reliable Datadog infrastructure setup has two independent proofs: the Agent is healthy on the Linux host, and fresh telemetry is visible in Datadog. Validate both before adding alerting. Then begin with one monitor whose signal, duration, scope, owner, and response are easy to explain.

If your infrastructure is containerized with Docker, the next logical step is the companion tutorial on deploying the Datadog Docker Agent and verifying container discovery.

References

1. Datadog Documentation — Getting Started with the Agent — https://docs.datadoghq.com/getting_started/agent/ — accessed September 10, 2026.
2. Datadog Documentation — Linux — https://docs.datadoghq.com/agent/supported_platforms/linux/ — accessed September 10, 2026.
3. Datadog Documentation — Getting Started with Monitors — https://docs.datadoghq.com/getting_started/monitors/ — accessed September 10, 2026.
4. Datadog Documentation — Upgrade your Datadog Agent — https://docs.datadoghq.com/agent/guide/upgrade_agent_fleet_automation/ — accessed September 10, 2026. Used to verify the current Agent 7 Linux installation-script pattern; the in-app installer remains the recommended first path for a new host.
5. Datadog Documentation — Agent Commands / Agent troubleshooting — https://docs.datadoghq.com/agent/configuration/agent-commands/ and https://docs.datadoghq.com/agent/troubleshooting/agent_check_status/ — accessed September 10, 2026.

Editorial note: This tutorial was checked against current official Datadog documentation on the date above. No live Datadog account or production host was used to claim hands-on test results.