YunoHost-Apps/borg_ynh

Add healthchecks or similar (feature request)

shukon opened this issue · 3 comments

Sending mails on failure is great! Even better would be the possibility to ping healthchecks.io or some other external monitoring service.
Those monitoring services operate as a dead man's switch, raising alerts if not pinged on a specified schedule. Backups often fail silently, and borg could too, e.g. if the backup creation is not triggered at all.
Borgmatic does this for example.
It's an additional parameter in the config of this app and an additional curl call on successful backups, but works even if the borg-service itself fails for any reason.

EDIT: this would also add a fallback to address issues #108 and #109 .

I agree. Also note that the healthchecks application is FLOSS, and there are other providers, like https://wtf.roflcopter.fr/apps/#HealthChecks

Healthcheck could even be packaged by Yunohost, if anyone is willing to do that.

I took a look at the issue and started to work on it.

I think there can be difficulties in order to be fully functional:

  1. There should be a ping per application being backed-up
  2. Healthchecks.io limits its usage for free, we may not suggest to use their services
  3. There is no Healthchecks package for Yunohost yet.
  4. There is only one Healthchecks instance offered by a CHATONS currently, I am not sure it's a good idea to suggest its usage while they are alone to do so: https://www.chatons.org/en/search/by-service?field_software_target_id=306

From my prospective, we should implement first a Yunohost package to self-host healtchecks. Then we should consider enhancing this project to include the support for pinging to healthchecks service.
Also worth noting that there exist projects with which we can ping URL containing the project name and a slug. An API exists for managing checks URL: https://cron.roflcopter.fr/docs/api/

  1. Yeah, that would be cool.
  2. Hm. I still think it's pretty good, I mean it's free as in speech and some-free-beers. But ok.
  3. Fair enough. What about a uptime kuma push monitor instead? Does the same thing and is hostable via Yunohost.

I'd argue that instead of limiting support to one monitor, we should just have a field for an URL to ping on a successful backup. Whether it be uptime-kuma, healthchecks.io or some evil-private-institution.tm should be up to the user.
And since we cannot individual backup cycles for individual apps, we might as well just have one ping for a general successful borg backup run. Keep it simple, so it works?