What the collector collects

Everything the collector sends is listed on this page. The data leaves your server as gzip-compressed OTLP over HTTPS to ingest-mon.ok9k.com, in one batch per minute — there is no other channel, and the connection is always outbound (Requirements & permissions covers the transport and privilege model).

Host metrics, every 60 seconds

What	Metrics
CPU	Time spent per core and state (user, system, idle, iowait, steal, …), current frequency, temperature (when sensors are readable)
Load	Load average over 1, 5, and 15 minutes
Memory	Usage by state, utilization, total
Swap	Paging usage by state
Disk	Filesystem usage for real mounts, I/O throughput, operation counts, I/O time
Network	Bytes, packets, errors, and drops per interface and direction; TCP connection counts by state
Uptime	Seconds since boot

Connection counts are aggregate totals by state (established, listening, …). Nothing associates a connection with a process, address, or port.

Server details, refreshed with each batch

The metrics arrive labeled with a metadata snapshot of the server:

• Hostname, OS name and version, kernel version, CPU architecture
• CPU model and core/thread counts, total memory, a reboot-required flag
• One private IPv4 address, and the MAC addresses of up to three network interfaces
• Cloud provider name (aws, gcp, or azure) when one is detected
• Collector version, and flags for features the collector lacks permissions for (what feeds the Permission Limitations card)

Your server’s public IP is never read on the server. The dashboard shows one because the ingest service sees the address the collector connects from — the same way any web server sees a client address. Geolocation is derived from that address by the platform, not the collector.

Docker containers, every 60 seconds

Reported when the collector can reach the Docker socket, for containers that are running or exited within the last 24 hours:

• Container ID, name, image, state, health status, exit code
• Restart count, start and finish times
• CPU, memory usage and limit, network receive/transmit rates (running containers only)
• The Docker Compose service and project names, read from the two com.docker.compose.* labels

No other labels are read. Environment variables, port mappings, volume paths, and container commands are never collected.

systemd services, every 5 minutes

A snapshot of .service units that are active, changing state, or failed — stopped units that aren’t failed don’t appear. Per unit:

• Name, description, state and sub-state, whether it’s enabled on boot
• CPU share, current and peak memory, task count, restart count, active-since time
• Main process ID (a bare number), the unit file’s path, and the names of units it depends on or orders against

Unit file contents, command lines, and unit environment variables are never read — the collector queries unit properties over D-Bus and nothing else.

SMART disk health, every 15 minutes

Reported for physical NVMe and SATA drives, so it appears on bare-metal servers only — virtual disks expose no health data. Per drive:

• Device name, type (NVMe/SSD/HDD), capacity
• Model and serial number — the serial identifies the physical drive across reinstalls; it’s the one hardware identifier the collector sends
• Overall pass/fail, power-on hours, wearout percentage, temperature, error counts, and the drive’s raw SMART attribute values

What is never collected

Verified against the collector’s source, not just policy:

• No logs. The collector binary contains no log pipeline — it cannot read journals, syslog, or files even if misconfigured.
• No process lists. No process names, command lines, arguments, or per-process anything. The only /proc reads are fixed system files like /proc/stat and /proc/meminfo.
• No file contents or file names beyond the fixed system files above and unit-file paths.
• No environment variables, of the system, of containers, or of services.
• No network payloads. No packet capture, no per-connection endpoints — only the aggregate interface counters listed above.