Networking Basics for Observability

Networking Is the Hidden Prerequisite

Even "computer fundamentals" questions about networking are really about whether telemetry can leave your environment and reach Datadog. You might never configure a corporate firewall on exam day, but you will see scenarios about blocked egress, proxy variables, wrong site URLs, or DogStatsD ports. This section teaches the portable concepts; Chapter 3 maps them to Datadog's published port and IP lists.

IP Addresses: Public, Private, and Why Both Appear

An IP address uniquely identifies a host on a network. IPv4 addresses such as 203.0.113.10 are routable on the public internet. Private addresses defined in RFC1918—10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16—are used inside data centers and home networks. NAT translates private hosts outbound so they can reach SaaS endpoints like Datadog intake servers.

For observability, remember:

• The Agent on a private subnet still needs a default route and allowed egress to reach Datadog's endpoints on the public internet (unless you use a dedicated proxy architecture).
• Metadata tags such as availability-zone or region help group hosts; they do not replace the need for actual network connectivity.

DNS: Names Before Connections

The Domain Name System (DNS) translates names like intake.datadoghq.com into IP addresses. If DNS fails, the Agent cannot resolve where to send payloads—even if the firewall is wide open.

Symptoms of DNS trouble:

• Agent logs show name resolution errors
• curl or telnet tests to a hostname fail but work to a literal IP (when permitted)
• Intermittent failures when secondary DNS servers are unreachable

Corporate environments sometimes use split-horizon DNS or internal DNS forwarders. Exam questions may describe a host that reaches the internet for browsing but fails Agent checks because server DNS search domains differ from desktop defaults.

TCP vs UDP and the Role of Ports

TCP (Transmission Control Protocol) establishes a reliable connection with acknowledgments. HTTPS—HTTP over TLS—rides on TCP port 443. The Datadog Agent sends most telemetry to Datadog backends over HTTPS (TCP 443).

UDP (User Datagram Protocol) is connectionless and lightweight—ideal for high-volume, latency-sensitive custom metrics where occasional loss may be acceptable. DogStatsD defaults to UDP port 8125 on localhost (or a configured bind address). Applications fire-and-forget metric packets to the Agent; the Agent aggregates and forwards them.

A classic trap: candidates think opening inbound 443 on the monitored host allows monitoring. Usually the Agent initiates outbound connections to Datadog; you allow egress, not publish your servers to the internet.

Firewalls, Proxies, and TLS

Enterprise networks often require an HTTP/HTTPS proxy for outbound traffic. The Agent supports proxy settings in configuration and via variables such as DD_PROXY_HTTP. Without them, the Agent may time out while browsers on the same subnet work—because browsers auto-read system proxy PAC files the Agent does not.

TLS encrypts traffic between Agent and Datadog. Certificate validation failures happen when:

• A SSL inspection proxy re-signs traffic without trusting the corporate root on the host
• The system clock is wrong (certificates appear expired)
• An outdated Agent cannot negotiate required cipher suites (rare today but mentioned in legacy troubleshooting tales)

Local vs Remote Listeners

Some Agent components listen locally for application traffic (DogStatsD, APM trace intake on localhost ports). Others are purely outbound clients. When an exam stem says "application cannot send custom metrics," check whether:

1. The app targets the correct IP:port for DogStatsD
2. A local firewall (iptables, Windows Firewall) blocks loopback UDP
3. The Agent DogStatsD listener is disabled in config

This is different from "Agent cannot reach Datadog cloud," which is an egress problem.

Basic Connectivity Troubleshooting Chain

Use this ordered checklist mentally on scenario questions:

1. Can the host resolve the intake hostname? (DNS)
2. Can the host route to the internet or proxy? (routing table, default gateway)
3. Is outbound 443 (or proxy equivalent) allowed? (firewall/security group/NACL)
4. Does TLS succeed? (proxy cert trust, clock skew)
5. Are Datadog-specific endpoints correct for your site? (datadoghq.com vs datadoghq.eu)

Commands like ping may be blocked by policy and are not definitive; DNS lookup and HTTPS curl tests to the intake domain are more relevant for Agent issues.

Link to Observability Outcomes

Networking fundamentals explain gaps in charts, not just CLI curiosity. If DogStatsD packets never reach the Agent, custom metrics vanish while host integrations still appear—because integrations run inside the Agent process, but DogStatsD is a separate listener path. If HTTPS egress fails, everything stops.

Tags like env:prod do not fix connectivity; they only organize data once it arrives. The exam rewards candidates who separate transport problems from configuration typos from tag cardinality mistakes.

Study Bridge to Chapter 3

Memorization of every Datadog IP range is less important than knowing why allowlisting exists: some regulated networks default-deny outbound traffic. Chapter 3 provides Datadog's published IP ranges and ports for Agent, APM, and container autodiscovery. Return here if a question feels like pure networking—chances are it is testing DNS, TCP vs UDP, or outbound HTTPS concepts you learned in this section.