All skills
datadog-labs avatar

/dd-apm

@9bcb3ce official

APM - install, onboard, instrument, enable, set up, configure, traces, services, dependencies, performance analysis. Use for any request involving Datadog APM setup, instrumentation (SSI, ddtrace, agent install), or analysis.

Use this Skill: https://skilld.dev/gh/datadog-labs/agent-skills/dd-apm

This session only. Nothing lands on disk.

linux-ssiagent-installSKILL.md

≈2.7k tokens on demand. Your agent reads this file only when SKILL.md points to it.

Install Datadog Agent on Linux

Before doing anything else: Fully resolve all variables in ## Context to resolve before acting. Do not begin Step 1 until every variable has a concrete value.

Triggers

Invoke this skill when the user expresses intent to:

  • Install the Datadog Agent on Linux hosts or VMs
  • Set up Datadog monitoring on bare-metal or cloud Linux instances
  • Prepare Linux hosts for APM onboarding

Do NOT invoke this skill if:

  • The Agent is already installed on all hosts — check with datadog-agent status first
  • The target is a Kubernetes cluster — use dd-apm-k8s-agent-install instead

Phase 0: Load Credentials

[ -f environment ] && source environment
echo "DD_API_KEY set: $([ -n "${DD_API_KEY:-}" ] && echo yes || echo no)"
echo "DD_SITE: ${DD_SITE:-not set}"

If DD_API_KEY is already set — proceed directly to gathering infrastructure info.

If DD_API_KEY is not set — tell the user:

Please run the following in this chat to set your credentials (the ! prefix executes it in this session):

! export DD_API_KEY=your-api-key-here
! export DD_SITE=datadoghq.com

Wait for the user to run the commands, then re-run the check above before continuing.


Phase 1: Gather Infrastructure Info

Only do this phase if the user hasn't already provided the information. If SSH credentials are known, skip to Phase 2.

Ask the user:

  1. Which hosts need the agent? Get a list of IPs or hostnames.
  2. How do I SSH to them? Get the SSH user, key path, and any jump host or bastion configuration.
  3. Do any hosts already have the Datadog Agent installed? If so, skip install for those hosts and go straight to verify-ssi.

Claude runs

Verify SSH works for each host before proceeding:

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> "hostname"

If it returns a hostname — proceed. ERROR: Connection refused or timeout — resolve connectivity before continuing.

Once SSH is confirmed, present a plan to the user before proceeding. For example:

Here's what I'm going to do:
  1. Install the Datadog Agent with SSI on: <host1>, <host2>, ...
  2. Verify each agent is running and healthy
  3. Discover services on each host that need restarting for SSI to take effect
  4. After you restart services, verify instrumentation is working

Ready to proceed?

Wait for user confirmation before starting installs.


Prerequisites

Per host — check before installing:

Claude runs

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "uname -m && cat /etc/os-release | grep -E '^(ID|VERSION_ID|PRETTY_NAME)='"

If architecture is x86_64 or aarch64, and the OS is a supported distribution (Ubuntu 16.04+, Debian 9+, RHEL/CentOS 6-9, Amazon Linux 2/2023, SUSE 12+) — proceed.

ERROR: Architecture is armv7l (32-bit ARM) or unsupported OS — stop. Datadog Agent 7 and SSI do not support this configuration.


Context to resolve before acting

Variable How to resolve
DD_API_KEY Check echo $DD_API_KEY first — if set, use it. Otherwise ask the user for their API key from Datadog UI: Organization Settings → API Keys. Never log or print the key.
DD_SITE Check echo $DD_SITE first — if set, use it. Otherwise ask the user. Default: datadoghq.com. Options: datadoghq.com, us3.datadoghq.com, us5.datadoghq.com, datadoghq.eu, ap1.datadoghq.com
SSH_KEY Ask the user for the path to their SSH private key, or check CLAUDE.md
SSH_USER Ask the user for the SSH username. Default: root
SSH_HOST Ask the user for the hostname or IP of the target host
SSH_PORT Ask the user for the SSH port. Default: 22

Phase 2: Install the Datadog Agent with SSI

