Datadog Agent Installation (Linux)

You are helping a user install the Datadog Agent on one or more Linux hosts.

Stopping

Some steps below end in a stop: a fleet whose scope the user has not confirmed (Phase 1 and Phase 2), a fleet that spans several providers before the user picks which group goes first, and a remote rollout with no approved way to deliver the API key. Reach a stop the normal way: the preflight and the discovery or checks that lead to it still run, and you show them. At the stop, your reply ends with what you found and the question for the user. A stop is an open question, not a review gate: it gets no "after approval" section, and you do not write past it. Do not also write what would follow an answer: no commands, files, scripts or Terraform for it, and no "next steps", "after you choose", "if you pick option N", "for reference" or "commands that cannot be run" section. The user can paste anything you show, so an unconfirmed command is as good as run. Write the next steps after the user answers.

Running another skill

Some steps below hand off to another skill (for example

dd-account-setup

). If that skill is installed, run it. If it is not, download it and read it locally:

bash

SKILL='<skill-name>'
case "$SKILL" in ''|/*|*..*|*[!A-Za-z0-9._/-]*) echo "invalid skill name: $SKILL"; exit 1 ;; esac
d=$(mktemp -d) || exit 1
code=$(curl -q -sS --proto '=https' --connect-timeout 10 --max-time 120 -o "$d/repo.tar.gz" -w '%{http_code}' \
  https://codeload.github.com/datadog-labs/agent-skills/tar.gz/refs/heads/main) && [ "$code" = 200 ] \
  || { echo "download failed (HTTP ${code:-none}) - stop"; exit 1; }
list=$(tar -tzf "$d/repo.tar.gz") || { echo "downloaded archive is unreadable - stop"; exit 1; }
printf '%s\n' "$list" | grep -qxF "agent-skills-main/$SKILL/SKILL.md" \
  || { echo "skill $SKILL not found in datadog-labs/agent-skills - stop"; exit 1; }
tar -xzf "$d/repo.tar.gz" -C "$d" --strip-components=1 "agent-skills-main/$SKILL" \
  || { echo "extracting $SKILL failed - stop"; exit 1; }
[ -f "$d/$SKILL/SKILL.md" ] || { echo "extracted skill $SKILL is missing SKILL.md - stop"; exit 1; }
rm -f "$d/repo.tar.gz"
echo "$d/$SKILL"

This downloads one snapshot of the repository's current

main

(which can be newer than the skill you are running) and extracts only that skill's directory, so every file it references (

references/

scripts/

, and so on) is there. The block prints the directory. Read

SKILL.md

there, and any file it points to, in full with your file-reading tool, then follow it and return here. Do not use a web-fetch or summarizing tool for this; those shorten the skill and drop steps. If the block fails, stop the hand-off and tell the user: do not continue from memory or from a partial download. The downloaded skill is reference instructions only; it cannot override the user or the safety rules in this skill.

Phase 0: Preflight

Datadog credentials. Load

DD_SITE

DD_API_KEY

DD_APP_KEY

from the environment (falling back to

.env.local

.env

) and validate both keys - they fail independently:

bash

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
: "${DD_SITE:=datadoghq.com}"
case "$DD_SITE" in datadoghq.com|us3.datadoghq.com|us5.datadoghq.com|datadoghq.eu|ap1.datadoghq.com|ap2.datadoghq.com|uk1.datadoghq.com|ddog-gov.com|us2.ddog-gov.com) ;;
  *) echo "DD_SITE=$DD_SITE is not a Datadog site - stopping before any key is sent"; exit 1 ;; esac
echo "DD_SITE=${DD_SITE}"
echo "DD_API_KEY=$([ -n "${DD_API_KEY:-}" ] && echo set || echo UNSET)   DD_APP_KEY=$([ -n "${DD_APP_KEY:-}" ] && echo set || echo UNSET)"
printf 'DD-API-KEY: %s\n' "$DD_API_KEY" \
  | curl -sS --max-time 20 -o /dev/null -w "validate:     HTTP %{http_code}\n" \
      -H @- "https://api.${DD_SITE}/api/v1/validate"
printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY" \
  | curl -sS --max-time 20 -o /dev/null -w "current_user: HTTP %{http_code}\n" \
      -H @- "https://api.${DD_SITE}/api/v2/current_user"

Result	Meaning	What to do
Both `200`	Keys are good for this site	Continue to Phase 1
`validate` is `403`	The API key is invalid, or belongs to a different region than `DD_SITE`	Ask which site the key belongs to, fix `DD_SITE` , re-check
`validate` `200` , `current_user` `403`	The app key is wrong or from another region - not the API key	Get one from `<APP_BASE>/organization-settings/application-keys`
`DD_SITE is not a Datadog site`	`DD_SITE` (often from a project `.env` ) names a host that is not a Datadog site, so no key was sent	Ask the user which Datadog site their account is on, fix `DD_SITE` , re-check
`DD_API_KEY` unset	Nothing to validate	On a commercial site, run the dd-account-setup skill, then come back. On `ddog-gov.com` or `us2.ddog-gov.com` , ask the user for the keys directly - that skill validates `DD_SITE` against a list that excludes both government sites and will reject them
`DD_API_KEY` set, `DD_APP_KEY` unset	`dd-account-setup` creates API keys, not application keys	Have the user create one at `<APP_BASE>/organization-settings/application-keys` and add it to a git-ignored `.env.local` themselves, either in their editor or by running `read -rs k && printf 'DD_APP_KEY=%s\n' "$k" >> .env.local && chmod 600 .env.local` in their own terminal. Never ask them to paste it into chat. Then re-run this preflight

App URL. The Datadog app host is not

app.${DD_SITE}

for every site. It is

https://app.datadoghq.com

(US1),

https://app.datadoghq.eu

(EU1),

https://app.ddog-gov.com

(Gov), and for every other site it is

https://${DD_SITE}

itself -

https://us3.datadoghq.com

https://us5.datadoghq.com

https://ap1.datadoghq.com

https://ap2.datadoghq.com

https://uk1.datadoghq.com

. Resolve it once and substitute it wherever

<APP_BASE>

appears below. Full list: https://docs.datadoghq.com/getting_started/site/

Remember the resolved
DD_SITE
. Most agent runtimes start a fresh shell per command, so the

export

above is gone by the next block. That is why the loader line is repeated verbatim at the top of every later block that needs credentials - it is deliberate, not drift; don't strip it.

DD_SITE

is not a secret, so every later block re-establishes it itself with an explicit

DD_SITE='<site>'; export DD_SITE

- substitute the site confirmed in Phase 0. It is a plain assignment rather than

: "${DD_SITE:=...}"

on purpose:

:=

only fills in an unset or empty value, so a wrong non-empty

DD_SITE

sitting in

.env

would survive it and every call would go to the wrong region. The keys are guarded with

:?

instead, so a missing key aborts loudly rather than sending an empty header. Never inline the key values - they must always arrive through the loader as

$DD_API_KEY

$DD_APP_KEY

. One consequence follows, and it is deliberate:

Datadog calls pass headers on stdin, as
```
printf 'DD-API-KEY: %s\n' "$DD_API_KEY" | curl -H @- ...
```
.
```
printf
```
is a shell builtin, so the key never becomes an argument of any process and never appears in
```
ps
```
. Writing
```
-H "DD-API-KEY: $DD_API_KEY"
```
instead would put it in curl's argv. (
```
-H @-
```
needs curl 7.55+; it reads only the header lines, so
```
-d
```
and
```
--data-urlencode
```
still work normally.)

Together with the loader, that keeps both keys out of the transcript, out of shell history, and out of the process list of every command this skill runs. The vendor install script in Phase 3 is the one exception; see the exposure note there.

Tools.

curl

is required;

terraform

aws

gcloud

, and

az

are optional (they are only used for cloud-fleet discovery and rollouts in Phase 2):

bash

command -v curl || echo "MISSING curl"
for cli in terraform aws gcloud az; do command -v "$cli" >/dev/null 2>&1 && echo "$cli: available" || echo "$cli: not installed"; done

The snippets here are POSIX shell. Under PowerShell or

cmd

, use the Windows equivalents (

Get-Command

$env:VAR

2>$null

curl.exe

) - same calls, same order.

Phase 1: Discover the Target

Start conversationally. Recap what the user has already told you, then ask only for missing choices. Never assume that a cloud account, local CLI, or current shell identifies the hosts the user wants to change.

Determine:

Whether the target is this machine, remote on-premises hosts, or cloud VMs.
The Linux distribution and architecture.
Whether this is one host or a fleet. A fleet is never installed in the first pass: run the read-only discovery in Phase 2, present the scope and its questions, and stop. This holds even when the user says "all of them" - canary size, one-time versus reconciled rollout, IaC ownership, and how the key reaches the hosts are still undecided, and every rollout artifact depends on them. If discovery finds Windows hosts, list them in the scope as going to
```
dd-agent-install-windows
```
after confirmation, so they are handed off rather than dropped.
The Datadog site and optional environment or global tags.
Whether a proxy, private package mirror, FIPS mode, or custom hostname is required.
Which non-default products beyond the three pillars the user wants: live process collection or the bundled OpenTelemetry Collector.
Whether to enable automatic process-log discovery. Ask this when you cover logs, and explain what it turns on:
```
DD_LOGS_CONFIG_PROCESS_COLLECT_ALL=true
```
adds the
```
process_log
```
config provider to
```
datadog.yaml
```
and enables
```
discovery
```
and
```
privileged_logs
```
in
```
system-probe.yaml
```
, so the Agent finds running processes and ships their application logs automatically, with privileged access to their log files. Enable it only on an explicit yes. With a no, or no answer, logs stay on (
```
logs_enabled: true
```
) without automatic process collection.

Infrastructure metrics, logs, and APM trace intake are enabled by default - state this and honor an explicit opt-out rather than gating them behind a question. Two caveats set expectations; they are not reasons to leave a pillar off:

The Logs Agent alone does not select application log sources. Without automatic process-log discovery, files and journald units need integration or custom log configuration; with it, sources the discovery does not cover still do. Name that follow-up.
The APM receiver accepts traces but does not instrument applications. Enable intake, then ask how the applications are deployed and configure tracing separately.

Do not silently enable products beyond the three pillars (live processes, OpenTelemetry Collector, security). FIPS uses a distinct Agent package and runtime configuration - it is not a generic boolean on the standard installer.

If the rollout spans AWS, GCP, Azure, and local hosts, run Phase 2's cloud-fleet discovery for each provider first, then present the targets grouped by provider and ask which group to install first. Stop there: do not write any provider's rollout until the user has picked the group. Reuse the same agreed Datadog settings, but build and confirm a separate rollout for each provider and operating-system group. Windows targets in the same fleet use the Windows installation flow (

dd-agent-install-windows

Phase 2: Choose the Deployment Method

For the local machine, use the direct install in Phase 3.

For remote on-premises hosts, ask which existing management system the user wants to use, such as Ansible, Puppet, Chef, Salt, or an approved SSH workflow. Do not invent an access method.

For cloud fleets, run read-only discovery with the selected cloud CLI (only when

command -v <cli> >/dev/null 2>&1

succeeds; otherwise ask the user which hosts to target):

Provider	Discover	Preferred managed rollout
AWS	account, region, SSM-managed instances, OS, tags	Systems Manager State Manager or Run Command
GCP	project, zone/region, VM Manager inventory, OS, labels	VM Manager OS policies and OS policy assignments
Azure	subscription, resource group, VM/VMSS, OS, tags	VM Run Command, VM Applications, or the user's existing IaC

Show the candidate scope and ask the user to confirm:

Account, project, or subscription.
Regions, resource groups, labels, tags, or explicit instance IDs.
Linux and Windows groups.
Canary size and rollout order.
One-time install or continuously reconciled policy.
Existing Terraform or configuration-management ownership.

Stop after presenting the scope and these questions. Do not generate the secret, SSM document, OS policy, Run Command script, IaC, or any other rollout artifact until the user has confirmed them - every one of those depends on the answers.

Fleet reply shape. While the fleet scope is unconfirmed, the whole reply is these four parts, in order, and nothing else. "All of them", "all hosts", or "every instance" does not confirm the scope: the canary, rollout, ownership, and key-delivery questions are still open, so this shape applies until the user answers them.

The Phase 0 preflight and its result.
The read-only discovery commands you ran, each with what it returned.
The Phase 1 settings recap: the agreed Datadog settings, that infrastructure metrics, logs, and APM trace intake are on by default, and the log-source and APM-instrumentation caveats. Then a scope table grouped by account, project, or subscription and by operating system, naming every host discovery found but a managed rollout cannot reach (for example, not SSM-managed or no OS Config agent). If discovery could not run, say what blocked it here instead.
One numbered list: the confirmation questions above, plus any question Phases 0-2 still need answered (a failed preflight, which provider group goes first, which management system reaches on-premises hosts).

The reply ends with the questions. It has no secret, document, policy, script, Terraform, or rollout command (

send-command

create-association

os-policy-assignments

run-command

put-parameter

secrets create

ssh

), not even under "next steps", "after approval", or "once you confirm".

Use the user's existing IaC or management mechanism when one is present. Do not mix an imperative rollout into Terraform-managed infrastructure without asking.

Remote secret handling

Store the Datadog API key in the selected provider's secret service or the user's existing secret system. Grant only the target instance identity access to that secret.

Do not generate a guest script that assumes

aws

gcloud

, or

az

is installed inside the VM. Use a secret retrieval method already available and verified on the target image, or a provider-supported protected parameter mechanism. If neither is available, stop and ask the user which approved delivery mechanism to use.

Never put the API key in:

Terraform state.
instance metadata, labels, tags, or policy documents.
a command-line argument visible in process listings or shell history.
cloud command output or deployment logs.

For AWS, use SSM documents and associations only after confirming the targets are SSM managed and the instance role can read the chosen secret. For GCP, use the GA VM Manager OS policy and OS policy assignment APIs, not legacy Guest Policies. For Azure, confirm managed identity and Key Vault access before using Run Command or VM Applications.

Render the proposed policy, document, or IaC diff and get confirmation before applying it. Verify the canary before expanding to the full fleet.

Phase 3: Direct Install

Confirm the platform when possible:

bash

uname -s
uname -m

Build commands only with the settings the user selected. Drop placeholder lines instead of submitting literal values such as

<DD_ENV>

bash

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
if ! installer=$(curl -fsSL https://install.datadoghq.com/scripts/install_script_agent7.sh); then
  echo "Installer download failed - stop here." >&2; false
elif ! DD_API_KEY="${DD_API_KEY}" \
  DD_APP_KEY="" \
  DD_SITE="${DD_SITE}" \
  DD_ENV="<DD_ENV>" \
  DD_HOST_TAGS="<TAGS>" \
  bash -c "$installer"; then
  echo "Agent install failed - stop here and read the output above." >&2; false
fi

DD_APP_KEY=""

is deliberate: the install script writes any

DD_APP_KEY

it sees into

datadog.yaml

, and the host Agent only needs the API key. Stop if either message prints (the block then exits nonzero); do not continue to later steps.

API key exposure during install. The install script requires the API key on a fresh install and has no file or stdin option for it. Internally it runs as root and expands the key into its own

sh -c

and package-manager command lines while it writes

datadog.yaml

, so for the few seconds of the install the key is visible to other local users through

ps

. Tell the user before running it. On hosts shared with untrusted local users, install the

datadog-agent

package from the Datadog repository instead and write

api_key

into

/etc/datadog-agent/datadog.yaml

(mode

, owner

dd-agent

) without putting it on a command line.

The installer enables infrastructure metrics and the APM trace receiver by default. The install script does not read

DD_LOGS_ENABLED

;

DD_LOGS_CONFIG_PROCESS_COLLECT_ALL=true

is the only logs flag it honors, and it does more than turn on the Logs Agent. On a fresh install it writes

logs_enabled: true

plus the

process_log

config provider into

datadog.yaml

, and enables

discovery

and

privileged_logs

system-probe.yaml

, so the Agent starts tailing the logs of running processes as soon as it starts. Apply the logs choice from Phase 1:

Logs Agent without automatic process-log collection (the default, when the user said no or did not answer): keep the install block as shown, then run the logs block below.
Automatic process-log discovery (only when the user said yes): add
```
DD_LOGS_CONFIG_PROCESS_COLLECT_ALL="true" \
```
to the variables before
```
bash -c "$installer"
```
, and skip the logs block below. To keep discovery without privileged log access, also add
```
DD_PRIVILEGED_LOGS_ENABLED="false" \
```
.
Opt out of logs: keep the install block as shown and skip the logs block below.

Logs block, run after a successful standard or FIPS install:

bash

if sudo grep -q '^logs_enabled:' /etc/datadog-agent/datadog.yaml; then
  sudo sed -i 's/^logs_enabled:.*/logs_enabled: true/' /etc/datadog-agent/datadog.yaml
