Datadog Ports and Endpoints

Why Ports Matter on the Datadog Fundamentals Exam

Networking and Agent configuration is a dedicated outline domain on the Datadog Fundamentals certification. Roughly one in ten exam questions expects you to distinguish inbound listeners on the host from outbound connections to Datadog, name the default ports, and recognize when a firewall rule—not a missing API key—is why telemetry never arrives. The Agent is not a passive target that Datadog polls; it is an active client that collects locally and pushes upstream over encrypted channels.

Outbound Traffic: The Primary Path

For a standard host or VM deployment, the most important network fact is simple: the Agent initiates outbound connectivity to Datadog, most commonly over TCP port 443 (HTTPS). Metrics, events, service checks, logs, and most integration payloads leave the host this way after local collection. You do not need to open inbound TCP 443 from the public internet to your Agent for normal operation, and Datadog does not SSH into your servers to pull data.

If outbound 443 to the correct site endpoints is blocked, the Agent may still run checks locally, but dashboards stay empty because nothing reaches your organization. Exam scenarios often describe "Agent healthy, integrations running, no data in Datadog"—that pattern should make you think egress filtering before you suspect key rotation.

Site selection matters alongside the port. The site parameter in datadog.yaml (or DD_SITE in containers) determines which regional hostname the Agent targets—datadoghq.com for US1, datadoghq.eu for EU, and other documented sites. Pointing the Agent at the wrong site is a configuration error, not a firewall issue, but the symptom—no data—looks similar until you verify the site value matches where your API key was created.

DogStatsD on Port 8125

DogStatsD is the Agent's local ingestion service for application-originated telemetry. By default it listens on UDP port 8125 on localhost only. Application libraries send lightweight metric packets to that listener; the Agent batches and forwards them over outbound 443. This design keeps application overhead low—you are not calling Datadog's HTTP API for every counter increment.

Two exam traps appear repeatedly:

1. Non-local traffic. If a container on another host must send DogStatsD metrics to an Agent, you typically enable dogstatsd_non_local_traffic (environment variable DD_DOGSTATSD_NON_LOCAL_TRAFFIC) and ensure UDP 8125 is reachable between sender and Agent. Leaving the default localhost binding explains "metrics work on the host but not from sidecar containers."

2. Port mismatch. If you change the DogStatsD port in Agent configuration, every client library must target the same value. The Agent does not magically retag packets arriving on the wrong port.

On the same machine, DogStatsD can also use a Unix domain socket, which avoids UDP port exposure entirely—a good pattern when security teams resist opening 8125 even locally.

APM Receiver on Port 8126

Application Performance Monitoring (APM) tracers send spans to the Agent's trace receiver on TCP 8126 by default. Unlike DogStatsD's UDP fire-and-forget model, traces use TCP so delivery is more reliable for larger payloads. If you customize apm_config.apm_dd_url or the equivalent environment variables, every tracer in the fleet must be updated to match.

Exam questions may contrast 8125 and 8126 directly: 8125/UDP = custom metrics via DogStatsD; 8126/TCP = distributed traces via APM. Mixing them up is an easy point to lose.

Configuration Surfaces You Should Recognize

Ports are set in more than one place, and the Fundamentals exam expects you to connect names to behavior:

• datadog.yaml — global Agent settings including dogstatsd_port, site, and proxy options.
• Environment variables — container-friendly overrides such as DD_DOGSTATSD_PORT, DD_APM_RECEIVER_PORT, and DD_SITE.
• Integration conf.d files — per-check instance settings (for example, which URL an HTTP check calls), separate from DogStatsD listener ports.

After changing listener ports or site values, datadog-agent restart (or the equivalent service restart) is required; a running Agent does not pick up every networking change from a reload alone.

Exam Port Traps

Fundamentals distractors sometimes swap 8125, 8126, and 443. Anchor the big three: 443 outbound, 8125 UDP DogStatsD, 8126 TCP APM.

Endpoint Direction Cheat Sheet

Application code  --UDP 8125-->  Agent (DogStatsD)
APM tracer        --TCP 8126-->  Agent (trace receiver)
Agent             --TCP 443-->   Datadog site intake (HTTPS)

Nothing in that diagram requires Datadog to open a connection back to your laptop. Reverse that arrow on an exam option and mark it wrong.

A Practical Troubleshooting Sequence

When networking is suspect, work outward from the host:

1. Confirm datadog-agent status shows the Agent running and checks executing.
2. Verify outbound TCP 443 from the host to your site's documented intake hostnames (not a random IP from a one-time DNS lookup).
3. If custom metrics are missing but host metrics work, test UDP 8125 locally with a DogStatsD client or dogstatsd-stats.
4. If traces are missing, confirm the tracer targets TCP 8126 on the Agent host.

This sequence mirrors how Datadog support triages connectivity tickets and maps cleanly to Fundamentals scenario questions.