Where does datadog.yaml live?

On most Linux hosts it sits at /etc/datadog-agent/datadog.yaml. The agent reads it on start and on reload. In containers you usually pass the same keys as DD_ environment variables instead of a file.

Why use a placeholder for the API key?

Committing a real API key leaks it into version control and grants write access to your Datadog account. The generated file references DD_API_KEY so you inject the secret through the environment or a secrets manager at runtime.

What is unified service tagging?

Setting env, service, and version consistently across the agent, traces, logs, and metrics so Datadog can correlate them. It is the foundation for navigating from a slow trace to its related logs and host metrics.

Which site should I pick?

Match the region where your Datadog organization was created — US1, US3, US5, EU, or AP1. Sending to the wrong site means the agent authenticates against an endpoint that does not hold your account and data never appears.

What does DogStatsD do?

It is a bundled StatsD server, by default on UDP port 8125, that accepts custom application metrics with tags. Enable it when your code emits counters, gauges, or histograms through a StatsD client.

Datadog Agent Configuration Builder

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

A datadog.yaml tailored to what you monitor

The Datadog Agent is configured by a single datadog.yaml, but most of the file is boilerplate you only touch to enable a feature. This tool generates exactly the sections you need — site, tagging, logs, APM, processes, and DogStatsD — with the API key left as an environment placeholder.

How it works

The agent authenticates with an API key and sends data to a regional site endpoint such as datadoghq.com or datadoghq.eu; choosing the wrong site means data silently never arrives. The builder writes api_key: ${DD_API_KEY} so the secret is injected at runtime, never committed.

Unified service tagging ties everything together through env, service, and host tags, letting Datadog correlate a trace with its logs and metrics. Each feature is a self-contained block: logs_enabled plus a logs_config turns on log collection, apm_config.enabled opens the trace receiver on port 8126, process_config.process_collection powers the live process view, and use_dogstatsd exposes a StatsD server on port 8125 for custom application metrics. Toggling a feature off simply omits or disables its block so the agent skips that pipeline.

Tips and example

Keep tags as key:value pairs so they filter cleanly in dashboards, and set env once at the top so traces and metrics inherit it. A minimal log-and-trace config:

api_key: ${DD_API_KEY}
site: datadoghq.com
env: production
tags:
  - team:platform
logs_enabled: true
apm_config:
  enabled: true
  receiver_port: 8126

Reload with datadog-agent reload or restart the service after editing, and confirm with datadog-agent status that each enabled check reports OK.