Derive Datadog Metrics from Logs Without Changing Code

You already have the logs; you need the metric

Your web service is emitting 5xx errors, and the on-call engineer wants an alert. The application team cannot instrument the code with DogStatsD before the next release window, but access logs are already shipping to Datadog. That gap is where log-based metrics fit: they convert ingested log lines into custom metrics without application changes.

The trade-off is immediate. Log-based metrics are billed as custom metrics, they appear after ingestion and pipeline lag, and every dimension you select becomes a metric tag. A poorly chosen dimension—such as a raw URL or user ID—can inflate cardinality and your bill before you notice. Use log-based metrics for fast, retroactive signals, then verify cost and cardinality before you build monitors on them.

What a log-based metric actually is

A log-based metric is an aggregate Datadog custom metric built from a log filter query. You choose a measure—count, distinct count of an attribute, or a numeric aggregation such as sum, average, min, max, or percentile—and one or more dimensions. Each dimension becomes a tag on the resulting metric, so you can slice by env, service, or version in dashboards and monitors.

Because the result is an aggregate, you lose the ability to pivot from a metric point back to the individual log lines that produced it. Log retention and indexing remain separate decisions from metric generation. Keeping dimension tags consistent with unified service tagging (service, env, version) helps the metric correlate cleanly with traces, RUM, and other metrics.

Worked example: 5xx errors from access logs

Suppose your nginx access logs include @http.status_code and @url.path. You want an error count by environment, not by every unique URL.

In the Datadog app, open Logs configuration and create a generated metric. Use a narrow filter so you only pay for the metric volume you need:

service:web AND source:nginx AND @http.status_code:[500 TO 599]

Set the measure to Count. Select dimensions carefully:

• env — low cardinality, safe to tag.
• path_group — a normalized path pattern you derive in a log pipeline, not @url.path raw.

Avoid using @url.path, @user.id, or full error messages as dimensions. Those attributes are high-cardinality: each unique value creates a new time series, which drives custom-metric cost.

Where to run: Datadog web UI, Logs configuration area. Required permissions: a role that can manage log pipelines and generated metrics. Expected check: after a few minutes of ingestion lag, open Metrics Explorer and confirm the metric appears with only the tags you selected. Risk: if you add a high-cardinality dimension, the metric can generate many time series and increase usage before you remove it.

Trade-offs versus DogStatsD

Factor	Log-based metric	DogStatsD
Code changes	None	Application instrumentation required
Latency	Ingestion plus pipeline lag	Near real time
Retroactive use	Works on logs already ingested	Only from emit time forward
Per-event drilldown	Not available from the metric	Not available from the metric either
Billing	Custom metric usage	Custom metric usage

Choose log-based metrics when you cannot change shipping code or need a signal from historical logs. Choose DogStatsD or APM when you need sub-minute alerting, per-request context, or you want to decouple metrics from log volume.

Verify before you alert

1. Create a test metric with a narrow filter, such as 5xx errors for one service.
2. Compare its count over a fixed five-minute window against a Datadog Logs search using the same query. Allow several minutes for ingestion lag before judging a mismatch.
3. Open the metric in Metrics Explorer. Confirm the tag keys and values match the log attributes you selected, with no unexpected high-cardinality values.
4. Check Plan & Usage or usage attribution for custom-metric counts before and after enabling the metric.
5. Build a dashboard tile and a monitor on the metric. Trigger a known condition, such as a synthetic 5xx, to observe alert timing, then lengthen the evaluation window to absorb ingestion lag.

Creating a generated metric changes account state. If you need to roll it back, disable or delete the metric in Logs configuration; new points stop accruing, but prior usage may still appear in billing reports.

Start with one derived signal

Generate both a request-count metric and an error-count metric from the same access-log filter. Derive availability as a formula—errors divided by total—in a dashboard or SLO instead of tagging every status code as a dimension. Review custom-metric usage after seven days. If the signal needs to be faster or more granular than logs allow, instrument the application rather than forcing logs to serve as metrics.

Datadog UI labels, API field names, quotas, and pricing change over time. Confirm current configuration surfaces and model cost from your own Plan & Usage data before rolling this out to production.