Study guide
7.1 Davis Deterministic Causation Engine vs. Pure Correlation
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
7.1 Davis Deterministic Causation Engine vs. Pure Correlation
Key Takeaways Explain This Topic AI
Davis AI is a deterministic causation engine that uses live Smartscape topology and PurePath distributed traces rather than probabilistic machine learning correlation.
Pure statistical correlation relies on time-series proximity, which routinely generates false positives and alert storms in microservice architectures during cascading outages.
Davis continuously analyzes vertical infrastructure dependencies and horizontal service communication paths to trace symptoms directly to physical or code-level root causes.
Problem tickets automatically consolidate hundreds of symptomatic alerts across causally connected entities into a single, actionable incident record.
Davis continuously re-evaluates active problems in real-time, dynamically updating root cause and impact assessments as incidents evolve or auto-remediate.
Last updated: September 2026
In enterprise cloud architectures consisting of thousands of microservices, serverless workloads, container orchestrators, and hybrid infrastructure components, operational telemetry generates petabytes of metrics, logs, and traces every day. When an infrastructure component degrades or a software regression is deployed, failure cascades rapidly across interdependent tiers. Traditional monitoring tools and generic AIOps platforms attempt to address this complexity using statistical time-series correlation or unsupervised machine learning. However, in distributed environments, correlation fundamentally fails to establish causality.
Dynatrace solves this challenge through Davis , its proprietary, patented deterministic causation engine. Rather than guessing probable relationships based on temporal proximity, Davis utilizes real-time structural models of application and infrastructure topology to pinpoint the precise root cause of performance anomalies and outages.
Understanding the architectural mechanics of Davis, how it differs from machine learning correlation, and how it manages the problem lifecycle is essential for the Dynatrace Certified Associate examination.
The Architectural Imperative: Causation vs. Pure Correlation
To appreciate the innovation behind Davis, one must first examine the inherent limitations of statistical correlation in IT operations.
The Failure of Pure Correlation in Distributed Environments
Most modern AIOps platforms utilize mathematical correlation algorithms (such as Pearson correlation coefficients, clustering algorithms, or anomaly coincidence windows). When metric spikes occur concurrently—such as CPU utilization rising on Host A at the exact same minute response times spike on Service B—the correlation engine concludes that the two events are related.
This approach exhibits catastrophic failure modes in modern architectures:
Alert Storms: When an underlying shared dependency (such as a database or network switch) degrades, dozens of upstream microservices simultaneously experience elevated response times and error rates. A statistical tool evaluates each time-series anomaly independently, triggering hundreds or thousands of disconnected alert notifications to on-call teams.
Spurious Correlation: Modern systems process countless automated background tasks—such as scheduled cron jobs, database backups, garbage collection cycles, and batch ETL jobs. If an unrelated batch job spikes CPU at the same moment an edge API gateway suffers an external DDoS attack, a pure correlation engine falsely correlates the two events, directing engineers down dead-end troubleshooting paths.
The "Cold Start" / Training Trap: Probabilistic machine learning algorithms require weeks or months of historical data to establish predictive models. In dynamic Kubernetes environments where pods, nodes, and ephemeral containers spin up and terminate in minutes, statistical models are permanently out of date.
Deterministic Causation: The Dynatrace Paradigm
Dynatrace Davis does not rely on guessing, statistical probabilities, or correlation coefficients. Instead, Davis is deterministic : it evaluates anomalies strictly through verified, bidirectional topological relationships established by OneAgent.
Architectural Capability Pure Correlation (Statistical / Machine Learning AIOps) Davis Deterministic Causation Engine
Core Methodology Statistical anomaly coincidence and time-series clustering Deterministic fault-tree traversal across verified dependencies
Topology Awareness Absent or static (relies on manual CMDB imports) Real-time, automated, and continuous via Smartscape
Transaction Tracing Disconnected from infrastructure metrics; sampled traces 100% causally linked via PurePath context propagation
Cold Start / Training Requires weeks of training models; breaks on configuration changes Zero training required; immediate causation out of the box
Alert Volume Generates hundreds of fragmented alert notifications (Alert Storms) Consolidates all related symptoms into a single unified Problem ticket
Root Cause Precision Probability score or list of "possible suspects" Exact entity, code method, database query, or resource constraint
Exam Key Point: The DCA exam frequently tests the fundamental operating principle of Davis. Always remember: Davis is not a probabilistic machine learning correlation engine; it is a deterministic causation engine based on dynamic topology mapping and transaction-level tracing.
The Three Pillars of Deterministic Causation
Davis does not operate in a vacuum. It derives its intelligence from three interconnected Dynatrace core technologies that continuously supply structural and transactional context: +---------------------------------------------------------------------------------------------------+
- | THE TRIAD OF DAVIS DETERMINISTIC CAUSATION |
- +---------------------------------------------------------------------------------------------------+
- | 1. SMARTSCAPE TOPOLOGY MODEL |
- | • Maps real-time vertical stack (Host -> Process Group -> Service -> Application). |
- | • Maps real-time horizontal dependencies (inter-service network and HTTP communication). |
- | │ |
- | ▼ |
- | 2. PUREPATH DISTRIBUTED TRACING |
- | • Confirms exact transactional call paths across microservices. |
- | • Validates whether Service A actually invoked Service B during the degradation window. |
- | │ |
- | ▼ |
- | 3. HIGH-FIDELITY ONEAGENT TELEMETRY |
- | • Captures sub-second operating system, runtime (JVM/CLR/Node), and container metrics. |
- | • Detects exact physical events (GC pauses, CPU starvation, socket drops, disk queuing). |
- +---------------------------------------------------------------------------------------------------+
- 1. Smartscape Dynamic Topology Mapping
Smartscape maps the entire environment across five structural layers: Data Center, Host, Process Group, Service, and Application. It continuously discovers two orthogonal dependency vectors:
Vertical Dependencies: How software processes map to underlying containers, virtual machines, and physical hardware.
Horizontal Dependencies: How microservices, message queues, and external APIs communicate with one another across the network.
2. PurePath End-to-End Distributed Tracing
While Smartscape confirms that a network route exists between two services, PurePath confirms whether transactional requests actually traveled along that path during an incident. Every trace carries Smartscape entity IDs, enabling Davis to follow the precise execution flow from a browser user action down to a specific line of code or SQL statement.
3. OneAgent Telemetry & Event Ingestion
OneAgent injects sensors at the operating system, container runtime, and application bytecode levels, capturing low-level metrics at 10-second resolution. When resource limits are reached (e.g., memory exhaustion, disk full, CPU starvation), OneAgent generates discrete event notifications that Davis uses as causal nodes in its analysis.
The Mechanics of Davis Causation Analysis
When an anomaly is detected, Davis initiates a systematic, multi-tiered fault-tree traversal to differentiate symptoms from the underlying root cause. +---------------------------------------------------------------------------------------------------+
- | DAVIS FAULT-TREE TOPOLOGY TRAVERSAL WORKFLOW |
- +---------------------------------------------------------------------------------------------------+
- | [STEP 1: ANOMALY TRIGGERED] |
- | • User Action Duration degrades on Frontend Web Application (Symptom detected). |
- | │ |
- | ▼ |
- | [STEP 2: HORIZONTAL SERVICE TRAVERSAL] |
- | • Davis queries PurePath graph for all downstream service dependencies. |
- | • Traverses: Web Frontend -> API Gateway -> Order Service -> Payment Service. |
- | • Observes: Payment Service failure rate spiked to 85% (Downstream Symptom). |
- | │ |
- | ▼ |
- | [STEP 3: VERTICAL INFRASTRUCTURE TRAVERSAL] |
- | • Davis evaluates underlying Process Group Instance hosting Payment Service. |
- | • Descends to Operating System / Host tier: Payment-Host-04. |
- | • Identifies: CPU Steal / Ready time at 98% due to noisy neighbor VM (Physical Root Cause). |
- | │ |
- | ▼ |
- | [STEP 4: UNIFIED PROBLEM CONSOLIDATION] |
- | • All symptoms grouped into Problem #402. |
- | • Business Impact: 12,500 active user sessions affected on Web Frontend. |
- | • Identified Root Cause: Host CPU Saturation on Payment-Host-04. |
- +---------------------------------------------------------------------------------------------------+
- Top-Down Impact vs. Bottom-Up Root Cause
Davis strictly separates the business impact of an incident from its technical root cause :
Impact (Top-Down): Represents the user-facing or consumer-facing symptoms of the incident. This answers the question: Who is suffering? Davis measures impact at the Application and Service tiers, evaluating affected Real User Monitoring (RUM) sessions, synthetic availability failures, transaction throughput drops, and revenue at risk.
Root Cause (Bottom-Up): Represents the originating failure mechanism. This answers the question: What broke first? Davis isolates the root cause at the infrastructure, process, database, or code tier (e.g., host out-of-memory crash, JVM garbage collection suspension, disk write queue saturation, unhandled runtime exception).
Fault-Tree Traversal & Boundary Analysis
When multiple entities report anomalies simultaneously, Davis traverses the topological fault-tree starting from the affected application. It follows the horizontal PurePath call graph downstream. If Service A is slow because Service B is slow, Service A is marked as a symptom. Davis continues traversing downstream until it reaches an entity whose degradation is not caused by any downstream dependency. It then traverses vertically down that entity's Smartscape stack to inspect process and host metrics. The entity at the terminal point of this traversal is flagged as the root cause.
Boundary Analysis (Unmonitored Components): What happens if a failure originates in an unmonitored third-party system, such as an external credit card clearinghouse or an uninstrumented mainframe? Davis detects that all outbound requests to that external endpoint are failing or timing out, while the local process and host remain healthy. Davis flags the Third-Party Web Request or External Service boundary as the root cause, isolating the issue to the vendor boundary without producing false internal alarms.
The Problem Lifecycle and Incident Evolution
Davis is not a static snapshot tool; it manages an active, evolving lifecycle for every incident.
1. Detection Phase & Problem Creation
Davis opens a Problem Ticket when an anomaly violates dynamic baseline thresholds or when a discrete availability event occurs (such as a process crash). Crucially, Davis requires that metric violations persist beyond detection sensitivity windows to filter out transient micro-spikes.
2. Continuous Re-Evaluation (The 1-Minute Cycle)
Unlike ticketing systems where alerts remain static once logged, Davis continuously re-evaluates every active problem on a minute-by-minute basis:
Event Aggregation: As new symptoms emerge on related entities (e.g., downstream queue backups or secondary service timeouts), Davis merges them into the existing problem ticket rather than creating new alerts.
Dynamic Root Cause Refinement: If an incident begins with an application response time degradation, but three minutes later an underlying database host crashes due to an out-of-memory error, Davis dynamically updates the Problem Card, escalating the host crash to the primary root cause.
Impact Expansion: Davis recalculates the number of affected user sessions and services in real-time as the incident expands or contracts.
3. Automated Remediation Verification & Closure
When an automated remediation script executes or engineers deploy a bugfix, Davis monitors telemetry until all contributing events return within dynamic baseline limits. Once all causal anomalies have normalized, Davis automatically marks the Problem as Resolved / Closed . If performance degrades again shortly after, Davis evaluates whether the event is a recurrence of the original incident or an independent problem.
DCA Exam Essentials: Davis AI Key Rules & Edge Cases
To achieve a top score on the Dynatrace Certified Associate exam, keep these foundational rules in mind:
Zero Configuration Required: Davis runs automatically out of the box. It does not require engineers to configure alert correlation rules, define Bayesian networks, or program escalation logic.
No Problem Splitting for Dependent Failures: If 100 microservices fail because a single shared database runs out of disk space, Davis opens exactly ONE problem ticket, never 100 tickets.
Alert Notifications vs. Problem Opening: Problem opening is handled by Davis based on dynamic baselines and availability events. Alert notifications (pushing to Slack, PagerDuty, Jira, or ServiceNow) are governed by Alerting Profiles , which filter problems by severity, tags, and delay rules.
Event Hierarchy Primacy: Availability events always take precedence over performance anomalies. If a service experiences both elevated response time and an availability outage, the Problem ticket reflects the Availability severity.