Compare commits

...
Author SHA1 Message Date
issue-fix-bot 325baf7047 fix: [alert] VeleroBackupStale (velero) (#780)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
2026-09-03 20:47:37 +00:00
security-bot a667920bb0 chore(image-automation): bump ghcr.io/cloudnative-pg/plugin-barman-cloud:v0.15.0
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-09-03 19:22:34 +00:00
security-bot 53fe8efa02 chore(image-automation): bump ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar:v0.15.0
Updates managed by image-automation-controller.
2026-09-03 19:21:48 +00:00
2 changed files with 25 additions and 5 deletions
@@ -58,10 +58,30 @@ spec:
# VeleroBackupFailed alert fires on the first failure regardless — so
# nothing is hidden, only the escalation to critical is deferred
# until a second cycle confirms it.
#
# The `and on(schedule) velero_backup_last_status` gate exists because
# velero_backup_last_successful_timestamp is an in-process gauge that
# velero does NOT retract when a Schedule is deleted: the series just
# stops being updated, ages past 60h and pages critical forever, for a
# schedule that no longer exists. That is what decommissioning
# netbird-backup-daily did on 2026-09-01.
#
# velero_backup_last_status is the same shape but IS retracted on
# Schedule deletion, so it works as a liveness set for "this schedule
# still exists". It hides nothing: velero repopulates it for every
# existing Schedule on its first scrape after a restart (verified
# across the three pods of the 2026-08-27 rollout), and it is written
# on failed runs too (0) as well as successful ones (1) — so a
# schedule that exists and is failing, or that exists and has stopped
# firing, still carries the series and still alerts.
expr: |
time() - velero_backup_last_successful_timestamp{schedule!=""} > 60 * 3600
and
velero_backup_last_successful_timestamp{schedule!=""} > 0
(
time() - velero_backup_last_successful_timestamp{schedule!=""} > 60 * 3600
and
velero_backup_last_successful_timestamp{schedule!=""} > 0
)
and on(schedule)
velero_backup_last_status
for: 10m
labels:
severity: critical
@@ -937,7 +937,7 @@ subjects:
# with no marker. Re-apply this block, or the skew silently returns.
apiVersion: v1
stringData:
SIDECAR_IMAGE: ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar:v0.14.0 # {"$imagepolicy": "flux-system:cnpg-barman-plugin-sidecar"}
SIDECAR_IMAGE: ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar:v0.15.0 # {"$imagepolicy": "flux-system:cnpg-barman-plugin-sidecar"}
kind: Secret
metadata:
name: plugin-barman-cloud-kg5c2795f7
@@ -998,7 +998,7 @@ spec:
secretKeyRef:
key: SIDECAR_IMAGE
name: plugin-barman-cloud-kg5c2795f7
image: ghcr.io/cloudnative-pg/plugin-barman-cloud:v0.14.0 # {"$imagepolicy": "flux-system:cnpg-barman-plugin"}
image: ghcr.io/cloudnative-pg/plugin-barman-cloud:v0.15.0 # {"$imagepolicy": "flux-system:cnpg-barman-plugin"}
name: barman-cloud
ports:
- containerPort: 9090