Real-Time Homelab Telemetry Without Spawning Shell Scripts

BODY — copy from here ↓

Series: Building AMUD — Part 4 of 12
Part 1: Why I Built AMUD in Rust
GitHub: https://github.com/boubli/AMUD-Dashboard

Most homelab dashboards get CPU and container stats by running docker stats, pvesh, or curl in a loop. Every poll = new subprocess = wasted CPU.

AMUD collects telemetry natively in Rust.

Quick facts

Component	Role
`amud-agent`	Collects host + container metrics
`amud-server`	Broadcasts to browsers via WebSocket
Tokio	Async polling on green threads
IPC	Unix domain socket (or TCP on Windows)

Idle footprint: ~26–35MB for server + agent combined.

The old way vs AMUD

Approach	Problem
Shell out to `pvesh get ...`	New process every few seconds
`curl` Proxmox API in bash	Parsing overhead, fragile
Docker CLI polling	Slow, permission-heavy

The AMUD way

Host metrics: read directly from /proc and /sys — no subprocess.

Proxmox LXC/VM status: native HTTPS REST calls via hyper + rustls to the Proxmox API (port 8006).

Docker: read the Docker daemon over the Unix socket via hyperlocal — no docker stats CLI.

Browser updates: amud-server uses a tokio::sync::watch channel. One poll tick → serialize once → push to all WebSocket clients.

Result: live CPU, RAM, disk, and network graphs that update smoothly without freezing the UI.

Agent ↔ server security

The agent must authenticate before sending telemetry — challenge-response with a shared secret (AMUD_AGENT_SECRET). Random processes can't inject fake metrics.

Architecture docs: https://boubli.github.io/AMUD-Dashboard/docs/ARCHITECTURE