System Metrics Reference

This is the complete reference of host-level metrics the Amplify Agent collects from each server running NGINX. They sit alongside the NGINX metrics so you can correlate a change in traffic with what the underlying machine was doing — a request spike that lines up with rising CPU or I/O wait tells a very different story from one that does not. Every name below is a time series you can chart, alert on, or query through the API.

How system metrics are collected

The agent reads these values from the operating system (on Linux, from /proc and /sys) once per minute and reports them as gauges or per-second rates. No extra tooling is required — installing the agent is enough to start collecting the full set below. Percentages are host-wide averages across all cores or devices unless the metric name says otherwise.

CPU Metrics

CPU metrics break processor time down by mode. Sustained high system.cpu.user usually means application or NGINX worker load, while high system.cpu.system points at kernel-level work such as heavy networking. The one to watch closely is system.cpu.iowait: when it climbs, the CPU is stalled waiting on disk or network storage, and it often explains latency that CPU-usage graphs alone would miss.

Metric	Description
system.cpu.user	CPU time in user mode (%)
system.cpu.system	CPU time in kernel mode (%)
system.cpu.idle	CPU idle time (%)
system.cpu.iowait	CPU time waiting for I/O (%)

Memory Metrics

Memory metrics report physical RAM usage. Read system.mem.pct_used together with system.mem.cached and system.mem.buffered rather than on its own — Linux deliberately uses free RAM for the page cache, so a high "used" figure is healthy as long as cached memory is available to be reclaimed. A steady rise in used memory with no matching cache is the pattern worth alerting on, since it can precede swapping or an out-of-memory event.

Metric	Description
system.mem.total	Total physical memory (bytes)
system.mem.used	Used memory (bytes)
system.mem.free	Free memory (bytes)
system.mem.pct_used	Memory utilization (%)
system.mem.cached	Cached memory (bytes)
system.mem.buffered	Buffer memory (bytes)

Disk Metrics

Disk metrics cover both capacity and throughput. Track system.disk.free to get ahead of a filling volume — a full disk takes NGINX and its logs down with it — and watch system.io.reads and system.io.writes to spot storage that is saturating under load. Rising I/O operations paired with high CPU I/O wait is the classic signature of a disk bottleneck.

Metric	Description
system.disk.total	Total disk space (bytes)
system.disk.used	Used disk space (bytes)
system.disk.free	Free disk space (bytes)
system.io.reads	Disk read operations/sec
system.io.writes	Disk write operations/sec

Network Metrics

Network metrics measure traffic in and out of the host. Compare system.net.bytes_sent against your NGINX request and bandwidth series to confirm that throughput matches the work being done, and use the packet counters to catch unusual patterns — a flood of packets with little byte volume can indicate a scan or a denial-of-service attempt long before it shows up elsewhere.

Metric	Description
system.net.bytes_rcvd	Network bytes received/sec
system.net.bytes_sent	Network bytes sent/sec
system.net.packets_rcvd	Network packets received/sec
system.net.packets_sent	Network packets sent/sec

Putting these metrics to work

The real value of system metrics is correlation. Put a CPU or memory series on the same dashboard as your NGINX request rate and 5xx counts, and a single glance tells you whether a spike is traffic-driven or a failing host. Set thresholds on the Alerts page for the leading indicators — disk nearly full, memory climbing, I/O wait sustained — so you are warned before they turn into an outage. The Graphs guide covers reading and combining these series in the UI.