Control Dynatrace DDU Token Consumption and Costs (2026)

Dynatrace’s Data, Events, and Topology (DDU) consumption is a primary driver of cost, so understanding and controlling it is key to managing your Dynatrace bill.

Imagine you’re watching a live stream of a busy city intersection. DDU is like the number of tiny cameras and sensors you’ve deployed throughout that city, each feeding continuous data back to a central monitoring hub. The more cameras, the more data, the higher the cost.

Here’s what that looks like in practice. When Dynatrace collects metrics, traces, logs, and topology information, each piece of data contributes to DDU consumption.

• Metrics: Every unique metric (e.g., cpu.usage, jvm.memory.used) for a specific entity (a host, a process group) counts. The more entities and the more metrics per entity, the higher the DDU.
• Traces: PurePaths, especially those with many service calls or custom attributes, consume DDU. High-volume, low-value traces can add up quickly.
• Logs: Log content ingested and stored contributes significantly. Even compressed logs take up space and incur DDU.
• Topology: The discovery and continuous updates of your environment’s topology (hosts, services, dependencies) also factor in.

Let’s see how this plays out. Consider a simple Go application deployed on Kubernetes.

# Example Kubernetes Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-go-app
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: my-go-app
    spec:
      containers:
      - name: go-app
        image: your-docker-repo/my-go-app:latest
        ports:
        - containerPort: 8080

With the OneAgent installed, Dynatrace automatically discovers this deployment, its pods, and the underlying host and Kubernetes infrastructure. It starts collecting metrics like CPU, memory, network, and application-specific metrics from the Go app. If your Go app generates verbose logs or has many internal calls captured in PurePaths, each of those adds to DDU.

The core problem Dynatrace solves here is providing end-to-end visibility across your entire technology stack. It doesn’t just monitor the Go app; it monitors the Kubernetes node it’s on, the network traffic between services, and the cloud provider’s underlying infrastructure. This breadth of data is powerful but can be costly if not managed.

To control DDU consumption, you have several levers:

1. Metric Ingestion Control: You can selectively disable metrics that aren’t critical. For instance, if you have custom metrics for a specific Go package that are rarely used, you can exclude them.

   • How: In Dynatrace, navigate to Settings -> Monitored technologies -> Go and disable specific metric collections. Or, use OneAgent configuration files to exclude metric IDs.
   • Why it works: Directly reduces the number of unique metrics being sent and processed.

2. Log Monitoring Filtering: Aggressively filter logs at the source or within Dynatrace to only ingest what’s essential for troubleshooting.

   • How: Configure log processing rules in Dynatrace (Settings -> Log observability -> Log processing) to drop or filter out noisy or irrelevant log lines based on content, severity, or source. You can also use log.exclude in the OneAgent configuration.
   • Why it works: Prevents large volumes of uninteresting log data from being ingested and stored.

3. PurePath Filtering and Sampling: Tune your PurePath ingestion to focus on critical transactions and reduce noise from background or high-frequency, low-impact calls.

   • How: Use Transaction and service data settings in Dynatrace (Settings -> Monitoring settings -> Monitored technologies -> Custom service detection or Java/Go/etc. specific settings) to define custom service detection rules or adjust sampling rates. For Go, you can use dt_enabled=false environment variable for specific applications or dt_trace_enabled=false for certain methods/packages.
   • Why it works: Reduces the number of detailed traces captured, focusing DDU on the most impactful transactions.

4. Topology Scope Reduction: While full topology is a core benefit, if you have massive, stable environments, you might consider limiting the depth or frequency of topology updates for less critical entities.

   • How: This is more advanced and often involves careful configuration of OneAgent discovery capabilities or, in extreme cases, logical segmentation of monitoring. However, Dynatrace’s default topology collection is generally efficient. Focus on disabling DDU-generating features if topology is not the primary concern for a specific agent.
   • Why it works: Limits the amount of configuration change data and entity metadata processed.

5. Custom Event Filtering: If you’re sending custom events, ensure they are high-value and not overly frequent.

   • How: Review your custom event payloads and ingestion points. Implement filtering logic in your application code or via Dynatrace’s event processing rules before they are ingested.
   • Why it works: Prevents the DDU cost associated with potentially redundant or low-impact custom events.

6. OneAgent Version and Configuration Optimization: Ensure you are using a recent OneAgent version, as performance and efficiency improvements are regularly made. Also, review dt_force_topology_discovery settings; while useful, excessive forced discovery can increase DDU.

   • How: Regularly update your OneAgent. Check dt_force_topology_discovery in your OneAgent configuration or via environment variables.
   • Why it works: Newer agents are more efficient, and avoiding unnecessary topology scans saves processing.

The most surprising thing about DDU consumption is how quickly seemingly minor data points can accumulate. A single "noisy" custom metric that reports every second for thousands of instances, or a verbose log message for every request in a high-throughput API, can individually be small, but together they can balloon your DDU.

Once you’ve optimized your DDU consumption, the next challenge you’ll likely face is understanding the impact of Dynatrace’s AI capabilities, like Davis, on your DDU and overall cost.