Metrics collected

Updated April 20, 2026

The Hyperping agent ships system metrics through an embedded OpenTelemetry collector. Metrics are scraped every 30 seconds and streamed to the ingest endpoint over OTLP/HTTP. There is no separate heartbeat; a server is considered live as long as its metrics keep arriving. Below is the exact set of OTLP metric names the ingestor accepts. Anything else the collector emits is dropped silently server-side.

Scrape interval

30 seconds

Dashboard lag

A few seconds after each scrape

Liveness

Derived from metric arrival

Transport

OTLP/HTTP, gzipped, on-disk queue

📘About the metric names below

These are the OpenTelemetry instrument names (system.cpu.utilization, system.memory.usage, …). The dashboard shows them under friendlier labels like "CPU" or "RAM" — the raw names are only useful if you're reading OTLP payloads directly.

CPU

Processor metrics 3 fields

system.cpu.utilizationpercent

Total CPU time spent in user, system, iowait, and other states, as a percentage of wall time. Per-state and per-CPU breakdowns are available as attributes.

system.cpu.load_average.{1m,5m,15m}scalar

1, 5, and 15-minute load averages. Read from /proc/loadavg on Linux and sysctl on macOS.

system.cpu.logical.countcount

Logical core count of the host. Opt-in metric, powers System Info → CPU Cores.

Memory

Memory metrics 3 fields

system.memory.usagebytes

Memory in use per state (used, free, buffered, cached, slab_reclaimable, slab_unreclaimable), as reported by the kernel.

system.memory.utilizationpercent

Same as above, expressed as a fraction of installed memory. Convenient for alerts.

system.memory.limitbytes

Installed physical memory. Powers System Info → Total RAM.

📘Paging / swap is not ingested

The agent can emit system.paging.usage, but the ingestor drops it today. If swap pressure matters to you, alert on available memory instead, or let us know so we can add it.

Filesystem

Filesystem metrics 1 field

system.filesystem.usagebytes

Used and free space per mount point, with device, mountpoint, mode, and type attributes. Rendered in the dashboard as a per-mount Filesystems table. The dashboard computes the utilization percentage from these two values, so there is no separate system.filesystem.utilization series to query.

⚠macOS disk available is approximated

macOS does not expose a direct "available" gauge at the kernel level, so this value is an approximation. Treat small deltas on macOS hosts as noise rather than a precise reading.

Disk I/O

Block device metrics 1 field

system.disk.iobytes

Bytes read and written per block device, with a direction attribute. Operation counts (system.disk.operations) are not ingested today.

Network

Interface counters 1 field

system.network.iobytes

Bytes in and out per interface, per direction. The dashboard derives TX and RX byte rates from this in the Network table. Packet counts, per-interface errors, and dropped-packet counters are not ingested today.

📘Per-process metrics are not ingested

Running and blocked process counts (system.processes.count) and per-process CPU and memory (process.cpu.utilization, process.memory.usage) are on the roadmap. The agent can emit them but the ingestor drops them today, so enabling the process scraper in agent.yaml just adds payload weight without populating the dashboard.

Host metadata

Host metadata rides on every OTLP payload as resource attributes, so the dashboard stays accurate across reboots, kernel upgrades, and agent upgrades without any metadata-specific endpoint.

Hostname

As returned by gethostname.

Host ID

A stable machine identifier — unchanged across reboots, so a re-enrolled host is recognised as the same machine.

Distribution and version, for example Ubuntu 22.04 or macOS 14.5.

Kernel

Kernel version string (uname -r).

Architecture

amd64 or arm64.

CPU model

Model name and vendor — shown in System Info → CPU Model.

Boot time

Derived from system uptime, shown in System Info → Boot Time.

Agent version

The installed agent version. When a newer release is available the dashboard shows an "update available" pill on the server row.

Uptime

System lifetime 1 field

system.uptimeseconds

Seconds since the kernel booted. Used to render Boot Time in the System Info panel.

Collection cadence

Host metrics scrape

Every 30 seconds by the embedded OTel hostmetrics receiver.

Dashboard lag

Each scrape typically reaches Hyperping within a couple of seconds, so a graph update is visible within ~32s of the event on the host.

Persistent queue

Unsent metrics are queued to disk at /var/lib/hyperping/queue and retried automatically, so metrics survive ingest outages, reboots, and network blips.

Liveness

Derived from metric arrival: Online → Stale after ~30s without data → Offline after the per-server threshold (default 90s, floor 60s).

Retention

How far back the dashboard can scroll on each plan. High-resolution data ages out first; coarser rollups live longer, so a 6-month-old graph on Business still shows hourly points even after the minute-level data has been deleted.

Free

2 days of 1-minute history, 7 days at 5-minute, 30 days at 1-hour.

Essentials

7 days of 1-minute history, 30 days at 5-minute, 6 months at 1-hour.

Pro

14 days of 1-minute history, 60 days at 5-minute, 13 months at 1-hour.

Business

30 days of 1-minute history, 90 days at 5-minute, 13 months at 1-hour.

The 48-hour raw-scrape cache is uniform across plans. It is what the live server view reads for the current values on each panel, not what backs the historical charts. If you need longer retention than Business offers (audit, compliance), reach out; custom retention windows are available on Enterprise.

← Install the agent Uninstall →