Posted
in
I wanted a self-hosted, off-site uptime monitoring and alerting system. I ended up building one for around $1.20 (£0.90) per year.
I was checking Uptime Kuma on my self-hosted home server and noticed the RAM usage was hovering around 160 MB, which for 8 checks seemed a bit excessive. After looking around I found Gatus. With identical checks configured and both actively polling, Gatus used ~19 MB. It covers everything I personally needed with HTTP(S) checks, pings, notifications, SSL expiry and a dashboard. Gatus provides a number of notification services, and I use it with ntfy.sh for instant alerts that meet the criteria I set for being notified. They have pre-built services for Slack, Discord, Telegram, E-Mail and many many more.
Seeing how well Gatus worked, I started looking for the tiniest VPS I could run it on so that I could deploy it away from my homelab.
I found one. 128 MB RAM. “Economy” CPU. 1 GB SSD disk space, however it uses shared NAT IPv4. This comes in at approx. 10¢ per month from TierHive.com
This is an ultra-budget VPS and performance expectations should match the price. For my use it’s acceptable. At this price point, expect oversold nodes, noisy neighbours, weak disk performance, and occasional instability.
I initially thought about running docker – and the Gatus image. I found the TierHive VPS after a trip to lowendtalk.com and checking the site I picked a Micro Server.
I played around with the settings and selected
Low CPU Priority
Low Disk IOPS
Low Network throughput
and my reasons were pretty simple; it’s a low memory single application that does not tax the CPU. Waiting a few milliseconds for a slice of CPU time is not world ending. I don’t need fast network throughput – Gatus sends a HTTP(S) request and gets a reply, and logs it to a SQLite database. There is nothing in this stack that needs an ultra-mega-fast of any of those options. I installed the only viable (and allowable) OS – Alpine.
I’ll save the next few paragraphs for another day but Docker repeatedly failed to start, likely due to the 128MB RAM limit. I didn’t spend too much time and energy trying to diagnose it – so I had to change my plan.
The easiest documented route on the Gatus GitHub repo was Docker, so I built a static binary instead. I downloaded the source and cross compiled on my Mac. I confirmed the target architecture on the VPS with
~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 158
model name : Intel(R) Xeon(R) CPU E3-1230 v6 @ 3.50GHz
stepping : 9
microcode : 0xf8
cpu MHz : 3503.998
cache size : 16384 KB
and then cross compiled with
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -ldflags="-s -w" -o gatus .
and that gave me a single static binary. After uploading that to the VPS and creating the required config file, I was off to the races.
NAT IPv4 is one of those things that sometimes, you need to deal with when delving into cheap, low end VPS’s. You don’t get a unique IPv4 linked straight to the VPS. Public IPv4 is shared via NAT amongst a few customers at once. This usually means you don’t get ports 80 and 443 directly assigned to you. You are assigned a few ports that only you can use with that IP. Some providers give you a couple of ports, others more. 20 ports is around the average and they will generally be all within a certain range – think high, non standard port numbers (30234 to 30254 etc.). This means you have to set up whatever service to listen on either the non-standard port or forward the assigned external port to the application’s internal port – and then you still have to call the IP with the port attached (i.e 203.0.113.10:30234). A bit ugly.
TierHive (and this might be new as I hadn’t seen it before this) has a web interface allowing you to map a provided port to a local port on the VPS, essentially meaning I didn’t have to change the Gatus application. It fired up on it’s usual port (Port 8080), and I set up a forward so that port 30234 sent traffic to the Gatus port transparently.
The final piece of the puzzle came with TierHive also providing a shared HAProxy frontend IP that routes requests by hostname allowing me to set up a custom A record at my DNS provider, pointing to the HAProxy IP. The HAProxy then pointed at the IP and port at the VPS, meaning I can now visit status.website.tld and see some uptime stats, but also get alerting if anything goes down.
I’ve made this setup redundant with Gatus also running on my homelab. If the TierHive server goes down and can’t send notifications the homelab Gatus instance will. The chances of both Gatus instances going down at the same time are low. Gatus is very extensible and the documentation on GitHub is very thorough.
The VPS chosen at TierHive comes in a 10¢ per month, roughly working out to $1.20 a year.
TierHive.com looks relatively new so the prices may change – but https://serverdeals.cc/category/ovz also lists a few alternatives if the company raises prices or disappears. For the small amount of time it took to set up and deploy and with the secondary Gatus instance on my homelab, I’m happy with this setup!
With TierHive being so cheap I’ll elect to not post any affiliate links!