The log DDU (Davis data unit) measures what ingesting, storing and querying logs costs under Dynatrace’s legacy licence model. For an SRE team, the bill does not depend on the number of lines but on three volumes in gigabytes: what comes in, what stays stored and what queries read.

This article explains the calculation described in the documentation, checks it against the official example, then shows how to read log consumption through the Metrics API. It applies to Dynatrace SaaS only, in environments activated for Grail (Log Management and Analytics). Nothing here applies to Dynatrace Managed, whose classic Log Monitoring follows a different model that this article does not cover.

In brief

  • The DDU model for Log Management and Analytics rests on three dimensions: Ingest & Process, Retain and Query, all measured in GB.
  • According to the documentation, the weights are 100.00 DDUs per GB ingested, 0.30 DDUs per GB retained per day and 1.70 DDUs per GB read.
  • The model is labelled « legacy »: all new Dynatrace contracts are signed under DPS, and these pages must not be used to estimate a DPS price.

Log DDU: what the three dimensions measure

According to the « DDUs for Log Management and Analytics » page of the Dynatrace documentation, total consumption is the sum of three products: volume times weight, for each dimension.

Log Management and Analytics DDU weights: 100.00 DDUs per GB for Ingest and Process, 0.30 per GB per day for Retain, 1.70 per GB for Query

Ingest & Process

This dimension counts the raw data sent to Dynatrace, after decompression and before enrichment and transformation. It covers delivery through OneAgent or the log ingestion API (via ActiveGate), topology enrichment, transformations (adding, dropping and masking attributes, extraction) and filtering. Filtering consumes DDUs at ingestion but not for retention: a log dropped here is never stored.

Retain

Retained volume is the data saved after parsing, enrichment, transformation and filtering, but before compression. The documentation warns that enrichment can multiply volume by 2 or more. Its example uses a factor of 1.8. Retention periods available for log buckets range from 10 days to 10 years (10, 15, 35 days by default, 95, 372, 462, 1,102, 1,832, 2,562 and 3,657 days).

Query

A query consumes according to the uncompressed volume read during execution, including sampled data. The page lists the Logs & Events viewer, custom DQL queries, unified analysis pages, API queries and dashboard tiles based on logs, which rerun a query on every refresh. An active query consumes even if no result is returned: cancelling unneeded queries avoids paying for nothing.

Calculating consumption: the official example

The documentation walks through a scenario: 500 GB of logs per day, enrichment of 1.8, 35 days of retention and 25 TB read per day by queries. Each step can be checked by hand.

Documented DDU calculation: 1,500,000 DDUs for ingestion, 283,500 for retention and 1,275,000 for queries, 3,058,500 DDUs per month in total

  1. Ingestion: 500 GB × 30 days = 15,000 GB; × 100.00 = 1,500,000 DDUs per month.
  2. Retention: 500 GB × 1.8 = 900 GB per day; × 35 days = 31,500 GB stored; × 0.30 = 9,450 DDUs per day, or 283,500 per month after the 35-day ramp-up.
  3. Queries: 25,000 GB × 30 days = 750,000 GB; × 1.70 = 1,275,000 DDUs per month.
  4. Total: 3,058,500 DDUs per month.

For the same data kept for a year, the documentation gives 2,956,500 DDUs per month for retention, after a 365-day ramp-up. This matters: ingestion weighs heavily, but retention length becomes dominant as soon as it grows.

One more detail: the number of lines or their individual size does not enter the calculation. Only the volumes ingested, stored and read count.

Reading log consumption in Dynatrace

In the interface, the documentation points to Account Management, then License / Subscription > Overview, with the permission to change monitoring settings or an administrator account. On the Davis data units page, the Log Monitoring row of the « Consumption by DDU pool » table and the Log Monitoring tab of the detail view show the consumption.

