64 lines
2.3 KiB
Markdown
64 lines
2.3 KiB
Markdown
|
+++
|
||
|
|
title = "Knowing your Backup has Run"
|
||
|
|
weight = 65
|
||
|
|
+++
|
||
|
|
Great, we have backups set up and running automatically, but how do we know
|
||
|
|
they're running successfully?
|
||
|
|
Well, Norg can interact with monitoring tools to let you know backups are running...
|
||
|
|
Or, probably more accuractely, when they fail.
|
||
|
|
|
||
|
|
Currently only [Uptime Kuma](https://uptime.kuma.pet) is supported, but it would be
|
||
|
|
possible to connect to many other types of monitoring service by creating a new `notifiers/{notifier_name}.nim` codefile and linking it all up.
|
||
|
|
|
||
|
|
## Supported Monitoring Tools
|
||
|
|
- [Uptime Kuma](#uptime-kuma)
|
||
|
|
- [Ntfy](#ntfy) - Planned, Not implemented yet.
|
||
|
|
- [Healthchecks.io](#healthchecks-io) - Planned, Not implemented yet.
|
||
|
|
|
||
|
|
### Uptime Kuma
|
||
|
|
Uptime Kuma is a self-hosted monitoring tool. It's generally used to call *out* to
|
||
|
|
a service or server every minute to check it is running. But, it does have the option
|
||
|
|
of a "Push" type of monitor, which waits for a service to make a `HTTP GET` request to it, and reports on the status of that request, or if that request is missed within a timeframe.
|
||
|
|
Some basic Uptime Kuma Settings for a backup job would be as follows:
|
||
|
|
```ini
|
||
|
|
# These are to be entered into Uptime Kuma and not into your Norg
|
||
|
|
# configuration.
|
||
|
|
|
||
|
|
# Push monitors wait for the client to contact Uptime Kuma instead of Uptime
|
||
|
|
# Kuma contacting the client. This is perfect for backup monitoring.
|
||
|
|
Monitor Type = Push
|
||
|
|
|
||
|
|
Heartbeat Interval = 90000 # = 25 hours = 1 day + 1 hour
|
||
|
|
|
||
|
|
# Wait 6 times the Heartbeat Retry (below) before logging a heartbeat missed.
|
||
|
|
Retries = 6
|
||
|
|
|
||
|
|
# Multiplied by Retries this gives a grace period within which the monitor
|
||
|
|
# goes into the "Pending" state.
|
||
|
|
Heartbeat Retry = 360 # = 10 minutes
|
||
|
|
|
||
|
|
# For each Heartbeat Interval if the backup fails repeatedly, a notification
|
||
|
|
# is sent each time.
|
||
|
|
Resend Notification every X times = 1
|
||
|
|
```
|
||
|
|
|
||
|
|
Your Norg configuration file should have an `uptimekuma` section as below
|
||
|
|
|
||
|
|
```toml
|
||
|
|
...
|
||
|
|
[uptimekuma]
|
||
|
|
base_url = "https://uptime.kuma.example/api/push/abcd1234"
|
||
|
|
states = ["Success", "Failure", "Running"]
|
||
|
|
```
|
||
|
|
|
||
|
|
This will make Norg request your Uptime Kuma service on `Running`, `Failure` and `Success` states. Uptime Kuma could then alert you about this change in state,
|
||
|
|
depending on how your Uptime Kuma is configured.
|
||
|
|
|
||
|
|
### Ntfy
|
||
|
|
Not implemented yet.
|
||
|
|
|
||
|
|
### Healthchecks.io
|
||
|
|
Not implemented yet.
|
||
|
|
|
||
|
|
|