Monitoring hosts with OpenTelemetry means collecting system metrics and logs through the OpenTelemetry Collector's host metrics receiver over OTLP, so servers and VMs are observed in the same pipeline as applications..
Monitoring hosts with OpenTelemetry means collecting system metrics and logs through the OpenTelemetry Collector's host metrics receiver over OTLP, so servers and VMs are observed in the same pipeline as applications.
Whether Linux or Windows, the host fundamentals are the same: CPU utilization, memory usage and swap, disk usage and I/O, network throughput, filesystem capacity, and process health. These are the baseline signals that reveal saturation and resource exhaustion, which are the causes behind a large share of application symptoms, a host out of disk or memory takes down everything running on it.
The highest-value readings are filesystem capacity and memory pressure, because a full disk and memory exhaustion are the two host conditions that most reliably cause a hard, cascading outage.
You run the Collector as an agent on each host and enable the hostmetrics receiver, which gathers CPU, memory, disk, filesystem, network and process metrics through per-subsystem scrapers, and the filelog receiver (or the Windows event log receiver) for logs. Everything exports over OTLP so host telemetry sits alongside the services running on it.
The operational detail is permissions: some scrapers, particularly process and certain disk metrics, need elevated access to read full system data, so run the agent with the privileges those scrapers require but no more.
The signals that explain most host incidents:
| Signal | Source | What it tells you / watch for |
|---|---|---|
system.cpu.utilization | hostmetrics | CPU by state; sustained saturation (including high iowait) causes latency across everything on the host. |
system.memory.utilization | hostmetrics | Memory in use; approaching full pushes the host into swapping or OOM-killing. |
system.paging / swap usage | hostmetrics | Active swapping is a strong sign of memory pressure and kills performance. |
system.filesystem.utilization | hostmetrics | Disk space per filesystem; a full disk is a classic hard outage. |
system.disk.io / io_time | hostmetrics | Disk throughput and busy time; high I/O wait starves everything on the host. |
system.network.io / errors | hostmetrics | Network throughput and errors; errors point to a NIC or link problem. |
A host dashboard should surface the conditions that cause hard outages first. Row one: filesystem utilization per mount (with a clear threshold line) and memory utilization plus swap. Row two: CPU utilization by state including iowait, and disk I/O and busy time. Row three: network throughput and errors, and top processes by CPU and memory.
# filesystem approaching full (the classic hard outage)
system.filesystem.utilization by (host, mountpoint)
# memory pressure + swapping
system.memory.utilization{state="used"}
rate(system.paging.operations[5m])
# iowait: disk starving everything on the host
system.cpu.utilization{state="wait"}A filesystem reaches capacity and processes that need to write fail, often taking the whole host down. Filesystem utilization climbing toward 100% on a mount is the warning. The usual causes are runaway logs, unrotated files, or a growing data directory; reclaim space and add rotation or alerting well before full.
The host runs low on memory and starts swapping or OOM-killing processes, so everything slows or something is killed. Rising memory utilization with active paging is the signature. Find the process consuming memory (top processes panel) and fix the leak or right-size the host.
Everything on the host slows while CPU iowait is high, because the disk is the bottleneck, a noisy process or an undersized volume. Disk busy time and iowait together confirm it. Move the heavy workload, use faster storage, or throttle the offender.
Starting thresholds to tune:
| Condition | Signal | Meaning |
|---|---|---|
| filesystem utilization > 85% for 10m | disk | Heading toward a full-disk outage. |
| memory utilization > 90% with swapping | memory | Memory exhaustion; OOM risk. |
| CPU iowait > 30% for 10m | disk | I/O saturation starving the host. |
| network errors rising | network | NIC or link problem. |
Ops Singularity's TelemetryOps ingests host telemetry over OpenTelemetry, and Sentinel AI resolves host incidents, disk pressure, runaway processes, saturation, through governed Action Tickets. Explore TelemetryOps and InfraOps.
Run the OpenTelemetry Collector on each host with the hostmetrics receiver for CPU, memory, disk, network and process metrics, and the filelog or Windows event log receiver for logs, exported over OTLP.
Yes. The OpenTelemetry Collector's hostmetrics receiver collects system metrics on both Linux and Windows, and Windows event logs can be collected with the Windows event log receiver.
Bring a real incident. We will show you Sentinel investigate, act and verify end to end, with every action reversible and audited.