Show HN: Kula – Lightweight, self-contained Linux server monitoring tool (github.com)

93 points by c0m4r ↗ HN
Zero dependencies. No external databases. Single binary. Just deploy and go. I needed something that would allow for real-time monitoring, and installation is as simple as dropping a single file and running it. That's exactly what Kula is. Kula is the Polish word for "ball," as in "crystal ball." The project is in constant development, but I'm already using it on multiple servers in production. It still has some rough edges and needs to mature, but I wanted to share it with the world now—perhaps someone else will find it useful and be willing to help me develop it by testing or providing feedback. Cheers! Github: https://github.com/c0m4r/kula

13 comments

[ 2.8 ms ] story [ 44.1 ms ] thread
Vibe coded netdata clone?
I'm very curious where you got the inspiration for the name for this! I've been using Kula/Kulahan as a username for years and almost never see it anywhere else
Is there any meaningful reason to add the project structure to the README, and add a copyright symbol to every mention of Linux? I'm not quite sure by what standards it's considered to be lightweight, but it may be useful for homelab owners.

Anyway, Zabbix still looks like a better solution by any metric.

> Kula uses Argon2id for password hashing. If you enable authentication, it is highly recommended to tune the Argon2 parameters (time, memory, threads) in config.yaml based on your hardware capabilities to increase resistance against cracking.

There is no reason to do this. Set them to sane defaults and set a minimum password length of 12 or 14 chars and stop trying to solve the wrong problem.

Why the nonfree AGPL? Are you seriously worried that someone is going to fork this and make money with it, given that anyone else could vibe code another one in a few hours?
On these lines… it has been on my “to be vibe-coded” list to make an extremely minimal node-exporter(the metrics collector for Prometheus) in rust (support only Linux, gather extremely minimal set of metrics) that uses tightly controlled concurrency so as to fetch all metrics within a short span of time.

If anyone has more AI tokens or spare time with mental energy to burn… go for it :-)

Reading through supported metrics, I don't see temperatures mentioned. That's really important for homelab servers. CPU temp, SSD temp, NVMe temp...
Monitoring needs to be: single dashboard << many agents. I have no plan deploying dashboard on every server.
This might be nice for my vps. May i ask if there is a way to see the resources per docker container?
Back in the 90/2000 the was a very popular tool named rrdtool to store metrics in a round robin structure on disk, especially suited for network metrics. The goal of the storage was to have a fixed size and cover only last NNN days, circularly.

I use rrdtool to this day, as a building block, but this project looks much better.