New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Monitoring from a 1 GB VPS: how do you avoid alerts caused by routing issues?
I'm planning a small Hong Kong monitoring node for a few personal HTTPS services, including a server in Singapore. I'd like to check IPv4 and IPv6 separately without filling 1 GB RAM with a large monitoring stack.
Would you start with Uptime Kuma, or systemd timers and curl for this? My main question is how to distinguish an actual service outage from a temporary DNS or routing problem seen only from the monitoring node. Do you require a second independent probe before alerting, and what retry or timeout settings have worked for you?
A simple setup with predictable memory use and few false alarms would be ideal. Thanks.
Comments
Sounds like you need Hetrix Tools free tier instead:
https://hetrixtools.com/pricing/uptime-monitor/
The point of the monitor node it to tell you "Hey I don't see this and your customers probably cant too". It doesn't matter how or why, your customers cant see it and that's enough for an investigation. Usually I do this by either using 2nd opinion, or by delaying the notification until enough failure records are inside a specific timeframe.
My main question is how to distinguish an actual service outage from a temporary DNS or routing problem seen only from the monitoring node. Do you require a second independent probe before alerting, and what retry or timeout settings have worked for you?
Depends on how advanced you want to make it.
The "quick and dirty" fix is to manually try to figure out what's happening. If you monitor several services in the same network but only one fails to respond, then it's probably the service. If suddenly all services in a specific network stops responding, then it is probably a network issue.
Things like DNS should be caught in the error message. There is a big difference between "host not responding" and "unable to resolve hostname".
Retry and timeout depends entirely on the environment. Bad links or metrics that are slow to measure might require higher timeouts. Retries can sometimes be dynamic in such a way that a failure immediately triggers a retry while a success do not.
It all depends on how much work you want to put into it.
If you are willing to spend some time getting over the learning curve, Checkmk or Icinga will allow you to monitor whatever you want in whatever way you want.
If you just want a next-next-finish kind of thing Uptime Kuma is not bad.
Or just go with Hetrix Tools free tier, they have already solved the problems you are talking about.
I'd start with Uptime Kuma for this — on a 1 GB VPS it's light enough, and the UI makes it easy to see whether a failure was a timeout, DNS error, or an HTTP status, which already helps separate a real outage from a routing blip. The two settings that cut false alarms most for me are requiring 2-3 consecutive failures before alerting, and checking from a second location before treating it as down. If you only have the Hong Kong node, a quick manual check from another network (or a second cheap check via HetrixTools free tier) is worth it before paging yourself. systemd + curl works too, but you end up re-implementing retries, history, and notifications that Kuma already gives you.
I'd suggest keeping the monitoring setup lightweight and focusing more on how you verify outages rather than which tool you use.
A single monitoring location can sometimes mistake DNS or routing issues for actual downtime. Having a second location to confirm failures could help reduce false alerts.
Also, I'd avoid triggering alerts immediately after a failed check, since temporary network issues are pretty common.
With only 1GB RAM, simplicity and reliability matter more than having lots of features.
i'm in mainland china and had the same false alarms - a single probe from one box flaps whenever the route hiccups. what helped me was requiring 2-3 failed checks in a row before alerting, and adding a second probe from a different network. do you know if your alerts cluster around evening hours?
On a small HK box with only 10 Mbps I'd lean toward systemd timers plus curl, since checks use almost no bandwidth or RAM and that kind of node is better suited to monitoring than heavy traffic. To tell DNS problems from real outages, I'd run the DNS lookup and the HTTP request as separate steps, so the failure reason is logged, and only alert after a few consecutive failures. Uptime Kuma is fine too, but I'd keep it to a single lightweight container managed by systemd.