APM

What APM shows you - traces, services, and resources

At the center of Datadog APM is distributed tracing. It records how a request the application received flowed through the system, and you can search and analyze traces one by one in the Trace Explorer. Aggregated performance is viewed on the Service page and the Resource page, where you can track service health, performance indicators, and changes before and after a deployment (as of August 2026; source: Datadog APM documentation). Whereas Infrastructure Monitoring takes the viewpoint of the host as a "box," APM takes the viewpoint of the "processing" that passes through the box, and the two complement each other. The concept of a trace itself is organized in the trace entry of the glossary.

Getting started with instrumentation - supported languages and two approaches

To capture traces, the application must be instrumented (the SDK embedded). The official SDKs support Java, Python, Ruby, Go, Node.js, PHP, C++, Rust, .NET Core, .NET Framework, Android, and iOS (as of August 2026; source: list of supported libraries). There are broadly two approaches to adoption: Single Step Instrumentation automatically embeds the SDK with a single command without changing code, while code-based custom instrumentation adds calls to the tracing API in your code to create your own spans. The two play different roles, "a means of installing the SDK" versus "a means of controlling spans in fine detail," so they can be used together. Note that the setup assumes the Agent receives the transmitted traces, so the flow is to finish installing the Datadog Agent first. If you prefer vendor-neutral instrumentation, the official documentation also describes a path for sending data instrumented with OpenTelemetry to Datadog.

How to read a trace

A single trace is made up of the chain of processing units (spans) that the request passed through. There are two entry points for reading it. When you want to investigate an individual slow request, open the relevant trace from the Trace Explorer and check which span consumed the time. When you want to grasp the overall trend, enter from the Service page and see which resources (units such as endpoints or queries) of which service concentrate the latency or errors. Moving back and forth between "the individual case" and "the aggregated trend" is the basic way to read APM, and in incident investigation the standard order is to narrow down from the trend to a suspicious resource and then confirm with an individual trace at the end.

Billing has two tiers - host billing and span ingestion volume

APM billing has two tiers, a per-host base charge and span ingestion and retention volume, and this is the classic spot for billing accidents. The structure of the official pricing as of August 2026 is as follows.

What matters is the mechanism of the free allotment: ingested spans come with 150 GB per APM host per month, and Indexed Spans with 1 million spans per host per month (15-day retention), and these allotments are pooled across all APM hosts. The official FAQ gives the example that with 2 hosts, one at 250 GB and the other at 50 GB for a total of 300 GB, there is no additional charge. In other words, only the amount exceeding the total pool of "host count x allotment" is metered, so be aware that a configuration with a small number of high-traffic hosts easily overflows the allotment.

Sampling design - capture everything, or narrow it down

Span ingestion volume can be adjusted through Ingestion Controls as sampling rates per service and per resource, and the spans kept long-term can be chosen with retention filters (the mechanism for specifying which spans are subject to 15-day retention, as of August 2026). As a design decision, the sensible order is to ingest close to everything in the early stage of adoption to grasp the actual state of the whole system, and once the breakdown of ingestion volume becomes visible, start narrowing from "services with high volume but low investigative value." If you narrow aggressively from the start, traces of latency or errors that occur only rarely are not captured, and you lose your clues right when you want to investigate. Conversely, if you keep ingesting everything permanently, the amount over the allotment in the previous section quietly piles up as per-GB metered charges. The goal of sampling design is a state where you can put into words "which requests of which service to keep, and for what purpose."

Points to note for Lambda and container environments

Per-host billing does not apply as-is in environments where no resident host exists. AWS Lambda has its own billing unit: as of August 2026, it is 10 dollars per 1 million traced invocations with an annual commitment (15 dollars on-demand), with 1 invocation defined as 1 top-level span. Container platforms such as AWS Fargate also have a separate price per traced active instance (6 dollars with an annual commitment, 9 dollars on-demand) (source: Datadog pricing page). When estimating APM for a serverless-centered architecture, unless you calculate with these SKUs rather than the host billing table, the estimate and the invoice will diverge widely. For groups of Lambda functions with many invocations, the "per 1 million invocations" unit price comes into play, so choosing which functions to trace effectively becomes your cost design.

Where APM fits and where it does not

APM is most effective in architectures where multiple services and databases work together and you want to isolate "where the cause of the slowness is." Conversely, if you only want to monitor a monolith running on a single host as-is, it is worth considering first whether Log Management and Infrastructure Monitoring are enough. Looking at the unit prices as of August 2026, APM is 31 dollars per host with an annual commitment, which works out to roughly double the 15 dollars of Infrastructure Monitoring Pro added on top. The decision axis is whether the reduction in investigation time justifies this difference. On the other hand, in organizations where multiple teams spend hours cross-checking logs at every incident, the value of tracing cause and effect with a single trace quickly recovers the price difference.