Run for each host that does not already have the agent installed.

Claude runs

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "DD_API_KEY=${DD_API_KEY} DD_SITE=${DD_SITE} DD_APM_INSTRUMENTATION_ENABLED=host bash -c \"\$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)\""

DD_APM_INSTRUMENTATION_ENABLED=host causes the install script to also install datadog-apm-inject and language library packages under /opt/datadog-packages/ in one pass.

If the script completes without errors — proceed to Phase 2.

ERROR: curl: command not found:

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "apt-get install -y curl 2>/dev/null || yum install -y curl"

ERROR: Permission error — ensure the SSH user has sudo access. The install script requires root.

ERROR: Script fails with GPG key error — retry; if it persists, check the host's DNS resolution for keys.datadoghq.com.


Phase 3: Verify the Agent is Running and Healthy

Claude runs

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "sudo datadog-agent status 2>&1 | head -40"

Healthy output shows:

  • Agent (v7.XX.X) with Status: Running
  • API Keys status: API Key ending with XXXX: Valid

ERROR: command not found — installation did not complete. Re-run Phase 1.

ERROR: API key invalid — update and restart:

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "sudo sed -i 's/^api_key:.*/api_key: <NEW_API_KEY>/' /etc/datadog-agent/datadog.yaml && \
   (sudo systemctl restart datadog-agent 2>/dev/null || sudo service datadog-agent restart)"

ERROR: Agent service not running:

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "sudo systemctl start datadog-agent 2>/dev/null && sudo systemctl enable datadog-agent 2>/dev/null || sudo service datadog-agent start"

Verify APM inject packages are present on disk (not just registered):

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "ls /opt/datadog-packages/ && sudo datadog-installer status 2>/dev/null | grep apm | head -10"

If /opt/datadog-packages/datadog-apm-inject exists — injection is available.

ERROR: Directory missing or empty — datadog-installer status may show the package as registered while its directory is actually empty (stale registration). Reinstall:

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "sudo datadog-installer remove datadog-apm-inject && \
   DD_API_KEY=${DD_API_KEY} DD_SITE=${DD_SITE} DD_APM_INSTRUMENTATION_ENABLED=host bash -c \"\$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)\""

Verify hostname registration — the Agent must resolve and register its hostname for the host to appear in Datadog. DNS lookup failures are common in containers and minimal VMs:

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "sudo datadog-agent status 2>&1 | grep -iE '^\s+Hostname' | head -3"

If Hostname: <some-name> is shown — hostname resolved. Record this as DD_HOSTNAME for all subsequent steps.

ERROR: Hostname: (none) or any DNS resolution error — the agent can't resolve its own FQDN. Fix by setting the hostname explicitly in datadog.yaml:

# Read the actual system hostname
ACTUAL_HOSTNAME=$(ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> "hostname")

# Append to datadog.yaml only if not already set
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "grep -q '^hostname:' /etc/datadog-agent/datadog.yaml || \
   echo \"hostname: ${ACTUAL_HOSTNAME}\" | sudo tee -a /etc/datadog-agent/datadog.yaml"

# Restart the Agent
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "sudo systemctl restart datadog-agent 2>/dev/null || sudo service datadog-agent restart"

# Confirm hostname is now registered
ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "sudo datadog-agent status 2>&1 | grep -iE '^\s+Hostname' | head -2"

Phase 4: Discover Services That Need Restarting

SSI only injects into processes at startup. Existing processes keep running uninstrumented until restarted. Discover what's running so the user knows what to restart.

Claude runs

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> \
  "sudo ss -lntp 2>/dev/null || sudo netstat -tlnp 2>/dev/null || cat /proc/net/tcp"

For each application-level listener (ignore sshd, systemd, chronyd):

ssh -o StrictHostKeyChecking=no -i <SSH_KEY> <SSH_USER>@<SSH_HOST> "
# Command line of the process
sudo cat /proc/<PID>/cmdline | tr '\0' ' '
# Service manager (may not be available in all environments)
sudo systemctl status <PID> 2>/dev/null | head -3 || true
# Parent process
PPID=\$(sudo awk '/PPid/ {print \$2}' /proc/<PID>/status)
sudo cat /proc/\$PPID/cmdline | tr '\0' ' '
"

