Daniel Allaire
f1a7e43645
Icinga ne surveillait rien : aucun objet Host ni Service de Set-OPS, seulement
la config Debian d'origine sur localhost.
Superviser setops-sauvegarde.service aurait reproduit le defaut du jour meme :
l'unite etait VERTE sur onze noeuds pendant qu'elle n'emportait rien. Le noeud
sait qu'il a LANCE sa sauvegarde, pas qu'elle est ARRIVEE. backup-01 evalue donc
ses depots et pousse un resultat passif par noeud vers l'API Icinga.
Trois criteres, parce qu'un seul suffit a mentir : l'instantane existe, il est
recent (26 h / 50 h), il contient au moins un fichier.
Le sens du flux est delibere : le depot parle a la supervision, jamais l'inverse
— compromettre mon-01 ne donne aucun acces aux sauvegardes.
Le ttl de 6 h fait la fraicheur : si le rapporteur se tait, Icinga perime les
services tout seul. C'est le silence qui a laisse le defaut vivre un mois.
Deux erreurs corrigees par la mesure :
- --data-urlencode refuse en Bad Request (l'API veut du JSON) ; le flux, le TLS
et l'auth marchaient, seule la charge etait perdue.
- le seuil « vide » en octets signalait a tort idm-01 (2363 o) : un export LDIF
d'un annuaire a un compte pese cela. « Vide » se mesure en FICHIERS. Et le
verdict est un AVERTISSEMENT : la machine ne distingue pas « les donnees ont
disparu » de « il n'y en a pas encore ».
Reserve assumee : curl -k — l'API presente le cert de sa propre AC, pas step-ca.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
38 lines
2.2 KiB
YAML
38 lines
2.2 KiB
YAML
---
|
|
# Cible des sauvegardes : héberge les dépôts restic (un sous-dossier par nœud source).
|
|
# Les clients y accèdent en SFTP/SSH avec la clé de sauvegarde. Chiffrement côté client (restic).
|
|
serveur_backup_utilisateur: "restic"
|
|
serveur_backup_racine: "/srv/restic"
|
|
# Clé PUBLIQUE de sauvegarde autorisée (la privée est dans la voûte, côté client_backup).
|
|
serveur_backup_pubkey: ""
|
|
|
|
# --- Vérification des dépôts et rapport passif vers Icinga ---
|
|
# Le dépôt est le SEUL à voir ce qui est réellement arrivé. Un nœud sait qu'il a lancé sa
|
|
# sauvegarde ; il ne sait pas qu'elle a abouti. D'où la vérification ici, et pas là-bas.
|
|
# Toutes les 4 h, pas une fois par jour : la vérification doit renouveler le `ttl` bien
|
|
# avant qu'il n'expire, sinon un simple retard du timer se lirait comme une sauvegarde
|
|
# perdue. Elle est peu coûteuse (lecture des métadonnées restic).
|
|
serveur_backup_verification_horaire: "*-*-* 00/4:00:00"
|
|
|
|
# Seuils d'âge. Le critère « n'emporte rien » ne se règle pas ici : il se mesure en
|
|
# NOMBRE DE FICHIERS dans l'instantané (zéro = rien emporté), ce qui est exact, alors
|
|
# qu'un seuil en octets signalait à tort un export LDIF de 2,3 Ko.
|
|
serveur_backup_age_warn_h: 26
|
|
serveur_backup_age_crit_h: 50
|
|
|
|
# `ttl` du résultat passif : au-delà, Icinga périme le service de lui-même — c'est ce qui
|
|
# fait que le SILENCE alerte. 6 h pour une vérification toutes les 4 h : une exécution peut
|
|
# être manquée sans fausse alerte, deux ne le peuvent pas.
|
|
serveur_backup_ttl_icinga: 21600
|
|
|
|
# Compte d'API Icinga (portée : uniquement process-check-result sur « sauvegarde: * »).
|
|
serveur_backup_icinga_utilisateur: "setops-depot"
|
|
serveur_backup_icinga_motdepasse: "{{ vault_icinga_api_depot | default('') }}"
|
|
serveur_backup_icinga_hote: "{{ (groups['serveur_icinga'] | default([]) | first) | default('') }}"
|
|
|
|
# Nœuds dont un instantané est ATTENDU : ceux qui portent client_backup ET détiennent
|
|
# réellement de l'état. Même règle que `client_backup_jobs`, même source que P36.
|
|
serveur_backup_noeuds_attendus: >-
|
|
{{ (client_backup_groupes_etat | default([]) | map('extract', groups)
|
|
| select('defined') | flatten | unique | list)
|
|
| intersect(groups['client_backup'] | default([])) }}
|