2026-06-24 20:17:46 -04:00
|
|
|
---
|
|
|
|
|
- name: Installer Prometheus
|
|
|
|
|
ansible.builtin.apt:
|
|
|
|
|
name: "{{ serveur_prometheus_paquets }}"
|
|
|
|
|
state: present
|
|
|
|
|
update_cache: true
|
|
|
|
|
cache_valid_time: 3600
|
|
|
|
|
|
2026-10-07 21:57:04 -04:00
|
|
|
# --- LA BASE D'UNE INCARNATION PRECEDENTE (2026-10-07) --------------------------------
|
|
|
|
|
#
|
|
|
|
|
# Les metriques repartaient de zero a chaque reconstruction. client_backup en garde une
|
|
|
|
|
# copie a froid (jeu `prometheus`) ; on la remet ICI, juste apres l'installation : le paquet
|
|
|
|
|
# demarre Prometheus aussitot, mais sa base n'a encore aucun bloc (le premier se ferme au
|
|
|
|
|
# bout de deux heures). Service arrete pendant la remise ; la tache « Activer et demarrer »
|
|
|
|
|
# plus bas le relance.
|
|
|
|
|
- name: La base de Prometheus a-t-elle deja des blocs ?
|
|
|
|
|
ansible.builtin.find:
|
|
|
|
|
paths: "{{ serveur_prometheus_donnees }}"
|
|
|
|
|
file_type: directory
|
|
|
|
|
patterns: "01*"
|
|
|
|
|
register: serveur_prometheus_blocs
|
|
|
|
|
|
|
|
|
|
- name: Restauration — la base d'une incarnation precedente ?
|
|
|
|
|
ansible.builtin.include_role:
|
|
|
|
|
name: client_backup
|
|
|
|
|
tasks_from: restaurer.yml
|
|
|
|
|
vars:
|
|
|
|
|
client_backup_restaurer_jeu: serveur_prometheus
|
|
|
|
|
client_backup_restaurer_vierge: "{{ serveur_prometheus_blocs.matched == 0 }}"
|
|
|
|
|
|
|
|
|
|
- name: Restauration — remettre la base, service arrete
|
|
|
|
|
when: client_backup_restauration.etat == 'a_restaurer'
|
|
|
|
|
block:
|
|
|
|
|
- name: Restauration — arreter Prometheus
|
|
|
|
|
ansible.builtin.systemd:
|
|
|
|
|
name: "{{ serveur_prometheus_service }}"
|
|
|
|
|
state: stopped
|
|
|
|
|
|
|
|
|
|
- name: Restauration — remettre la copie a froid a sa place
|
|
|
|
|
changed_when: true
|
|
|
|
|
ansible.builtin.command:
|
|
|
|
|
argv:
|
|
|
|
|
- /usr/local/sbin/setops-restaurer
|
|
|
|
|
- fichiers
|
|
|
|
|
- --instantane
|
|
|
|
|
- "{{ client_backup_restauration.instantane }}"
|
|
|
|
|
- --depuis
|
|
|
|
|
- "{{ client_backup_restauration.chemins[0] }}/metrics2"
|
|
|
|
|
- --remplacer
|
|
|
|
|
- --proprietaire
|
|
|
|
|
- prometheus:prometheus
|
|
|
|
|
- "{{ serveur_prometheus_donnees }}"
|
|
|
|
|
|
|
|
|
|
- name: Restauration — acter la base remise
|
|
|
|
|
ansible.builtin.include_role:
|
|
|
|
|
name: client_backup
|
|
|
|
|
tasks_from: acter.yml
|
|
|
|
|
vars:
|
|
|
|
|
client_backup_acter_etat: restaure
|
|
|
|
|
|
2026-09-14 11:35:14 -04:00
|
|
|
# --- LES CIBLES QUE LES ROLES DECLARENT (2026-09-14) ----------------------------------
|
|
|
|
|
#
|
|
|
|
|
# `serveur_prometheus_cibles_supplementaires` existait depuis longtemps — une liste libre,
|
|
|
|
|
# documentee, et que PERSONNE ne remplissait. Resultat : Prometheus ne scrutait que les
|
|
|
|
|
# `node_exporter`. Aucune metrique de SERVICE n'etait collectee — ni PostgreSQL, ni
|
|
|
|
|
# l'annuaire, ni les boites, ni le cache. Seulement du systeme.
|
|
|
|
|
#
|
|
|
|
|
# CE QUI LES REMPLIT DESORMAIS : `roles/<role>/meta/metriques.yml`, croise avec les hotes
|
|
|
|
|
# qui portent ce groupe. Exactement le patron de `client_sante` pour les sondes, et de
|
|
|
|
|
# `resoudre_flux` pour les pare-feu : LE ROLE DECLARE, LE MOTEUR DERIVE.
|
|
|
|
|
#
|
|
|
|
|
# UNE VALEUR DONNEE AU PLAN GAGNE : `| default` laisse un ecosysteme ajouter une cible qui
|
|
|
|
|
# ne vient d'aucun role — un equipement, un service tiers. La derivation complete, elle ne
|
|
|
|
|
# remplace pas.
|
|
|
|
|
- name: Relever les metriques que les roles declarent
|
|
|
|
|
ansible.builtin.find:
|
|
|
|
|
paths: "{{ role_path }}/.."
|
|
|
|
|
patterns: metriques.yml
|
|
|
|
|
recurse: true
|
|
|
|
|
depth: 3
|
|
|
|
|
delegate_to: localhost
|
|
|
|
|
become: false
|
|
|
|
|
run_once: true
|
|
|
|
|
check_mode: false
|
|
|
|
|
register: serveur_prometheus_metas
|
|
|
|
|
|
|
|
|
|
- name: Lire chaque declaration de metriques
|
|
|
|
|
ansible.builtin.slurp:
|
|
|
|
|
src: "{{ item.path }}"
|
|
|
|
|
delegate_to: localhost
|
|
|
|
|
become: false
|
|
|
|
|
run_once: true
|
|
|
|
|
check_mode: false
|
|
|
|
|
loop: "{{ serveur_prometheus_metas.files }}"
|
|
|
|
|
loop_control:
|
|
|
|
|
label: "{{ item.path | dirname | dirname | basename }}"
|
|
|
|
|
register: serveur_prometheus_declarations
|
|
|
|
|
|
2026-06-24 20:17:46 -04:00
|
|
|
- name: Deployer la configuration Prometheus
|
|
|
|
|
ansible.builtin.template:
|
|
|
|
|
src: prometheus.yml.j2
|
|
|
|
|
dest: "{{ serveur_prometheus_config }}"
|
|
|
|
|
owner: root
|
|
|
|
|
group: root
|
|
|
|
|
mode: "0644"
|
|
|
|
|
notify: Valider et recharger prometheus
|
|
|
|
|
|
|
|
|
|
- name: Definir les arguments du service (retention)
|
|
|
|
|
ansible.builtin.template:
|
|
|
|
|
src: default-prometheus.j2
|
|
|
|
|
dest: /etc/default/prometheus
|
|
|
|
|
owner: root
|
|
|
|
|
group: root
|
|
|
|
|
mode: "0644"
|
|
|
|
|
notify: Valider et recharger prometheus
|
|
|
|
|
|
|
|
|
|
- name: Activer et demarrer Prometheus
|
2026-07-01 21:01:53 -04:00
|
|
|
when: not ansible_check_mode
|
2026-06-24 20:17:46 -04:00
|
|
|
ansible.builtin.systemd:
|
|
|
|
|
name: "{{ serveur_prometheus_service }}"
|
|
|
|
|
enabled: true
|
|
|
|
|
state: started
|
sondes : les six premieres, et le patron qui les rend eprouvables
Ajout de meta/supervision.yml a six roles, chacun deposant sa propre sonde
selon le contrat des greffons Nagios.
DEUX PRINCIPES POSES AU DOCUMENT DE CONCEPTION, parce que la premiere
sonde les a imposes :
1. UNE SONDE DOIT POUVOIR ETRE MISE EN DEFAUT PAR PARAMETRE. Cible et
seuils sont des variables du role : on la prouve rouge avec un port ferme
ou un seuil impossible, sur une machine reelle, sans rien casser, et
aussi souvent qu on veut. Une sonde qu on ne peut prouver qu en cassant un
service ne sera prouvee qu une fois.
2. LA SONDE VIT LA OU VIT LA VERITE. « Ce noeud est-il collecte ? » est
une sonde de serveur_prometheus, pas de client_metrique : une seule y voit
les N noeuds, et surtout elle voit le cas SILENCIEUX — celui qui a cesse d
etre collecte ne peut pas s en plaindre.
LES SIX : cache-apt (artefacts, repond + place), resolution (resolveur,
zone interne ET Internet — deux chemins distincts), forge (forgejo, son
propre /api/healthz), collecte (prometheus, 15/15 cibles), tableaux
(grafana, base ok), ingestion (loki, PRET a ingerer, pas seulement en
ecoute).
TROIS FOIS J AI ECRIT LA SONDE AVANT DE MESURER, ET TROIS FOIS ELLE A EU
TORT. La forge : port 443 et chemin des depots INVENTES — elle ecoute en
3000 derriere l edge et n a legitimement aucun depot. Loki : j ai conclu
« panne persistante » sur deux lectures prises a quelques secondes d
intervalle, juste apres un redemarrage ; l anneau etait ACTIVE et la
reponse est passee a ready moins d une minute plus tard. Le delai de
stabilisation est desormais un AVERTISSEMENT nomme, pas une panne.
On demande au service ce qu il pense de lui-meme quand il sait le dire
(healthz, /ready, /api/health) plutot que d inventer un critere de l
exterieur.
make prouver : CONFORME.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-10 02:48:55 -04:00
|
|
|
|
|
|
|
|
# --- Sonde de supervision (docs/supervision-conception.md) --------------------------
|
|
|
|
|
# Le role qui possede la verite depose sa propre sonde ; le porteur (`client_sante`) la
|
|
|
|
|
# fait tourner et pousse le verdict, sans savoir ce qu'elle mesure.
|
|
|
|
|
- name: Assurer le repertoire des sondes de supervision
|
|
|
|
|
ansible.builtin.file:
|
|
|
|
|
path: /usr/local/lib/setops/sondes
|
|
|
|
|
state: directory
|
|
|
|
|
owner: root
|
|
|
|
|
group: root
|
|
|
|
|
mode: "0755"
|
|
|
|
|
|
|
|
|
|
- name: Deposer la sonde « collecte »
|
|
|
|
|
ansible.builtin.template:
|
|
|
|
|
src: sonde-collecte.sh.j2
|
|
|
|
|
dest: /usr/local/lib/setops/sondes/collecte.sh
|
|
|
|
|
owner: root
|
|
|
|
|
group: root
|
|
|
|
|
mode: "0750"
|