borgmatic-collective/borgmatic
borgmatic-collective
/
borgmatic
15
57
Fork 40
Code Issues 53 Pull Requests 1 Actions Packages Releases 121 Activity

Allow configuring healthchecks.io ping behavior #525

New Issue
Closed
opened 2022-05-01 12:04:10 +00:00 by tommy · 3 comments
tommy commented 2022-05-01 12:04:10 +00:00
Copy Link

I would like to be able to configure the pings to healthchecks.io in a more fine grained manner, specifically so that borgmatic doesn't send a started or fail ping, and instead only sends the success ping if everything finished successfully.

What is the use case for this? Well I want to give my backup healthchecks some leniency, as I'm running a distributed cluster where the backups are run nigthly, and some nights a client may or may not be up and running (which is not critical by any means). In this situation I configure my healthchecks to wait 3 days before switching to the DOWN state, since the backup will likely succeed within a few days when the client is back up again.

This is currently not possible to do since borgmatic sends the fail ping as soon as a backup fails, which means that healthchecks.io pushes failure notifications immediately even though the situation is not critical.

Essentially I would like to have some kind of simple configuration option to control this behavor, perhaps somethings along these lines:

    healthchecks: https://ping-url
    	ping_start: false
        ping_fail: false
I would like to be able to configure the pings to healthchecks.io in a more fine grained manner, specifically so that borgmatic doesn't send a `started` or `fail` ping, and instead only sends the `success` ping if everything finished successfully. What is the use case for this? Well I want to give my backup healthchecks some leniency, as I'm running a distributed cluster where the backups are run nigthly, and some nights a client may or may not be up and running (which is not critical by any means). In this situation I configure my healthchecks to wait 3 days before switching to the `DOWN` state, since the backup will likely succeed within a few days when the client is back up again. This is currently not possible to do since borgmatic sends the `fail` ping as soon as a backup fails, which means that healthchecks.io pushes failure notifications immediately even though the situation is not critical. Essentially I would like to have some kind of simple configuration option to control this behavor, perhaps somethings along these lines: ``` healthchecks: https://ping-url ping_start: false ping_fail: false ```
witten commented 2022-05-22 16:20:57 +00:00
Owner
Copy Link

That makes sense to me! Thanks for filing the ticket and describing your use case. I think this change would require a configuration schema change to work, as the current heathchecks key just has a single scalar value: the URL. But it does seem like we're going to need multiple configuration options at some point, so it might as well be for this feature.

That makes sense to me! Thanks for filing the ticket and describing your use case. I think this change would require a configuration schema change to work, as the current `heathchecks` key just has a single scalar value: the URL. But it does seem like we're going to need multiple configuration options at some point, so it might as well be for this feature.
witten commented 2022-05-24 21:12:12 +00:00
Owner
Copy Link

This is implemented in master now! I ended up going with a list option instead of a set of flags though. Here's how it would look to configure borgmatic to only ping for the success state:

hooks:
    healthchecks:
        ping_url: https://...
        states:
            - finish

This will be part of the next release! Thanks again for the idea.

This is implemented in master now! I ended up going with a list option instead of a set of flags though. Here's how it would look to configure borgmatic to only ping for the success state: ``` hooks: healthchecks: ping_url: https://... states: - finish ``` This will be part of the next release! Thanks again for the idea.
witten commented 2022-05-24 23:26:11 +00:00
Owner
Copy Link

Released in borgmatic 1.6.1!

Released in borgmatic 1.6.1!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
spot-check
1.8.10
1.8.9
1.8.8
1.8.7
1.8.6
1.8.5
1.8.4
1.8.3
1.8.2
1.8.1
1.8.0
1.7.15
1.7.14
1.7.13
1.7.12
1.7.11
1.7.10
1.7.9
1.7.8
1.7.7
1.7.6
1.7.5
1.7.4
1.7.3
1.7.2
1.7.1
1.7.0
1.6.6
1.6.5
1.6.4
1.6.3
1.6.2
1.6.1
1.6.0
1.5.24
1.5.23
1.5.22
1.5.21
1.5.20
1.5.19
1.5.18
1.5.17
1.5.16
1.5.15
1.5.14
1.5.13
1.5.12
1.5.11
1.5.10
1.5.9
1.5.8
1.5.7
1.5.7.dev0
1.5.6
1.5.5
1.5.4
1.5.3
1.5.2
1.5.1
1.5.0
1.4.22
1.4.21
1.4.20
1.4.19
1.4.18
1.4.17
1.4.16
1.4.15
1.4.14
1.4.13
1.4.12
1.4.11
1.4.10
1.4.9
1.4.8
1.4.7
1.4.6
1.4.5
1.4.4
1.4.3
1.4.2
1.4.1
1.4.0
1.3.26
1.3.25
1.3.24
1.3.23
1.3.22
1.3.21
1.3.20
1.3.19
1.3.18
1.3.17
1.3.16
1.3.15
1.3.14
1.3.13
1.3.12
1.3.11
1.3.10
1.3.9
1.3.8
1.3.7
1.3.6
1.3.5
1.3.4
1.3.3
1.3.2
1.3.1
1.3.0
1.2.18
1.2.17
1.2.16
1.2.15
1.2.14
1.2.13
1.2.12
1.2.11
1.2.10
1.2.9
1.2.8
1.2.7
1.2.6
1.2.5
1.2.4
1.2.3
1.2.2
1.2.1
1.2.0
1.1.15
1.1.14
1.1.13
1.1.12
1.1.11
1.1.10
1.1.9
1.1.7
1.1.6
1.1.5
1.1.4
1.1.3
1.1.2
1.1.1
1.1.0
1.0.3
1.0.2
1.0.1
1.0.0
0.1.8
0.1.7
0.1.6
0.1.5
0.1.4
0.1.3
0.1.2
0.1.1
0.1.0
0.0.7
0.0.6
0.0.5
0.0.4
0.0.3
0.0.2
Labels
Clear labels   
bug

   
data loss

   
design finalized

   
good first issue

   
new feature area

   
question / support

   
security

   
waiting for response
No Label
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#525
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?