To automate it, the general DDU page lists the metric keys per pool. For logs: builtin:billing.ddu.log.total, builtin:billing.ddu.log.byEntity and builtin:billing.ddu.log.byDescription. They are read with the Metrics API v2, which requires a token with the metrics.read scope.

curl call to the Metrics API v2 with the builtin:billing.ddu.log.total key, from now-30d, resolution Inf and an Api-Token header

curl -L -G 'https://<env-id>.live.dynatrace.com/api/v2/metrics/query' \ --data-urlencode 'metricSelector=builtin:billing.ddu.log.total' \ --data-urlencode 'from=now-30d' \ --data-urlencode 'resolution=Inf' \ -H 'Authorization: Api-Token <metrics.read-token>' \ -H 'Accept: application/json'

The resolution=Inf parameter requests a single aggregated point per tuple. Replace total with byEntity to see which entities weigh most. The value comes from your environment, so it will not match the manual’s example. This metric belongs to the classic DDU model: under a DPS subscription, consumption is read against the rate card in your contract, as described in the article on the DPS licence.

Reducing log DDUs without losing the signal

  1. Filter at ingestion: what is dropped costs no retention. Rules are built in an OpenPipeline pipeline, but ingestion is still billed for what was received.
  2. Shorten retention for debug logs: a dedicated bucket at 10 or 15 days costs far less than one at 95 days.
  3. Bound queries: narrow time window, filters on fields, see the DQL queries on log errors.
  4. Watch dashboard tiles: each one reruns a query on every refresh.
  5. Alert on useful logs, not everything: reducing alert noise also avoids storing the superfluous.

From an SRE angle, these settings avoid discovering an exhausted quota in the middle of an incident, when logs matter most.

When the licence changes: DDU, DPS and pool limits

The documentation states that all new contracts are signed under DPS. In that model, the « Log Analytics overview (DPS) » page speaks of Log – Ingest & Process, Log – Retain and Log – Query, charged according to the rate card. It also describes a « Retain with Included Queries » model (version 1.316+) where data kept within a configured period, 10 to 35 days, can be queried free of charge, followed by an overall retention of up to 10 years. The unit becomes the GiB, with a price read from your contract. No price is given here: check your rate card.

In the legacy model, an environment gets a free tier of 200,000 DDUs per year, usable for the three dimensions, and there are no host-included DDUs for Log Management and Analytics. DDU pools (Settings > Consumption > Davis data unit pools) let you set a monthly or yearly limit per pool, including Log Monitoring. By default, limits are not enforced.

How to check that it works

  1. Run the query above and check that the JSON response contains a point for builtin:billing.ddu.log.total.
  2. Compare with Account Management > License / Subscription > Overview, Log Monitoring tab: the orders of magnitude should match.
  3. Redo the three-dimension calculation with your own volumes: a gap with the measurement points to heavier enrichment than expected or expensive queries.

Frequently asked questions

How many DDUs does one log consume?

The documentation answers that the size or number of records is not relevant. Only the GB ingested and processed, the GB stored per day and the GB read by queries count.

Does filtering logs reduce DDUs?

It reduces retention, not ingestion: according to the documentation, filtering consumes DDUs during Ingest & Process but not during Retain.

Does this model apply to Dynatrace Managed?

No. The page describes only SaaS environments activated for Grail. The documentation states that consumption for the other DDU types, including classic Log Monitoring, remains unchanged.

Conclusion

Log DDUs boil down to three simple multiplications. Controlling them means acting on ingestion, retention length and query discipline. For a DPS contract, apply the same logic, but with the prices from your rate card.

For the wider picture of consumption, see the Dynatrace DPS licence. Sources: DDUs for Log Management and Analytics and Log Analytics overview (DPS).

span.observer is an independent community blog, not affiliated with Dynatrace LLC. Figures come from the Dynatrace documentation consulted on 31 October 2026; check them against your contract and your environment.

Originally published on span.observer. French version: https://span.observer/fr/ddu-logs-dynatrace-ingestion-retention-requete/.