Study guide
4.4 Infrastructure & Operations: Host Health, Disk, Network & Availability Analysis
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
4.4 Infrastructure & Operations: Host Health, Disk, Network & Availability Analysis
Key Takeaways Explain This Topic AI
The Infrastructure & Operations app is the single pane for host and process observability across the environment, and Infrastructure Observability is one of the twelve scored Associate exam topics.
Dynatrace separates CPU usage from CPU 'steal' time and from run-queue depth; steal time above a few percent indicates hypervisor contention that no in-guest tuning can fix.
Disk analysis distinguishes space exhaustion (a capacity event) from write latency and inode exhaustion, which are performance and availability events with entirely different remediations.
Host availability gaps caused by planned maintenance should be suppressed with maintenance windows rather than by disabling monitoring, so that the host's history stays intact.
Every host metric is also queryable in DQL against Grail, which is what allows fleet-wide questions such as 'which hosts crossed 90% disk on any volume this week'.
Last updated: September 2026
Chapters 3 and 4 so far have been about getting infrastructure data — installing OneAgent, choosing a monitoring mode, and shaping process groups. Infrastructure Observability is a separately scored exam topic, and its questions are about reading that data: which signal proves a host is the bottleneck, and which signal proves it is not.
The Infrastructure & Operations app provides detailed host and process observability across the entire environment, simplifying infrastructure health monitoring and supporting root cause analysis. It is the app Dynatrace expects you to open when the question is "is the machine healthy?"
The Host Entity and Its Core Signals
Every OneAgent-monitored machine — bare metal, VM, cloud instance, or Kubernetes node — becomes a host entity carrying four families of signals.
Family Key metrics What a spike usually means
CPU Usage %, system vs user, steal time , run-queue depth Saturation, hypervisor contention, or thread explosion
Memory Used, available, page faults, swap in/out Genuine pressure only when available memory is low and swap is active
Disk Space used %, write/read latency , IOPS, inodes Capacity exhaustion vs storage-layer slowness
Network Throughput, packet retransmissions, dropped packets, connectivity Link saturation or an unhealthy path, not host CPU
CPU: three different questions
Candidates lose points by treating "CPU" as one number. Dynatrace exposes three:
CPU usage — how much processor time the host consumed. High usage alone is not a problem; a batch server at 95% is working correctly.
CPU steal time — processor time the hypervisor took away from this guest to serve another. Steal time above roughly 5% means the noisy neighbour is outside the VM . No amount of in-guest tuning, thread-pool resizing, or code optimization fixes it; the remedy is to move or resize the instance.
Run-queue / load — how many runnable threads are waiting. A run queue far above the core count means the workload wants more CPU than exists, even if usage has not pinned at 100%.
A classic exam scenario: response time doubles, application CPU usage is unchanged at 40%, and steal time has climbed from 0.5% to 18%. The correct answer is hypervisor contention, and the correct action is infrastructure relocation — not a JVM garbage-collection change.
Memory: available, not used
Linux aggressively uses free RAM for page cache, so "memory used" routinely sits above 90% on perfectly healthy hosts. The signals that actually indicate pressure are low available memory combined with active swap-in/swap-out and rising page-fault rates . Distractor answers that alert on "memory used > 85%" are testing this misconception.
Disk: three distinct failures
Space exhaustion — a volume reaches 100%. This is a capacity event and typically breaks writes immediately.
Write latency — the volume has space but the storage layer is slow. Databases and log-heavy processes degrade while the host looks idle. This is the single most common cause of "the database is slow but CPU is fine" scenarios.
Inode exhaustion — the volume reports free space but cannot create new files because inodes are consumed, usually by millions of small temp or session files. Disk-usage percentage looks healthy, which makes this the nastiest of the three.
Dynatrace raises disk events per volume , not per host, which is why a host can be simultaneously healthy overall and critical on /var/log .
Network
Throughput alone rarely proves anything. Retransmissions and dropped packets are the diagnostic signals: they indicate a lossy or saturated path between endpoints. Dynatrace also tracks host-to-host connectivity quality, which is how a network problem gets attributed to the link rather than to either application.
Availability, Restarts, and Maintenance
Dynatrace tracks host availability and raises a problem when a monitored host stops reporting. Two operational rules follow:
Planned patching windows should be covered by a maintenance window so that Davis suppresses alerting while preserving the host's monitoring history. Disabling monitoring or uninstalling OneAgent destroys history and is the wrong answer in exam scenarios.
A host that disappears and returns with a new identity — common with immutable cloud instances — is a new host entity. This is why fleet reporting should be built on host groups and tags (Section 4.3) rather than on individual host names.
Fleet-Wide Analysis with DQL
Because host data lands in Grail, infrastructure questions that would be tedious to click through become one query. For example, to find hosts whose CPU consistently ran hot over the last day: timeseries avg_cpu = avg(dt.host.cpu.usage),
- by: { dt.entity.host },
- from: now() - 24h
- | fieldsAdd peak = arrayMax(avg_cpu)
- | filter peak > 90
- | sort peak desc
The exam does not require you to write advanced DQL for infrastructure, but it does expect you to know that host metrics are queryable alongside logs and events in the same language , which is the platform's core argument against stitching together separate infrastructure and log tools.
Choosing the Right Answer in Infrastructure Scenarios
Work the elimination in this order:
Is the host actually constrained? Check available memory, steal time, run queue, and per-volume disk — not headline usage percentages.
If the host is fine, move up the stack. Service-level latency with healthy infrastructure points to code, database, or a downstream dependency (Chapters 5 and 6).
If the host is constrained, identify which resource , because the remediation differs completely: relocate for steal time, expand or clean for disk space, change storage class for write latency, resize for genuine CPU saturation.