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.