2.3 Running the Agent and Status

Running the Agent as a Production Service

Installing the Datadog Agent is only half the job — the Fundamentals exam expects you to run, inspect, and manage it like an operations engineer. On Linux the Agent is a systemd unit (datadog-agent); on Windows it is a Windows service. In both cases the goal is identical: keep a background daemon collecting telemetry through reboots and user logouts without requiring an interactive login session.

After any install or configuration change, confirm the service is active before debugging Datadog itself. On systemd hosts, systemctl status datadog-agent shows whether the process is running. If the service fails immediately, the next step is almost never the Datadog UI — it is Agent logs and the CLI diagnostics covered below.

Configuration changes to datadog.yaml or integration conf.yaml files do not hot-reload automatically in most workflows. Restart the Agent after editing those files so the running process re-reads configuration. This pattern appears repeatedly on the exam: an engineer edits an integration, sees no new metrics, and forgot to restart. Installing or removing an official integration package with datadog-agent integration likewise requires a restart before new checks execute.

The datadog-agent CLI: Status First

The datadog-agent command family is your on-host toolkit. For Infrastructure Development, four commands matter most:

Start with datadog-agent status. It is the standard first-stop view of Agent health and summarizes whether the forwarder can reach Datadog, which checks are scheduled, and whether major subsystems (DogStatsD, trace Agent, log Agent) are enabled. When an integration is configured but data is missing, scroll to the Checks section of status output — Datadog's integration docs explicitly recommend this validation step.

Use datadog-agent configcheck when Autodiscovery or multiple conf.yaml fragments make it unclear which configuration the Agent resolved. It answers the question "What did the Agent actually load?" — invaluable when a typo in YAML means your edit was silently ignored.

datadog-agent hostname confirms identity reporting before you chase metric gaps in the UI. It is not a substitute for status, but it is the fastest way to verify hostname overrides in containerized environments.

Managing Official Integrations from the CLI

On supported Agent versions, datadog-agent integration manages packaged integrations:

• install — add an official integration package
• remove — uninstall an integration
• show — display installed integration metadata
• freeze — pin integration versions for reproducible hosts

Custom integration development uses datadog-agent integration create to scaffold a new check, but Fundamentals focuses on installing and enabling existing integrations rather than authoring new ones.

The typical enablement sequence on a host-based Agent:

1. Install the integration package if it is not already present.
2. Create conf.d/<integration>.d/conf.yaml from the shipped example.
3. Restart the Agent.
4. Run datadog-agent status and confirm the check appears under Checks.

Skipping step 3 is the most common operational mistake, and the exam knows it.

Interpreting Status Output

Think of status output in layers:

1. Agent version and hostname — confirms you are on the expected host identity.
2. Forwarder / API keys — surfaces intake errors, wrong site, or key rejection.
3. Checks — lists each integration instance, last run time, and errors.
4. DogStatsD / APM / Logs — shows whether local listeners are up.

If status reports healthy checks but the Datadog UI is empty, suspect site misconfiguration or org mismatch before rewriting integration YAML. Local health plus missing UI data is a classic site or api_key problem, not a broken check definition.

For deeper investigation — log locations, flare bundles, verbose debug modes — see the Troubleshooting chapter. Infrastructure Development stops at knowing which command to run first and what restart accomplishes.

Service Control Quick Reference

Environment-variable-based configs (DD_API_KEY, DD_SITE, DD_TAGS) follow the same rule: after changing them at deploy time, the Agent process must restart to pick up new values.

Exam Scenarios

• "Which command first?" → datadog-agent status.
• "Confirm a new integration loaded" → status, Checks section (or configcheck for resolved YAML).
• "Edited conf.yaml, still old behavior" → restart the Agent.
• "Manage packaged integrations" → datadog-agent integration subcommands.

Treat the Agent as a managed service with a documented CLI — not a black box that only Datadog Support can inspect. That mindset matches how Datadog expects certified practitioners to work on real infrastructure.

Logs, Version Checks, and Upgrade Awareness

When systemctl status is not detailed enough on Linux, Agent logs under /var/log/datadog/ provide the stack trace behind a failed start. YAML syntax errors in datadog.yaml — especially tabs or inconsistent indentation — prevent the Agent from parsing configuration and cause immediate exit. The Fundamentals exam cross-references Chapter 1 config-file rules here: a valid integration URL in an invalid YAML file still produces a dead Agent.

For integration debugging beyond status, datadog-agent check <integration> runs a single check interactively and prints metric payloads or errors to the terminal. This is slower than status for broad health checks but faster for isolating one failing database instance when five conf.yaml files exist.

Restart reloads configuration; upgrading installs a new Agent package. Exam scenarios usually test restart semantics after config edits.