Study guide
1.4 Licensing Models: Dynatrace Platform Subscription (DPS) & Davis Data Units (DDUs)
Dynatrace Certified Associate Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Overview, Deployment Models & Architecture
1.1 Dynatrace Platform Capabilities, Web UI Navigation & the Dynatrace Hub 1.2 SaaS vs. Dynatrace Managed Architecture & Security 1.3 Core Telemetry Components: OneAgent, ActiveGate & Grail Lakehouse 1.4 Licensing Models: Dynatrace Platform Subscription (DPS) & Davis Data Units (DDUs)
2 Chapter 2: ActiveGate Architecture & Network Topologies
2.1 ActiveGate Types: Environment vs. Cluster ActiveGates 2.2 ActiveGate Capabilities: Proxying, Private Synthetic, Cloud Integrations & Extensions 2.3 Network Zones, Multi-DC Routing & Firewall Traversal
3 Chapter 3: OneAgent Deployment, Configuration & Management
3.1 OneAgent Architecture, Components & Automatic Injection 3.2 Host Installation on Linux, Windows & Containerized Hosts 3.3 Cloud-Native Deployment: Dynatrace Operator on Kubernetes & OpenShift 3.4 Kubernetes Observability: Clusters, Nodes, Namespaces, Workloads & Events
4 Chapter 4: Monitoring Modes, Process Groups & Infrastructure Observability
4.1 Monitoring Modes: Full-Stack vs. Infrastructure-Only vs. Discovery 4.2 Process Groups, Process Instances & Custom Process Group Detection Rules 4.3 Host Groups, Host Naming Rules & Environmental Metadata Extraction 4.4 Infrastructure & Operations: Host Health, Disk, Network & Availability Analysis 4.5 Database Observability: The Databases App, Connection Pools & Storage Latency
5 Chapter 5: Smartscape Topology & Service Flow
5.1 The 5-Layer Smartscape Topology: Datacenter to Application 5.2 Service Detection: Web Services, Background Tasks & Custom Services 5.3 Service Flow, Backtrace Analysis & Horizontal/Vertical Dependency Mapping
6 Chapter 6: PurePath Distributed Tracing & Code-Level Diagnostics
6.1 PurePath Architecture, Distributed Tracing & Request Context Propagation 6.2 Method Hotspots, CPU Profiling & Memory Allocation Thread Analysis 6.3 Database Service Diagnostics, Slow Queries & Exception Analysis
7 Chapter 7: Davis AI Engine, Baselining & Causation
7.1 Davis Deterministic Causation Engine vs. Pure Correlation 7.2 Automated Dynamic Baselining, Percentiles & Traffic Seasonality 7.3 Event Ingestion, Event Types & Event Hierarchy in Problem Evolution
8 Chapter 8: Problem Lifecycle, Root Cause Analysis & Alerting
8.1 Problem Lifecycle, Severity Categories & Root Cause Cards 8.2 Alerting Profiles, Delay Filters & Management Zone Routing 8.3 Problem Notification Integrations: Webhooks, Slack, ServiceNow & ITSM
9 Chapter 9: Digital Experience Monitoring: Synthetic Monitoring
9.1 Synthetic Monitors: HTTP, Single-Step Browser & Multi-Step Clickpaths 9.2 Private Synthetic Locations, ActiveGate Engines & Credential Vault 9.3 Outage Detection, Performance Baselining & Maintenance Suppression
10 Chapter 10: Digital Experience Monitoring: Real User Monitoring (RUM)
10.1 RUM Architecture, OneAgent Script Injection & Mobile/OpenKit Telemetry 10.2 User Actions: Load vs. XHR/Fetch Actions, Visually Complete & Speed Index 10.3 Apdex Performance Ratings, User Sessions & Session Replay Masking
11 Chapter 11: Log Management and Analytics on Grail with DQL
11.1 Log Management on Grail: Storage, Ingestion Pipelines & Log Masking 11.2 Dynatrace Query Language (DQL): Fetch, Filter, Fields & String Operations 11.3 DQL Aggregations: Summarize, MakeTimeseries, Sorting & Visualizations
12 Chapter 12: Platform Governance, OpenTelemetry & Automation
12.1 Management Zones: Scoping Observability, Dashboards & Access Control 12.2 Tagging Strategies: Automated Rule-Based Tags, Manual Tags & AWS/K8s Metadata 12.3 OpenTelemetry Ingestion, OpenPipeline & Dynatrace Workflows Automation
13 Chapter 13: Cloud Integrations & Agentless Infrastructure Ingestion
13.1 AWS, Azure & Google Cloud Integrations 13.2 VMware vSphere, Extensions & Other Agentless Ingestion Paths
14 Chapter 14: Business Analytics & Business Events
14.1 Business Events: Capture, Ingestion & the bizevents Grail Table 14.2 Business Analytics: Connecting Performance to Revenue, Conversion & KPIs
15 Chapter 15: Notebooks, Dashboards & Data Visualization
15.1 Notebooks: Section-Based Investigation & Shareable Analysis 15.2 Dashboards: Tiles, Variables, Segments & Continuous Monitoring 15.3 Choosing Visualizations: Data Explorer, Chart Types & Metric Selection
16 Chapter 16: Reporting, Metrics & User Behavior Analysis
16.1 Metrics on Grail: Built-in Metrics, Granularity & Retention 16.2 Dashboard Reports, Subscriptions & Exporting Data via APIs 16.3 User Behavior Analysis: Bounce Rate, Landing & Exit Pages, Conversion Goals 16.4 Session Segmentation, User Journeys & Funnel Drop-Off Analysis
17 Chapter 17: Security, Vulnerability Analytics & Application Protection
17.1 Platform Security: Data Privacy, Encryption & Access Control 17.2 Third-Party Vulnerabilities, the Davis Security Score & Security Advisor 17.3 Code-Level Vulnerabilities, Attacks & Runtime Application Protection 17.4 Security Investigator, Notifications & the Remediation Workflow
1.4 Licensing Models: Dynatrace Platform Subscription (DPS) & Davis Data Units (DDUs)
Key Takeaways Explain This Topic AI
Dynatrace Platform Subscription (DPS) is a modern consumption-based commercial model where an organization commits to an annual spend pool that draws down flexibly across any platform capability without rigid license silos.
Host Units (HUs) measure server monitoring capacity based on physical or virtual RAM, where 16 GB of RAM corresponds to 1.0 Host Unit in Full-Stack monitoring mode.
Infrastructure-Only monitoring mode provides essential operating system and network visibility at a reduced rate of 0.3 Host Units per 16 GB of host RAM.
Davis Data Units (DDUs) function as the universal consumption currency for custom metrics, third-party cloud integrations (AWS CloudWatch, Azure Monitor), and Dynatrace Extensions.
Cost governance tools—including DDU environment pool caps, metric exclusion rules, and host group assignments—safeguard against budget overruns and optimize observability investments.
Last updated: September 2026
Effectively managing a modern enterprise observability platform requires a comprehensive understanding of commercial licensing, capacity metering, and consumption governance. Dynatrace has evolved its commercial framework from rigid, component-based licensing into a flexible, consumption-driven model known as the Dynatrace Platform Subscription (DPS) . Understanding how Host Units (HUs) and Davis Data Units (DDUs) are metered ensures organizations maximize observability coverage while optimizing budget efficiency.
The Evolution of Licensing: Classic vs. Dynatrace Platform Subscription (DPS)
Historically, software monitoring vendors required customers to purchase isolated, product-specific licenses. Dynatrace originally offered a Classic Licensing model that segmented platform capabilities into distinct licensing buckets. While still encountered in legacy contracts, modern deployments overwhelmingly leverage DPS.
Classic Licensing: Siloed Entitlements
In the Classic model, an enterprise purchased fixed quantities of individual license components:
Host Unit Licenses: Reserved strictly for full-stack or infrastructure server monitoring.
Digital Experience Monitoring (DEM) Units: Reserved for Synthetic tests and Real User Monitoring (RUM) sessions.
Log Management Licenses: Purchased based on gigabytes of log data ingested per day.
Davis Data Unit (DDU) Pools: Purchased specifically for custom metrics and cloud API polling.
The Limitation: Classic licensing frequently led to stranded capacity . If an organization modernized applications by migrating from large monolithic virtual machines to serverless functions, their unused Host Unit licenses could not be converted to cover synthetic testing or cloud metric spikes without commercial contract renegotiation.
Dynatrace Platform Subscription (DPS): The Unified Commitment Pool
The Dynatrace Platform Subscription (DPS) replaces fragmented licenses with a single, unified annual or multi-year financial commitment. Under DPS:
The customer commits to an annual platform spend balance.
Every capability—OneAgent full-stack monitoring, Grail log ingestion, DQL query compute, Synthetic monitors, Davis AI causation, and automated Workflows—draws down against the identical commitment balance based on transparent hourly or volume-based consumption rates.
Organizations enjoy complete architectural flexibility: as workloads shift from virtual machines to Kubernetes or serverless containers, consumption dynamically adapts without contractual friction.
- Attribute / Dimension Classic Licensing Model Dynatrace Platform Subscription (DPS)
- Contract Structure Fragmented contracts with siloed entitlements Single unified annual commitment pool
Capacity Fungibility Zero; unused Host Units cannot fund Logs or DEM 100% fungible; balance covers all platform capabilities
New Feature Access Requires purchasing new add-on SKUs Instant access to newly released platform features
Architecture Agility Hinders cloud migrations due to fixed license types Seamlessly absorbs VM, container, and serverless transitions
- Consumption Metering Rigid caps per license type Real-time drawdown tracking via Account Management
- Host Unit (HU) Sizing Mechanics and Calculation Rules
For server and virtual machine monitoring, Dynatrace meters capacity using Host Units (HUs) . Sizing is determined purely by the physical RAM of bare-metal servers or the allocated vRAM of virtual machines, completely independent of CPU core counts.
Full-Stack Monitoring Calculation
Full-Stack monitoring delivers deep code-level tracing (PurePath), process discovery, service flow mapping, network analysis, and infrastructure metrics. The baseline consumption ratio is: 1.0 Host Unit = 16 GB of Host RAM \text{1.0 Host Unit} = \text{16 GB of Host RAM} 1.0 Host Unit = 16 GB of Host RAM
For systems with less than 16 GiB of RAM, Dynatrace applies fractional tiers taken from the official host unit weighting table:
≤ \le ≤ 1.6 GiB RAM: Consumes 0.10 HU .
≤ \le ≤ 4 GiB RAM: Consumes 0.25 HU (1/4 of a Host Unit).
≤ \le ≤ 8 GiB RAM: Consumes 0.50 HU (1/2 of a Host Unit).
≤ \le ≤ 16 GiB RAM: Consumes 1.0 HU .
When a host's RAM falls between two rows, Dynatrace rounds up to the next tier. A host with 12 GiB of RAM therefore consumes a full 1.0 host unit, because 12 GiB sits between the 8 GiB and 16 GiB rows. This rounding rule is a favourite exam trap: candidates who compute 12 ÷ 16 = 0.75 12 \div 16 = 0.75 12 ÷ 16 = 0.75 get the question wrong.
For systems exceeding 16 GB of RAM, consumption scales linearly in 16 GB increments:
32 GB RAM: Consumes 2.0 HUs .
48 GB RAM: Consumes 3.0 HUs .
64 GB RAM: Consumes 4.0 HUs .
128 GB RAM: Consumes 8.0 HUs .
Infrastructure-Only Monitoring Calculation
Many organizations operate supporting server fleets—such as database replica nodes, intermediate proxies, batch file servers, or storage appliances—where code-level application execution is absent, but operating system health, disk saturation, and network metrics remain critical.
For these workloads, administrators configure OneAgent in Infrastructure-Only Monitoring mode :
Infrastructure-Only mode consumes 0.3 Host Units per 16 GiB of RAM (a 70% reduction compared to Full-Stack mode).
A 16 GiB server consumes 0.3 HU ; a 32 GiB server consumes 0.6 HU ; a 48 GiB server consumes 0.9 HU .
Critical cap: Infrastructure-mode consumption is capped at 1.0 host unit per host . A 64 GiB server therefore consumes 1.0 HU , not 4 × 0.3 = 1.2 4 \times 0.3 = 1.2 4 × 0.3 = 1.2 HUs, and a 512 GiB server also consumes just 1.0 HU . The cap is what makes Infrastructure mode dramatically cheaper on large database and storage nodes — the bigger the box, the larger the saving. +-----------------------------------------------------------------------------------------+
- | HOST UNIT (HU) SIZING REFERENCE TABLE |
- +-----------------------+-----------------------------+-----------------------------------+
- | HOST MEMORY (RAM) | FULL-STACK MONITORING (HU) | INFRASTRUCTURE-ONLY MODE (HU) |
- +-----------------------+-----------------------------+-----------------------------------+
- | Up to 1.6 GiB | 0.10 HU | 0.03 HU |
- | Up to 4 GiB | 0.25 HU | 0.075 HU |
- | Up to 8 GiB | 0.50 HU | 0.15 HU |
- | Up to 16 GiB | 1.0 HU | 0.3 HU |
- | 32 GiB | 2.0 HUs | 0.6 HU |
- | 64 GiB | 4.0 HUs | 1.0 HU (capped) |
- | 128 GB | 8.0 HUs | 2.4 HUs |
- +-----------------------+-----------------------------+-----------------------------------+
Kubernetes & Container Sizing Note: In Kubernetes and OpenShift clusters, OneAgent is licensed at the underlying worker node level based on each node's physical or virtual RAM. Once a worker node is licensed, all containers, pods, microservices, and namespaces running on that node are monitored with zero additional per-container licensing fees.
Davis Data Units (DDUs): Structure and Consumption Mechanics
While Host Units cover standard server and process infrastructure, modern environments ingest vast streams of telemetry from external systems. Davis Data Units (DDUs) serve as the universal consumption currency for custom data and third-party integrations.
Telemetry Types Powered by DDUs
DDUs meter three primary telemetry streams:
Custom Metrics: Application or business metrics ingested via the Dynatrace REST API, OpenTelemetry metric exporters, StatsD, or Micrometer.
Cloud Provider Integrations: External hypervisor and PaaS metrics polled via ActiveGate integrations from Amazon Web Services (AWS CloudWatch), Microsoft Azure Monitor, and Google Cloud Monitoring.
Dynatrace Extensions 2.0: Performance metrics gathered from network appliances (SNMP), mainframe systems, Windows infrastructure (WMI), Java management beans (JMX), and Prometheus endpoints.
Metric Consumption Weighting
Metric consumption in Dynatrace is calculated based on the number of data points reported over time:
One continuously reported metric tuple (1 metric data point reported once every 60 seconds) produces 525,600 data points per year.
Each ingested metric data point deducts 0.001 DDU from the quota, so one continuously reported metric tuple consumes 525,600 × 0.001 = 525.6 DDUs 525{,}600 \times 0.001 = \mathbf{525.6\text{ DDUs}} 525 , 600 × 0.001 = 525.6 DDUs per year.
High-cardinality metadata multiplies metric streams: if a custom metric orders.processed is split across 5 distinct regional dimensions, it forms 5 unique metric time series, consuming roughly 5 × 525.6 = 2,628 DDUs 5 \times 525.6 = \mathbf{2{,}628\text{ DDUs}} 5 × 525.6 = 2 , 628 DDUs annually. Dimension explosion — not raw metric count — is what destroys DDU budgets.
Cost Governance, Quota Allocation, and Spend Optimization
Without proactive governance, modern microservice architectures can generate explosive telemetry volumes that rapidly deplete organization budgets. Dynatrace provides robust administrative controls to meter and restrict consumption.
DDU Pool Management and Hard Caps
Within Dynatrace Account Management, administrators configure distinct DDU Pools mapped to specific environments or business units:
Custom Metrics Pool: Establishes monthly or annual quotas for custom metric ingestion.
Cloud Integration Pool: Controls metric volume ingested from AWS CloudWatch or Azure Monitor.
Log Ingestion Pool: Restricts log ingestion volumes.
Administrators can configure pools with soft notifications (alerting administrators when 80% of budget is reached) or hard caps (automatically dropping incoming telemetry once the quota is exhausted to prevent unplanned overage charges).
Telemetry Optimization Strategies
Metric Ingestion Filtering: Configure rules at the ActiveGate or platform level to discard noisy, low-value metric dimensions before they are metered.
CloudWatch Namespace Selection: Rather than polling all AWS metrics, restrict ActiveGate polling configurations to essential namespaces (e.g., AWS/EC2 , AWS/RDS ), omitting high-volume, low-utility metrics such as basic EBS volume statistics.
Automated Host Group Rules: Utilize Host Groups and automated deployment rules to assign development and staging clusters to Infrastructure-Only monitoring mode by default, reserving Full-Stack monitoring for critical staging and production environments.