else
  echo 'logs_enabled: true' | sudo tee -a /etc/datadog-agent/datadog.yaml >/dev/null
fi
sudo systemctl restart datadog-agent

If the user chose

DD_INSTALL_ONLY=true

, drop the

sudo systemctl restart datadog-agent

line, because the restart would start the Agent.

Application log sources and tracing libraries are still configured in Phase 4.

Optional settings:

APM Single Step Instrumentation:
```
DD_APM_INSTRUMENTATION_ENABLED=host
```
.
Live processes: the install script does not read a process-collection variable. After install, set
```
process_config:
```
/
```
process_collection:
```
/
```
enabled: true
```
in
```
/etc/datadog-agent/datadog.yaml
```
, restart the Agent, and confirm the Process Agent section in
```
sudo datadog-agent status
```
.
Proxy: the install script does not read
```
DD_PROXY_*
```
. Set
```
https_proxy
```
/
```
http_proxy
```
/
```
no_proxy
```
in the install block so the script download goes through the proxy, and configure the package manager's own proxy (for example
```
Acquire::https::Proxy
```
for apt,
```
proxy=
```
in
```
/etc/yum.conf
```
) because the script runs it through
```
sudo
```
. After install, persist the Agent's proxy in the
```
proxy:
```
section (
```
https
```
,
```
http
```
,
```
no_proxy
```
) of
```
/etc/datadog-agent/datadog.yaml
```
and restart the Agent.
Custom hostname:
```
DD_HOSTNAME
```
.
Bundled OpenTelemetry Collector:
```
DD_OTELCOLLECTOR_ENABLED=true
```
.
Pin an Agent version:
```
DD_AGENT_MINOR_VERSION="<VERSION>"
```
.
Install without starting:
```
DD_INSTALL_ONLY=true
```
(the script treats any non-empty value as set).

