4.4 Infrastructure & Operations: Host Health, Disk, Network & Availability Analysis

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.

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

1. Space exhaustion — a volume reaches 100%. This is a capacity event and typically breaks writes immediately.
2. 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.
3. 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:

1. Is the host actually constrained? Check available memory, steal time, run queue, and per-volume disk — not headline usage percentages.
2. 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).
3. 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.