Present findings to the user:

I found the following application services on <host>:

  Port 8080 — PID 1234 — /usr/bin/python3 /app/server.py
    Managed by: systemd unit flask-app.service

  Port 3000 — PID 5678 — node /app/server.js
    Managed by: supervisord

These services need to be restarted for Datadog SSI to inject into them.
Restart them however is appropriate for your environment, then let me know
and I'll verify the instrumentation.

Do not offer to restart services. Do not restart services unless the user explicitly asks.


Done

Exit when ALL of the following are true:

  • Agent running on each target host (datadog-agent status shows Running, API key valid)
  • /opt/datadog-packages/datadog-apm-inject exists on disk on each host
  • User has been informed which services need restarting
  • User has confirmed they are ready to restart services

Automatically proceed to enable-ssi (if services need UST labels configured) or verify-ssi (if services have already been restarted) — do not ask the user for permission.


Security constraints

  • Never write a raw API key into any file or chat message
  • Never store DD_API_KEY in shell history — pass it inline in the SSH command only
  • If the user's API key appears in any output, redact it before displaying
  • Always confirm before restarting production services

Source: SKILL.md on GitHub

1 warning2d5 checks · Risk SAFE
  • Gen Agent Trust Hub2d

    The skill facilitates the installation, configuration, and troubleshooting of Datadog APM for Kubernetes and Linux environments. It uses official Datadog installation scripts and a CLI tool ('pup') from the 'datadog-labs' GitHub organization. It requires administrative privileges (sudo) and SSH access to perform system-level instrumentation and configuration. All behaviors align with its documented purpose as a Datadog Labs utility.

  • Socket2d

    2 alerts: gptAnomaly

  • Snyk2d

    Risk: LOW · No issues

  • Runlayer6mo

    1/1 file flagged

  • ZeroLeaks5mo

    Score: 93/100 · 2 sections analyzed

Signed by skilld at 9bcb3ce. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub yesterday.

Activeupdated 4 months ago
alwaysApply
true
Other metadata
metadata
{
  "version": "1.1.0",
  "author": "datadog-labs",
  "repository": "https://github.com/datadog-labs/agent-skills",
  "tags": "datadog,apm,tracing,performance,distributed-tracing,dd-apm,install,onboarding,instrumentation,ssi,agent",
  "globs": "**/ddtrace*,**/datadog*.yaml,**/*trace*"
}
  • Performance
  • datadog
  • apm
  • tracing
  • distributed-tracing
  • instrumentation
  • ddtrace
  • kubernetes
  • linux
  • service-remapping

README badge

README badge for datadog-labs/agent-skills/dd-apm

Installs the Datadog agent, enables single-step instrumentation (SSI) for automatic tracing, and provides commands to search traces and view service maps. Use this skill for any Datadog APM setup, onboarding, or performance analysis task on Kubernetes, Linux, or to rename services in APM.

Generated from the current SKILL.md.

Does this skill handle both Kubernetes and Linux host APM setup?
Yes. The skill routes to Kubernetes-specific sub-skills (k8s-ssi) when a cluster orchestrator is mentioned, and Linux-specific sub-skills (linux-ssi) for single hosts or VMs with no orchestrator.
Can I use this skill to rename services in Datadog?
Yes. The skill includes a service-remapping sub-skill that rewrites service names at ingestion time without requiring a deployment rollout.
Does this skill set up Single Step Instrumentation (SSI)?
Yes. SSI auto-instrumentation is covered in both the k8s-ssi and linux-ssi sub-skills; SSI requires no code changes and is enabled via agent installation flags or init container injection.
What if my request doesn't match Kubernetes, Linux, or service remapping?
The skill supports trace searching, service analysis, and metrics queries via pup commands. If your request still doesn't fit, the skill asks you to clarify rather than guessing a workflow.
Do I need to install Datadog Pup separately?
Yes. Datadog Labs Pup must be installed before using this skill; setup instructions are in the main agent-skills repository.

Generated from the current SKILL.md. These answers refresh after source changes.