I mean, you've sort of reinvented Munin. It certainly fits the bill here, and would stop the need to do a bunch of extra work.
Monitoring My Homelab, Simply
41–50 of 70 posts
Re: Monitoring My Homelab, Simply
#42I’ve been facing a similar search for an ultra-simple but ultra-extensible monitoring solution for my homelab. I’ve had the idea to write a Python program where the main script is just responsible for scheduling and executing the checks, logging, and alerting based on set thresholds. All monitoring would be handled via plugins, which would be extremely easy to write. It would ship with a few core plugins (ping, http,…
You've described this: https://munin-monitoring.org/
Re: Monitoring My Homelab, Simply
#43This is interesting. I appreciate the simplicity and DIY aspects. Is it available as a repo somewhere?
I recently had to troubleshoot a hanging issue on one of my servers, so I needed something that could ship logs. The modern observability stack is a deep pit of complexity, but OpenTelemetry is a standard, and there are reasonably simple tools in the ecosystem. I knew I didn't want a behemoth like Grafana, and I was aware of SigNoz, though it seems janky. Then I stumbled upon OpenObserve, and it looked promising. Setting it up on a spare mini PC and opentelemetry-collector on the server was pretty straightforward. Getting the collector configuration right took some trial and error, though.
I have to say, I'm quite satisfied with this setup. I ended up installing the collector on other machines, so it's almost like a proper observability system now :)
The graphs are nice. I can expand it to monitor anything else I would need. I haven't setup alerts yet, but it's possible.
I'm not really concerned about monitoring the monitor. It's not a big deal for my use case if it goes down. Metrics and logs will be submitted when it's back up, since they're cached on the servers. Besides, I'm only running OpenObserve on the machine, so there aren't many moving parts.
Anyway, all this is to say that sometimes there's more to be gained from using off-the-shelf tooling instead of rolling your own, even if it involves more complexity. Server monitoring is an old tradition, and there are many robust solutions out there. OTLP isn't that bad, especially at smaller scales, and it opens the door to a large ecosystem. It would be foolish not to take advantage of that.
Re: Monitoring My Homelab, Simply
#44Grafana Cloud have quite a nice free tier. If you use Alloy, you don't need any persistence locally. Everything just gets shipped off.
Similar to the author, I want to run a minimalist monitoring setup and currently just use Glances. But Grafana Cloud might be my first choice if I need to expand the setup.
Re: Monitoring My Homelab, Simply
#45Uptime Kuma ( https://github.com/louislam/uptime-kuma ). With email notifications. So much simpler, and free.
Love this - tried it. The problem as I see it is that these still require hosting - ideally (again, as I see it) self-hosting a script that monitors internal/homelab things also requires its own monitoring. Short of paying for a service (which somewhat goes against the grain of trying to host all your own stuff), the closest I can come up with is relying on a service outside your network that has access to your netwo…
UptimeFlare looks promising—runs in a Cloudflare Worker: https://github.com/lyc8503/UptimeFlare
If anybody wants to be a clever clogs, combining both this and Uptime Kuma would be genius. What I want is redundancy. E.g., if something can't be reached, check on the other, likewise if one service takes a crap, continue monitoring via the other and sync up the histories once they're both back online.
This "local or cloud" false dichotomy makes no sense to me—a hybrid approach would be brilliant.
If anyone manages this, email me: me@hammyhavoc.com. I would love to hear about it.
Re: Monitoring My Homelab, Simply
#46I personally found uptime kuma to be easiest because it has a python api package to bulk load stuff into it. Much easier to edit a list in vscode than click around a bunch in an app
My gripe is a lack of support for multiple users. E.g., a family member gets sick of receiving a notification and can't just toggle it themselves.
Re: Monitoring My Homelab, Simply
#47Honest question, what the hell is everyone monitoring in a home lab that isn't already monitored? I have an enterprise grade NAS, but if there's any kind of disk or RAID issue it beeps the shit out of me; I call that enough for home use. I have a Unifi router, if there is a connection issue it fails over to LTE and I get a notification on my phone. I have a UPS, if there is a power failure, my lights shut off, my NAS…
People care about failures with containers and scripts not uncommonly.
E.g., you run a service container that also needs Postgres, Redis, a reverse proxy, a Cloudflare Tunnel and perhaps sidecar worker containers too, like Authentik. People want to know where the problem is immediately without fucking around with 80+ containers.
Re: Monitoring My Homelab, Simply
#48Until the pc becomes unresponsive and needs a hard reset. In that case you are out of luck unless you have enterprise grade servers, or if you have some sort of smart plug that you can remotely power cycle
Re: Monitoring My Homelab, Simply
#49https://mmonit.com is what I use for stuff like this.
Re: Monitoring My Homelab, Simply
#50I use Prometheus + Prometheus Alertmanager + Any Free Tier paging system (currently OpsGenie, might move to AlertOps). Having a feature-rich TSDB backing alerting minimizes time adding alerts, and the UX of being able to write a potential alert expression and seeing when in the past it would fire is amazing. Just two processes to run, either bare or containerized, and you can throw in a Grafana instance if you want b…
Prometheus fronted by grafana is great and I use it a lot for work, but I can understand why they don't want to deal with it for just monitoring their home network - and writing your own monitoring software can certainly help you appreciate what you get from Prometheus.