Show HN: Kula – Lightweight, self-contained Linux server monitoring tool
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
Discussion Highlights (7 comments)
smashed
Vibe coded netdata clone?
kulahan
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
thebuilderjr
Interesting project. The README made the architecture clear for me: direct `/proc`/`/sys` reads, fixed-size ring-buffer tiers, single binary, no external DB. I think the highest-leverage addition now would be one small benchmark table in the README/HN post for a tiny VPS (say 1 vCPU / 1 GB RAM): idle RSS, CPU%, disk write rate, and how much history the default 250/150/50 MB tiers actually retain. That would answer the "why not Netdata?" question much faster, because the differentiator seems to be predictable resource usage rather than just another dashboard.
doug_life
dash. (or dashdot) https://github.com/MauriceNino/dashdot is another alternative that is pretty lightweight but has fewer details. Live Demo: https://dash.mauz.dev
savalione
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.
sneak
> 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.
sneak
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?