7.1 Davis Deterministic Causation Engine vs. Pure Correlation

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:

1. 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.
2. 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.
3. 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.

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:

1. 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.
2. 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.
3. 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.
4. 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.