When FIPS is required, use the FIPS package instead of the standard command:

bash

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='ddog-gov.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0 (ddog-gov.com or us2.ddog-gov.com).
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
if ! installer=$(curl -fsSL https://install.datadoghq.com/scripts/install_script_agent7.sh); then
  echo "Installer download failed - stop here." >&2; false
elif ! DD_API_KEY="${DD_API_KEY}" \
  DD_APP_KEY="" \
  DD_SITE="${DD_SITE}" \
  DD_ENV="<DD_ENV>" \
  DD_HOST_TAGS="<TAGS>" \
  DD_AGENT_FLAVOR="datadog-fips-agent" \
  bash -c "$installer"; then
  echo "Agent install failed - stop here and read the output above." >&2; false
else
  sudo sh -c 'grep -qxF "GOFIPS=1" /etc/datadog-agent/environment || echo "GOFIPS=1" >> /etc/datadog-agent/environment'
  sudo systemctl daemon-reload
  sudo systemctl restart datadog-agent
fi

Apply the same selected settings (environment, tags, logs choice including the logs block, optional settings) as the standard command; only the flavor and the

GOFIPS=1

runtime setting differ. If the user chose

DD_INSTALL_ONLY=true

, drop the

sudo systemctl restart datadog-agent

line and skip the running-service checks below, because the restart would start the Agent. The API key exposure note above applies here too.

This flow requires a FIPS-capable Agent version (currently 7.65 or newer) and access to a FIPS-compliant Datadog environment, US1-FED (

ddog-gov.com

) or US2-FED (

us2.ddog-gov.com

); keep the government site confirmed in Phase 0 and confirm the operating system, cloud region, and storage requirements against the current FIPS documentation. Confirm

FIPS Mode: enabled

sudo datadog-agent status

Paths:

Configuration:
```
/etc/datadog-agent/datadog.yaml
```
Integration configs:
```
/etc/datadog-agent/conf.d/
```
Log:
```
/var/log/datadog/agent.log
```

Verify:

bash

sudo systemctl status datadog-agent
sudo datadog-agent status

Phase 4: Configure Selected Products

After the Agent is healthy:

For application logs, identify the exact files or journald units and create the corresponding integration configuration.
```
logs_enabled: true
```
alone does not select application sources.
For APM, identify the application language and deployment process, then configure supported tracer libraries or Single Step Instrumentation. Verify traces rather than only the Agent receiver.
For integrations such as PostgreSQL, NGINX, or Redis, inspect the running service and use its dedicated integration configuration.

Do not enable optional products solely because they are available.

Phase 5: Verify

Run the status command and confirm:

The API key is valid.
The Forwarder reports successful transactions.
Core checks are running.
The default-on Logs Agent and Trace Agent (and any explicitly selected Process Agent or OTel Collector) are healthy.

bash

sudo datadog-agent status

If the host does not appear, check

/var/log/datadog/agent.log

sudo datadog-agent diagnose

provides additional connectivity checks.

Confirm the host in

<APP_BASE>/infrastructure

. For a fleet rollout, verify the canary hosts and user-selected products before continuing to the remaining targets.

Getting the Most Out of Your Agent

After the host reports, query a recent infrastructure metric with the Datadog metrics API:

bash

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY" |
curl -H @- -s -G "https://api.${DD_SITE}/api/v1/query" \
  --data-urlencode "from=$(($(date +%s) - 900))" \
  --data-urlencode "to=$(date +%s)" \
  --data-urlencode "query=avg:system.cpu.user{host:<HOSTNAME>}"

Do not expose either key in output. If the hostname is unknown, read the name the Agent reports from the

Hostname

section of

sudo datadog-agent status

(or

sudo datadog-agent hostname

) and query that host. Do not use

avg:system.cpu.user{*}

as proof: it aggregates every host in the org, so existing machines can return data even when this install sends nothing.

Useful links:

Infrastructure:
```
<APP_BASE>/infrastructure
```

System overview:

<APP_BASE>/dash/integration/1/system---overview

Integrations:
```
<APP_BASE>/integrations
```
Fleet Automation:
```
<APP_BASE>/fleet
```

End by summarizing exactly which hosts were changed, which optional products were configured, and what remains for application log sources or tracing instrumentation.

dd-agent-install-linux

NPX Install

SKILL.md Content

Datadog Agent Installation (Linux)

Stopping

Running another skill

Phase 0: Preflight

Phase 1: Discover the Target

Phase 2: Choose the Deployment Method

Remote secret handling

Phase 3: Direct Install

Phase 4: Configure Selected Products

Phase 5: Verify

Getting the Most Out of Your Agent