Study guide
7.3 Event Ingestion, Event Types & Event Hierarchy in Problem Evolution
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.3 Event Ingestion, Event Types & Event Hierarchy in Problem Evolution
Key Takeaways Explain This Topic AI
Dynatrace categorizes telemetry events into a strict severity hierarchy: AVAILABILITY, ERROR, PERFORMANCE, RESOURCE_CONTENTION, and INFO.
AVAILABILITY events represent complete service or infrastructure outages and immediately open problem tickets with the highest alert priority.
INFO and deployment events provide critical root-cause context during causal analysis but never trigger problem tickets or alert notifications on their own.
Davis consolidates multiple horizontal and vertical events into an evolving Problem Card, displaying a unified timeline of cascading degradation.
Maintenance windows provide granular alert suppression options, allowing teams to silence notifications while still recording performance baseline data and topology events.
Last updated: September 2026
In Dynatrace, performance monitoring transcends static time-series graphs through the ingestion and analysis of discrete Telemetry Events . Events capture state transitions, threshold violations, configuration deployments, and operational failures occurring across monitored entities. Rather than treating all events with equal urgency, Dynatrace applies a deterministic Event Severity Hierarchy .
This hierarchy dictates how Davis opens problem tickets, how problem severity levels escalate during cascading outages, and how external notifications are dispatched. Furthermore, event correlation enables modern CI/CD pipelines to feed deployment metadata directly into Dynatrace, empowering Davis to connect software releases directly to performance regressions.
Mastering event ingestion pathways, the severity hierarchy, and problem card evolution is essential for the Dynatrace Certified Associate exam.
Telemetry Events: The Building Blocks of Problem Intelligence
An Event in Dynatrace represents an instantaneous occurrence or a time-bounded state change on a specific monitored entity (such as a Host, Process Group, Service, or Application).
Ingestion Pathways
Events flow into Dynatrace from multiple instrumentation vectors:
Native OneAgent Sensors: The OneAgent continuously monitors operating system metrics, process lifecycles, and network sockets, automatically generating events for host reboots, process crashes, CPU saturation, out-of-memory kills, and network packet drops.
ActiveGate Cloud & Virtualization Plugins: ActiveGates polling VMware vCenter, AWS CloudWatch, Azure Monitor, or GCP generate infrastructure events (e.g., hypervisor host migrations, AWS RDS failovers, Azure VM auto-scaling).
Dynatrace Events API (v2): Modern DevOps toolchains push external events programmatically using the REST endpoint POST /api/v2/events . This allows CI/CD tools (Jenkins, GitLab CI, GitHub Actions, ArgoCD) to annotate Dynatrace entities with deployment, configuration change, or remediation metadata.
Synthetic Monitors: Browser and HTTP synthetic monitors generate availability and performance events when multi-location validation tests fail.
The Dynatrace Event Severity Hierarchy
Dynatrace organizes all events into five primary severity categories. This hierarchy is strictly enforced: higher-severity events take precedence over lower-severity events when Davis determines overall problem severity. +---------------------------------------------------------------------------------------------------+
- | DYNATRACE EVENT SEVERITY HIERARCHY |
- +---------------------------------------------------------------------------------------------------+
- | 1. AVAILABILITY (Highest Severity) |
- | • Complete outage of service or infrastructure (Process crash, Host reboot, HTTP 503). |
- | • Opens problem immediately with P1 / Critical priority. |
- | │ |
- | ▼ |
- | 2. ERROR |
- | • Spike in failed requests or unhandled exceptions (HTTP 5xx, database transaction rollback). |
- | • Opens problem if baseline failure rate thresholds are breached. |
- | │ |
- | ▼ |
- | 3. PERFORMANCE |
- | • Response time degradation, high queue latency, slow database queries. |
- | • Opens problem if dynamic baseline or static response time threshold is breached. |
- | │ |
- | ▼ |
- | 4. RESOURCE_CONTENTION (RESOURCE) |
- | • Infrastructure exhaustion (Disk full, Memory saturation, CPU starvation). |
- | • Opens problem or merges into active incident as the underlying root cause. |
- | │ |
- | ▼ |
- | 5. CUSTOM_ALERT |
- | • User-configured metric threshold violations (e.g., custom metric > 1,000). |
- | │ |
- | ▼ |
- | 6. INFO / CONFIGURATION / DEPLOYMENT (Lowest Severity - Contextual Only) |
- | • CI/CD deployments, configuration changes, feature flag toggles, planned restarts. |
- | • NEVER opens a problem ticket on its own; correlated by Davis as Root Cause Context! |
- +---------------------------------------------------------------------------------------------------+
- Comprehensive Event Hierarchy Analysis
Severity Category Ingestion Origin Immediate Problem Opening? Typical Examples & Trigger Conditions Alerting Urgency
AVAILABILITY OneAgent / Synthetic Yes (Immediate) Process shutdown, host offline, synthetic monitor global failure, HTTP 503 Service Unavailable Critical (P1) : Highest priority. Triggers immediate pager notifications.
ERROR OneAgent / PurePath Yes (If baseline violated) HTTP 5xx surge, unhandled exception burst, database connection pool rejection High (P2) : Significant user-facing error rate increase.
PERFORMANCE OneAgent / Dynamic Baseline Yes (If baseline violated) Service response time degradation (p50/p90), user action duration slowdown Medium (P3) : Performance regression impacting user satisfaction.
RESOURCE_CONTENTION OneAgent / Infrastructure Yes (If threshold violated) Host CPU saturation, disk queue fill, memory page swapping, network socket exhaustion Medium (P3) : Infrastructure constraint; frequently identified as Root Cause.
CUSTOM_ALERT Custom Events / API Yes (If configured) Business metric threshold breach (e.g., cart abandonments > 500) Configurable via Alerting Profiles.
INFO / DEPLOYMENT Events API / CI/CD NEVER Software deployment, Git commit tag, feature flag toggle, maintenance window start Zero (Informational) : Never pages on-call staff.
Exam Key Point: The DCA exam heavily tests the behavior of INFO (Configuration / Deployment) events. Remember this cardinal rule: INFO events NEVER open a problem ticket and NEVER trigger an alert notification on their own. Instead, Davis uses them as contextual evidence to determine whether a recent release or configuration update caused a subsequent performance or error event.
The Special Role of INFO & Deployment Events
In modern GitOps and Continuous Deployment workflows, software is released multiple times per day. When an outage occurs minutes after a canary rollout, connecting the failure to the release is the most critical step in mean time to resolution (MTTR).
Structure of the Events API v2 Payload
DevOps pipelines deliver deployment metadata to Dynatrace by executing an HTTP POST to /api/v2/events . A standard deployment event payload includes: {
- "eventType": "CUSTOM_INFO",
- "title": "Deployment of Order Service v2.4.1",
- "entitySelector": "type(SERVICE),tag(service:order-service)",
- "properties": {
- "remediation": "https://argocd.internal/rollback/order-svc",
- "git.commit": "9f8d32b",
- "ci.buildUrl": "https://jenkins.internal/job/order-svc/104",
- "approver": "release-lead@company.com"
- }
- }
- How Davis Correlates Deployments to Outages
When Davis opens a Problem ticket for a downstream service degradation (e.g., HTTP 500 errors), it queries the Smartscape topology graph for any events occurring in temporal proximity to the incident. If an INFO deployment event was registered on that service or its underlying process group within the preceding window, Davis highlights the deployment directly in the Root Cause section of the Problem Card as the probable catalyst for the degradation.
The Problem Evolution Timeline & Anatomy of a Problem Card
When an incident unfolds across a microservice landscape, it rarely begins and ends with a single static error. Dynatrace visualizes the progression of complex failures through Problem Evolution . +---------------------------------------------------------------------------------------------------+
- | ANATOMY OF A DYNATRACE PROBLEM CARD |
- +---------------------------------------------------------------------------------------------------+
- | PROBLEM #1842: High Failure Rate on 'Order Service' |
- | Status: OPEN | Severity: ERROR | Duration: 14 mins | Impact: 2 Applications, 4 Services |
- +---------------------------------------------------------------------------------------------------+
- | [1. BUSINESS IMPACT SECTION] |
- | • Web Application: 1,420 Real User sessions impacted. |
- | • Mobile App (iOS/Android): Cart checkout failures detected. |
- +---------------------------------------------------------------------------------------------------+
- | [2. VISUAL PROBLEM EVOLUTION TIMELINE] |
- | 14:00 ─── [INFO] Deployment event: 'Order Service v2.4.1' registered via Events API |
- | 14:02 ─── [RESOURCE] Disk I/O Saturation event on host 'db-prod-02' |
- | 14:04 ─── [PERFORMANCE] Response time degradation on 'Database Query: selectCart' |
- | 14:05 ─── [ERROR] Failure rate spike (84% HTTP 500) on 'Order Service' <--- Problem Opens |
- +---------------------------------------------------------------------------------------------------+
- | [3. ROOT CAUSE SECTION] |
- | • Identified Root Cause: Disk I/O Saturation on Host 'db-prod-02' |
- | • Contributing Change: Deployment 'v2.4.1' on Service 'Order Service' |
- +---------------------------------------------------------------------------------------------------+
- Problem Severity Escalation Rules
As an incident evolves, its overall severity dynamically mirrors the highest active event severity involved in the cascade:
If an incident begins with a PERFORMANCE degradation (Response time slowdown), the Problem Card is assigned PERFORMANCE severity.
If downstream services begin rejecting requests and throwing HTTP 500 errors, Davis merges the new ERROR event into the problem ticket, automatically escalating the problem severity to ERROR .
If a key process subsequently crashes or a synthetic monitor fails completely, an AVAILABILITY event is attached, immediately escalating the problem severity to AVAILABILITY .
When the crashed process restarts, the problem severity de-escalates back to the next highest active event until all events resolve.
Problem Closure Requirements
A Dynatrace Problem ticket never closes prematurely while contributing causal events remain active. Davis requires that:
All active AVAILABILITY, ERROR, PERFORMANCE, and RESOURCE events have ended.
Multi-dimensional metric baselines (response time, failure rate, traffic) have normalized within acceptable dynamic tolerance bands.
Maintenance Windows & Alert Suppression Strategies
During planned maintenance, rolling kernel upgrades, or disaster recovery drills, infrastructure components will reboot and services will temporarily shut down. Without proper controls, these planned actions trigger catastrophic alert storms.
Dynatrace manages planned downtime through Maintenance Windows , which can be configured with one of three distinct operational modes:
Maintenance Window Mode Metric Collection Status Problem Detection Status Alert Notification Status Best Use Case
Detect problems and alert Fully Active Fully Active Normal Alerting (Not Suppressed) Validating automated disaster recovery failover or chaos engineering drills where teams need real-time alerts.
Detect problems but don't alert Fully Active Fully Active Suppressed (Zero Pagers/Webhooks) Standard Maintenance : Teams need historical problem cards recorded in the UI for post-mortem review, but want to silence pagers.
Disable problem detection Fully Active Disabled (No Problems Opened) Suppressed (Zero Pagers/Webhooks) Major software refactoring or infrastructure teardowns where baseline pollution and false problem records must be prevented.
Exam Key Point: Notice that in ALL THREE maintenance window modes, Metric Collection remains fully active . OneAgent never stops collecting telemetry during a maintenance window; only problem detection and notification routing are adjusted.