---
client_metrique_paquets:
  - prometheus-node-exporter

# LE MATERIEL QUI N'EXISTE PAS DANS UNE VM (mesure du 2026-09-09 sur `obs-01`).
#
# `prometheus-node-exporter` RECOMMANDE `prometheus-node-exporter-collectors`, qui
# RECOMMANDE `ipmitool`, qui RECOMMANDE `openipmi`. Trois recommandations en cascade,
# chacune raisonnable sur du metal — et la derniere installe un script d'init qui tente
# de charger le pilote IPMI a CHAQUE demarrage. Dans une VM il n'y a pas de BMC :
#
#     openipmi[655]: Starting ipmi drivers ipmi failed!
#     systemd[1]: Failed to start openipmi.service
#
# CE QUI REND CE DEFAUT INSTRUCTIF : il datait du 2026-09-02, et personne ne l'avait vu.
# `systemctl --failed` rendait ZERO sur les quatorze machines — non parce qu'elles
# allaient bien, mais parce qu'aucune n'avait REDEMARRE depuis. Six jours et vingt heures
# pour `obs-01`. Un controle qui ne peut echouer qu'au demarrage ne mesure rien tant que
# rien ne demarre.
#
# Une unite en echec permanent n'est pas qu'inesthetique : elle use le seul signal qui
# devrait alerter. Le jour ou une VRAIE unite tombera, `systemctl --failed` rendra « 2 »
# au lieu de « 1 », et personne ne fera la difference.
#
# ON NE RETIRE QUE DANS UNE VM. Sur du metal, le collecteur IPMI est legitime — c'est
# meme la raison de la recommandation. Le role s'appuie donc sur ce qu'Ansible SAIT de la
# machine, pas sur une supposition.
client_metrique_paquets_sans_objet_en_vm:
  - openipmi
  - ipmitool

client_metrique_service: "prometheus-node-exporter"

# Adresse d'ecoute de node_exporter. Par defaut toutes les interfaces ; la
# segmentation reseau (VLAN / nftables) restreint l'acces au serveur Prometheus.
client_metrique_adresse_ecoute: ":9100"

# --- TLS (zero-confiance) : node_exporter sert en HTTPS avec le cert step_ca ---
# Requiert client_pki sur le noeud. Prometheus scrape alors en https + verifie.
client_metrique_tls_actif: false
client_metrique_tls_dir: "/etc/prometheus-node-exporter/tls"
client_metrique_web_config: "/etc/prometheus-node-exporter/web-config.yml"
client_metrique_tls_source_cert: "/etc/step/certs/{{ ansible_fqdn | default(ansible_hostname) }}.crt"
client_metrique_tls_source_cle: "/etc/step/certs/{{ ansible_fqdn | default(ansible_hostname) }}.key"

# --- Sonde de supervision (voir meta/supervision.yml) ---
# L'ENDROIT QUE PROMETHEUS INTERROGE, vu depuis la machine elle-meme. Le port se derive
# de l'adresse d'ecoute declaree : ecrire `9100` ici le ferait mentir le jour ou on la
# change, et une sonde qui vise le mauvais port rapporte une panne qui n'existe pas.
client_metrique_sonde_schema: "{{ 'https' if client_metrique_tls_actif | bool else 'http' }}"
client_metrique_sonde_port: "{{ client_metrique_adresse_ecoute | regex_replace('^.*:', '') }}"
client_metrique_sonde_url: >-
  {{ client_metrique_sonde_schema }}://127.0.0.1:{{ client_metrique_sonde_port }}/metrics

# LES COLLECTEURS QUI CHERCHENT DU MATERIEL ABSENT D'UNE VM (mesure du 2026-09-10 : les
# dix memes echouent sur les sept machines du site). Leur echec n'est pas une panne, et
# une sonde rouge partout est une sonde qu'on cesse de lire. Sur du METAL, vider cette
# liste : `mdadm` ou `bonding` qui tombe y voudrait dire quelque chose.
client_metrique_collecteurs_sans_objet:
  - bonding
  - fibrechannel
  - infiniband
  - ipvs
  - mdadm
  - nfs
  - nfsd
  - pressure
  - tapestats
  - zfs