First of all let me acknowledge that M/Monit is great at what it does. However, as said previously, for small home deployments, having yet-another-service to deploy, configure and monitor just adds more "work".
At the moment deploying individual Monit instances, instructing them to send alerts over email, and bookmarking their dashboard links is more than enough to monitor such a small home deployment. This almost covers 99% of what one would desire. The final 1%, as mention initially, is just a friendlier UI on a mobile device, which if nothing works, could just be the bookmarked dashboard links. Now, given there is no mobile application, I've received a couple of suggestions and I would like to comment on them. On Mon, Aug 22, 2022 at 11:44 AM Roland Giesler <roland@greentree.systems> wrote: > You could set up a jabber server in m/monit to send push notifications to > your phone? I was not aware that M/Monit is able to send Jabber messages. However, using them implies now one also needs a Jabber server. One can either use a public server (as Roland mentioned), or install one (which adds yet-another-service to deploy, configure and monitor). On Tue, Aug 23, 2022 at 7:00 PM <lutz.ma...@freenet.de> wrote: > are you aware of the suggestions to use Pushover or Slack, > see https://mmonit.com/wiki/Notification/Notification I was also not aware that M/Monit is able to integrate with either Pushover or Slack. Pushover is nice, and I was seriously thinking about buying a license for other uses. Slack implies one already has a Slack workspace. (And I'm not very happy with Slack's resource usage at least on the desktop...) However, what all of these solutions have in common is that they complicate the "tech stack" even more. All of a sudden one needs (besides the individual Monit instances) a M/Monit instance plus an external service. Moreover, there is the reliability issue: no notification (either Email, Slack, Pushover, Jabber, IRC, whatever) doesn't mean there is no problem... Maybe the Monit instance itself is down, thus no monitoring or alerts to begin with; maybe the M/Monit instance is down thus no notification is sent; maybe the third-party notification system has a problem, thus no notification is relayed; maybe my mobile device has no connectivity, thus no notification is received... (And in this regard, I've had serious issues with Slack notification delivery...) However with an application that does polling (say once a few minutes or tens of minutes) the "tech stack" is as simple as it gets: Monit instances, the mobile application; nothing in between except the network. Also the reliability is somewhat improving: if a Monit instance "goes down" it either means my mobile device lost connectivity (which could be solved by a simple "ping" to a well-known-public server like `https://1.1.1.1/`), either the server is actually down. > It's not a good idea to have an app that polls services on a mobile, since it > will drain the battery in no time. Indeed having an application doing constant polling would kill a mobile device battery. However the user could have the option of decreasing the polling time (say once half an hour), or even disabling it (thus using the application as a simple browser+bookmark replacement.) Thus, although the notification-based alternative would work, I don't think it solves my initial use-case for a mobile application. Thanks, Ciprian.
