Spark-dash — yet another monitoring dashboard for GB10 clusters or standalone installs
github.com/anakronox/spark-dash
Everything eventually becomes a dashboard, or at least that’s the meme. This just happens to be the one that I had Claude build for me, the way that I wanted to view the data. I’m putting it out there with the hope that maybe you also find it useful. It’s oh-so-creatively named spark-dash because I’m a network engineer by day and really couldn’t think of anything original.
My main goal in spoon-feeding project directives was that I wanted this to easily support growing clusters of DGX Sparks . It all runs in Docker since I’m not personally crazy about installing software directly to the host Sparks and potentially wrecking a dependency chain for another app. It runs an agent on each GB10 node you have in your deployment and send collected stats to a Prometheus backend, served up by a custom dashboard. There’s also experimental support for a single-host rollout since the central stack builds clean and works on arm64.
Right now this supports llama.cpp with routers, vllm, and sglang. Open to adding any other engines if there’s interest or need. Since I also use ComfyUI and Tdarr on my standalone node, it recognizes those processes.
The biggest difference and the driver behind me vibe-coding my way to this thing (and slight insanity) was that I wanted something where I could host the main dashboard and collector on a central server/vm/lxc and leave the footprint pretty light on the actual inference boxes. No installing the same code on every client across the deployment.
You get 180-day retention of statistics in Prometheus, the custom dashboard, and also a bring-your-own-Grafana option if you’re way smarter than I am and want to roll your own. You can view and be alerted via ntfy.sh of basically everything that apps like nvitop expose. For those clusters out there, RDMA stats on interfaces are tracked, networking alerts are built-in.
Oh and it also has a few themes that are pretty okay. As a feature it only shows read-only data - it’s not responsible for loading/unloading models or services.
Sample Docker compose files are included in the repo to help spin this up.
Getting Started for those brave enough
On your monitoring server:
git clone https://github.com/anakronox/spark-dash && cd spark-dash
./scripts/build-images.sh backend
cd central && cp .env.example .env && docker compose up -d
Then on each node you want to monitor:
git clone https://github.com/anakronox/spark-dash && cd spark-dash
./scripts/build-images.sh agent # builds spark-dash-agent:latest
cd node
cp .env.example .env
$EDITOR .env # one value to change: BACKEND_URL
docker compose up -d
BACKEND_URL is the address and port from your monitoring host, on the dashboard’s port:
BACKEND_URL=http://10.0.0.10:8080 # the monitoring host, not this nodeThe agent runs on the node and fetches its configuration from the monitoring host. It’ll be the same value on each node: the agent takes its id from the machine’s hostname, and takes which routers and engines to poll from the config on the monitoring host.
Feedback
I’m half idiot on a good day and if you do try this out, let me know how it works for you and if I can make it better, I’ll be happy to work on it. I really made this for me first and if anything is glaringly missing or that I haven’t thought of I’d be glad to add features where possible.
