Datadog is a cloud-native observability and security platform that unifies metrics, logs, traces, real-user data, and security signals into a single SaaS product. It matters because modern distributed architectures produce telemetry across dozens of services simultaneously, and Datadog correlates that data in real time — from infrastructure health to individual code-level performance. A key mental model: Datadog is not one tool but a family of loosely coupled products (APM, logs, RUM, security, profiling, synthetics, etc.) that share a common data plane and tagging system, so the value multiplies when you use them together rather than in isolation.
What This Cheat Sheet Covers
This topic spans 19 focused tables and 143 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Datadog Agent Architecture and Core Components
The Datadog Agent is the lightweight process you install on every host. Understanding its internal components is essential for troubleshooting collection gaps, configuring integrations, and estimating resource overhead.
| Component | Example | Description |
|---|---|---|
datadog-agent check nginx | • Runs integration and custom checks every 15 seconds by default • the central scheduling engine inside the Agent process | |
Payloads sent over HTTPS to intake.datadoghq.com | • Buffers metrics in memory and sends them over HTTPS • discards oldest data if the buffer limit is exceeded to cap memory usage | |
echo "custom.metric:1|c" | nc -u localhost 8125 | • Golang implementation of StatsD • listens on UDP port 8125 (or a Unix socket) and rolls up arbitrary application metrics without adding latency | |
Enabled via apm_config.enabled: true in datadog.yaml | • Separate subprocess that collects distributed traces from instrumented services • enabled by default in Agent 7. | |
process_config.enabled: true | • Collects live process data • by default only reports running containers unless fully enabled |