Application Performance Monitoring
Traces, spans, and services
APM builds distributed traces from spans. A trace is a tree of spans; the first span is the entry point, and each downstream call adds a child span with its own duration. Instrumentation comes from Datadog tracing libraries (auto-instrumentation for common frameworks) plus manual spans for custom logic. Every span should carry env, service, and version through unified service tagging (DD_ENV, DD_SERVICE, DD_VERSION), which is what links traces to deployments, logs, and profiles.
Sampling and retention
The tracer and Agent apply head-based sampling to control volume - by default the Agent keeps roughly ten traces per second per service/env combination, and the tracer can modulate rates. Traces are retained in full for 15 minutes for search and can then be kept by retention filters (formerly App Analytics) so a chosen percentage or tag-based subset stays indexed for 15 days. A common exam trap conflates "sampled" with "indexed": sampled traces still drive the Service Map, trace metrics, and error rates, while only indexed spans are searchable later.
Profiling, errors, and deployment tracking
Continuous Profiler collects CPU, wall-clock, allocation, and exception profiles attached to the same service tags. Error Tracking aggregates exceptions across traces and logs, and deployment tracking correlates version changes with error and latency shifts on the Service Map.
Worked example: a service emits env:prod, service:checkout, version:2.4.1 from the tracer; the same tags appear on its logs and profiles, letting you jump from a slow span to the matching logs and to the version that introduced the regression.