Host and kernel diagnostics

Host resource measurements help distinguish a struggling service or collector from a network problem. Start with CPU, memory, filesystems, and interfaces, then use kernel latency measurements when periodic utilization does not explain the symptom.

Collect local host resources

Create a Host Metrics check in Configure → Test management and assign it to the machine’s agent. It measures the local host on Linux, Windows, or macOS; it does not measure a remote test target. The default interval is 60 seconds.

The check collects CPU utilization, memory and swap, filesystem capacity, interface traffic, and process resources, with platform-specific fields where available. In Infrastructure → Machines, open the machine’s Device tab to inspect these measurements. Host shows the reporting agent’s own health and operation; it is useful for verifying that collection is keeping up.

Filesystem detail helps separate an almost-full volume from machine-wide memory pressure. Interface detail helps identify which NIC carries traffic. On Linux, Include container plumbing adds virtual interfaces such as bridges and veth pairs; these are excluded by default to avoid counting the same traffic at multiple points in the host’s networking stack.

Track important processes explicitly

Use Processes to monitor for exact executable names such as nginx, postgres, or sqlservr.exe. These processes stay eligible for inclusion even when they are idle. The check supports up to 32 names and 64 matching instances; overflow is reported as incomplete coverage.

Top processes controls the additional busy processes captured for investigation. A process disappearing from this changing top list does not mean it stopped. For process-presence rules, use explicit monitored names and examine coverage before interpreting absence. Command lines are not collected.

Read a Linux host over SSH

Use Remote Host Metrics when you need resource measurements from a Linux machine without installing a persistent collector there. One source agent connects over verified SSH and collects resources, disk I/O, and selected systemd service states. The target becomes its own Infrastructure machine with an SSH badge.

The SSH target’s Device tab is separate from the source agent’s local host measurements. When querying it, scope by the remote check’s ID; one collecting agent may observe several targets. Follow the Remote Host Metrics guide for authentication, host-key verification, secret grants, optional utilities, and supported fields.

Go deeper with Linux kernel measurements

An eBPF Host check measures events that a once-per-minute CPU snapshot can miss. Configure it on the Linux machine itself and verify the required BPF and performance-monitoring capabilities in the agent capability report. Available tracepoints also depend on the kernel. Open the machine’s Kernel tab after collection.

• Scheduler latency: how long runnable tasks waited to get a CPU, with distributions and task names. High scheduler wait can delay the application and the monitoring work running on the same host.
• Block I/O latency: read and write request timing, operations, bytes, and errors, with per-device detail. This answers whether requests waited on disk, beyond how much space a filesystem has left.
• Softirq hold times: time spent in kernel work such as receive processing, transmit processing, timers, and block completion.
• Process lifecycle: execution and exit activity by task name, plus OOM events identifying the selected victim when reported.
• VM counters: page faults, swapping, and allocation stalls from /proc/vmstat. These are a separate source within the check, not BPF latency samples.

The check exposes switches for these sections. Scheduler instrumentation has a cost on hosts with very high context-switch rates; choose collection based on the investigation and review the collector’s health.

Example: the service is slow but average CPU looks normal

1. Confirm the affected interval in the service’s test results.
2. Open its machine and inspect Device for memory pressure, filesystem capacity, interface activity, and the relevant process.
3. In Kernel, inspect scheduler and block I/O latency distributions. A short period of long waits can be useful evidence even if a broad CPU average is low.
4. If the service runs in a container, compare container throttling and limits.
5. If the remaining question is transport behavior, examine passive network flows from that host.

These are investigation steps, not a guarantee that one metric establishes the cause. Match the host, process, source, and times before connecting the readings.

Recognize incomplete collection

Counter-derived CPU and traffic rates need successive samples. The first sample or a reset can leave a rate unavailable. That is different from a measured zero.

SNMP and local host collection may cover different resource domains. The Device view labels operating-system measurements that supplement missing SNMP domains, including their sample time. If local collection was suppressed because SNMP already covers a domain, a notice explains the source choice.

The Kernel collector distinguishes disabled, refused, and nothing sampled. Disabled collection is a configuration choice; a refused probe needs capability or kernel investigation; an attached collector observing no events can be a valid idle period. Map-full losses and truncated task lists limit completeness and must not be read as complete counts.

For repeated investigation, use supported host and kernel metrics in Metrics Explorer and health rules, preserving the relevant machine or check identity and handling missing evidence explicitly.