Observability: updates, filesystem errors and backups #178
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
question
urgent
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
qo.is/infrastructure#178
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
We are currently missing o11y and alerts for some stuff:
btrfsmetrics, and have alerts, so we know that our filesystems are fine.Updates
/etc/lsb-releaseDISTRIB_RELEASEis <1y e.g. once a week?Backups
qois.backupmodule.borg listhas backup with recent dateborg compact && borg checkmonthly?)Observability for updates and backupsto Observability for updates, filesystem errors and backupsObservability for updates, filesystem errors and backupsto Observability: updates, filesystem errors and backupsKey topics:
https://github.com/influxdata/telegraf/blob/master/plugins/inputs/systemd_units/README.md sieht nützlich aus.
OK, die richtige Metrik(en) hab' ich glaub' gefunden:
systemd_units_sub_codemitname~=.*borg.*Aber wie sind die Infos dort zu interpretieren? Offenbar sind alle betreffenden Units
dead.Ah,
systemd_units_status_errnoergibt wohl mehr Sinn, da der "Value" dort wohl der Exit-Code ist.Hab' damit nun mal einen Alert erstellt: https://monitoring.qo.is/alerting/grafana/cfwnmnkzh83cwc/view
@fabianhauser, kannst du mal draufgucken, ob der so sinnvoll parametrisiert ist?
(Dieser Alert meldet nur, wenn ein non-zero Exit-Code von einem Backup-Prozess beobachtet wird. Ob die Backup-Services in den letzten 30 Tagen gelaufen sind, prüft er nicht.)
Um das zu lösen:
Zusätzlicher Alert, der feuert, wenn
borgbackup-job-data-local.servicein den letzten 30 Tagen nicht gelaufen ist (oder der entsprechende Exit-Code nicht eingesammelt wurde): https://monitoring.qo.is/alerting/grafana/afwnrnhti5ukgf/viewKannst du dir auch den ansehen, @fabianhauser? Falls das so passt, können wir das für die anderen
borgbackup-.*-Services duplizieren:(Diese Checkliste wurde anhand der von dieser Query zurückgegebenen Namen erstellt. To Do:
qois.backupgucken, ob das alle sind)
@das-g nice! Ich habe die alerts noch etwas angepasst - jetzt feuern sie in einem 49h zeitraum, für alle
borgbackup-job.*services :)Evtl. kannst du den alert in code umsetzen, und dann auch noch einen für den postgres backup job hinzufügen?
Export nach den in #178 (comment) genannten Anpassungen von Fabian:
Danke @das-g ! Magst du einen PR erstellen um diese in code aufzunehmen? Siehe srvos - glaub wir können den Alert auch auf die Metrik und den Text reduzieren.
github.com/nix-community/srvos@a00436b148/nixos/roles/prometheus/default-alerts.nix (L54-L69)sieht ja auch interessant aus.@das-g wrote in #178 (comment):
Ist
sum_over_timehier nicht kontraproduktiv, @fabianhauser? Wenn einmal Exit-Code-1und einmal Exit-Code1auftritt, würde sich das in einer Summe ja "ausgleichen".Hmm, ja vielleicht. Evtl. besser
countin dem fall...Braucht's überhaupt eine Aggregierung? Ich vermute ohne eine würden wir über jeden fehlgeschlagenen Backup-Job alertet, was ja auch OK (und evtl. sogar gewünscht) wäre, oder?
scheint eine gültige Query zu sein.