Agent Commands and Flare

Quick Answer: Start with datadog-agent status for a broad health view. Use configcheck to see loaded configs, check <name> to test one integration, and flare to send a sanitized diagnostic bundle to Datadog Support when local tools are not enough.

The Troubleshooting Datadog domain on the Fundamentals exam expects you to know which Agent subcommand answers which question — not how to script a full SRE runbook. When metrics stop arriving or an integration shows red in Fleet Automation, the exam rewards a disciplined sequence: confirm the Agent process is healthy, verify what configuration it actually loaded, test the failing check directly, then escalate with a flare if Support needs deeper context.

Why Agent Commands Matter on the Exam

Datadog publishes more than a dozen datadog-agent subcommands, but the Fundamentals outline emphasizes the ones operators reach for daily. Scenario questions often describe a symptom ("Redis metrics missing after a Kubernetes deploy") and ask which command gives the fastest signal. The trap is picking a plausible-sounding but wrong subcommand such as import, launch-gui, or encrypt.

Essential Subcommands

On the Exam: status answers "is the Agent running and what does it think about my checks?" configcheck answers "what YAML did the Agent actually load?" That distinction is the heart of many Autodiscovery troubleshooting stems.

Reading datadog-agent status

Run sudo datadog-agent status on Linux (or the platform equivalent). The output is long, but several sections appear repeatedly in exam scenarios:

1. Agent section — version, PID, uptime, and whether the API key is configured.
2. Checks section — per-integration instance names, last run time, and OK/WARNING/ERROR state.
3. Forwarder — pending payloads and retry behavior; useful when data looks healthy locally but never reaches the site.
4. Logs Agent / DogStatsD — whether log collection and custom metrics listeners are active.

If status shows a check in ERROR, your next step is usually datadog-agent check <integration_name> for the exact traceback, not a dashboard refresh.

configcheck and Autodiscovery

datadog-agent configcheck prints all loaded and resolved configurations. This is the command to run when:

• You edited conf.d/nginx.d/conf.yaml but nginx metrics never appeared.
• A Kubernetes Autodiscovery template should match a Redis pod but does not.
• You suspect the Agent is reading an unexpected file from conf.d/.

A classic Autodiscovery message is "No service found with this AD identifier" — meaning the template's identifier (labels, annotations, or container name) did not match any running workload. The fix is alignment between the template and the actual service metadata, not regenerating API keys.

Testing One Check: check

sudo -u dd-agent datadog-agent check <check_name> executes a single integration outside the normal scheduler interval. Integration documentation lists the exact check name (often matching the integration folder under conf.d/). This command is ideal when status lists the check but you need the raw Python error or connection refusal details.

The Flare Workflow

When status, configcheck, and log review still leave the root cause unclear, datadog-agent flare collects a diagnostic archive for Datadog Support.

Key flare facts for the exam:

• Flare gathers configuration files and Agent logs into a zip/tar archive (initially under /tmp on Linux).
• Sensitive values are scrubbed — API keys, proxy passwords, SNMP community strings, and similar secrets.
• The CLI prompts for confirmation before uploading; you can inspect the archive locally because the Agent is open source.
• You may associate the flare with an existing Zendesk ticket number or let Support create one.
• With Fleet Automation and Remote Configuration, Support can request a remote flare from the Datadog UI — useful when SSH to the host is impossible.

Common Trap: A screenshot of Host Map or a dashboard export is not a flare. Support needs the Agent-side bundle produced by the flare subcommand (or a manual copy of that archive if upload fails).

Recommended Troubleshooting Sequence

1. datadog-agent status          → Is the Agent up? Which checks fail?
2. datadog-agent configcheck     → Did the expected YAML load?
3. datadog-agent check <name>    → What error does the integration return?
4. Review Agent logs (+ debug)   → Deeper runtime detail (next section)
5. datadog-agent flare           → Escalate to Support with sanitized bundle

Worked Scenario: Missing Integration Metrics

A team enables the PostgreSQL integration by adding conf.d/postgres.d/conf.yaml, waits ten minutes, and sees no new metrics. The exam asks for the best next command after confirming the Agent service is running.

• status — confirms whether a postgres check instance exists and its last error.
• configcheck — proves the Agent parsed the new file (if absent, suspect YAML syntax, wrong path, or missing restart).
• check postgres — surfaces authentication or socket errors immediately.

Only after those steps does flare make sense — for example, when connectivity looks fine locally but payloads still never arrive at the org's site.

Commands You Should Recognize but Rarely Need First

import, launch-gui, encrypt, and jmx appear as distractors — they serve migration, GUI, secrets, or Java workflows, not first-line metric troubleshooting. Knowing each subcommand's purpose beats memorizing every flag.