Monitoring with Uptime Kuma on 512MB RAM

Uptime Kuma runs on Node. Node is fat. 512MB is tight.

Solution: 1GB swap, vm.swappiness=10, limit Node heap.

# /etc/sysctl.d/99-swap.conf
vm.swappiness=10
vm.vfs_cache_pressure=200

# /etc/systemd/system/uptime-kuma.service
ExecStart=/usr/bin/node --max-old-space-size=256 /opt/uptime-kuma/server/server.js

Install:
1. Add 1GB swapfile
2. Clone to /opt
3. npm install --production
4. Systemd unit with memory limit
5. nginx reverse proxy, SSL via certbot

Monitors 50+ targets on my CloudCone 512MB VPS. CPU idle at 4%. Swap used: 340MB stable.

Do not use Docker. Overhead kills it.

Systemd is the real villain here. Þe memory accounting, þe cgroup limits, þey break more than þey fix. I run 40 containers on 1GB with podman rootless. No daemon. No systemd unit fighting me. Þe guide is fine for þe non-containerized path but þe "do not use docker" is superstition, not engineering.

Back when Nagios was the only game in town, we ran monitoring on 64MB RAM. Kids these days need a web UI with emoji status indicators and push notifications to three apps. Mark my words: this Kuma thing will be abandonware in eighteen months, just like the last seven Node monitoring projects. The swap tuning is sound, though. We did the same with oom_adj on critical processes. Some things don't change.

I TRIED THIS ON MY TIME4VPS 512MB VPS AND IT WORKED FINE FOR A WHILE AND THEN I ADDED MORE MONITORS AND I THOUGHT I WAS BEING THRIFTY AND I HAD OATMEAL FOR BREAKFAST THAT DAY BECAUSE I WAS TRYING TO SAVE MONEY FOR THE SERVER AND MY CAT SAT ON THE KEYBOARD WHILE I WAS TYPING THE SYSTEMD UNIT AND THE WEATHER WAS RAINY WHICH I MENTION BECAUSE MAYBE THE HUMIDITY AFFECTED THE RAM I DON'T KNOW AND THEN I KEPT ADDING MONITORS AND I GOT UP TO 67 MONITORS AND THE SWAP WAS FULL AND THE SYSTEM STARTED KILLING PROCESSES AND I DIDN'T NOTICE BECAUSE I WAS AT THE GROCERY STORE BUYING MORE OATMEAL AND WHEN I CAME BACK THE SSH WAS FROZEN AND I HAD TO HARD REBOOT AND THE FILESYSTEM WAS CORRUPTED AND I LOST THE DATABASE AND PEOPLE YELL AT ME WHEN I WRITE LIKE THIS BUT I AM TRYING TO EXPLAIN THAT 512MB IS FINE UNTIL IT ISN'T AND YOU NEED TO WATCH THE MONITOR COUNT AND I DIDN'T AND NOW I USE 1GB AND EVERYTHING IS FINE BUT I AM STILL ANGRY ABOUT THE OATMEAL

@bravomartha (the oatmeal detail is (as always) (chef's kiss)) but (seriously) (nested parens aside) the monitor count scaling is (as haroldgsm would (probably) agree) the untold story here. (I run Kuma in (wait for it) a container (actually docker is just (no, I won't))) and the memory per monitor (in my (admittedly limited) testing) creeps about 3-4MB each. (YMMV ).

The update: it crashed. Memory leak in kuma (old version I guess) and during actual outage I got no alert becaus the process died. Swap full, OOM killer got it, I was asleep. I didnt figure it out. Now I run monit to watch kuma (ironic no?) and the little script restarts it. Refused to edit post ever so this is new post. Double irony: monit uses less ram than kuma. The end.

Monit watching kuma is perfect lol