---
# Metriques derivees du role. Le pendant de `meta/supervision.yml`, et son contraire.
#
# POURQUOI UN SECOND FICHIER, ET PAS UNE SECTION DU PREMIER.
#
# Les deux repondent a des questions DIFFERENTES, sur des donnees differentes, pour des
# consommateurs differents :
#
#   `supervision.yml`  -> une SONDE rend un VERDICT avec un TTL.   « est-ce casse ? »
#   `metriques.yml`    -> un EXPORTATEUR expose une SERIE.         « depuis quand,
#                                                                    et vers ou ? »
#
# `docs/supervision-conception.md` le dit deja dans l'autre sens : « une metrique a seuil
# appartient a Prometheus et Grafana ; melanger les deux rendrait les deux moins
# lisibles ». Ce fichier est l'autre moitie de cette phrase.
#
# CE QUE LE MOTEUR EN DERIVE : la cible de scrutation de Prometheus
# (`serveur_prometheus_cibles_supplementaires`, un crochet qui existait et que personne ne
# remplissait) et les panneaux du tableau de bord.
#
# CE QU'IL N'EN DERIVE PAS, ET C'EST VOULU : le FLUX. Le port 9187 doit s'ouvrir depuis
# l'observatoire, et c'est `meta/flux.yml` qui le declare — la ou vivent deja tous les
# flux de ce role. Deux fichiers pour un meme fait finiraient par diverger ; on l'a vu
# assez souvent ici.

# L'EXPORTATEUR : ce que le role installe pour qu'il y ait quelque chose a lire.
exportateur:
  paquet: prometheus-postgres-exporter
  service: prometheus-postgres-exporter
  port: 9187
  job: postgresql

# LES PANNEAUX : ce qui merite d'etre REGARDE DANS LE TEMPS.
#
# Ni un par metrique — l'exportateur en publie plus de deux cents — ni un par role. Un par
# QUESTION QU'ON SE POSE VRAIMENT quand quelque chose commence a aller moins bien.
#
# LE CRITERE : une serie a sa place ici si elle PRECEDE un verdict ou si elle n'en aura
# jamais. Ce qui bascule d'un coup appartient a Icinga ; ce qui derive lentement n'a que
# le graphe pour se faire voir.
panneaux:
  - titre: "Connexions utilisées"
    expr: "sum by (instance) (pg_stat_activity_count)"
    unite: connexions
    raison: >-
      La sonde Icinga crie a 70 % et a 90 %. Ce panneau dit ce qu'elle ne peut pas dire :
      depuis QUAND ca monte. Une base qui passe de 20 a 60 connexions en trois semaines
      n'a rien casse — elle annonce la date ou elle cassera.

  - titre: "Taux de succès du cache"
    expr: >-
      sum by (instance) (rate(pg_stat_database_blks_hit[5m]))
      / clamp_min(sum by (instance) (rate(pg_stat_database_blks_hit[5m])
        + rate(pg_stat_database_blks_read[5m])), 1)
    unite: ratio
    raison: >-
      CELUI-LA N'AURA JAMAIS DE VERDICT, et c'est pourquoi il compte. Quand les donnees
      depassent `shared_buffers`, la base va chercher sur disque de plus en plus souvent.
      Rien ne casse, rien n'alerte : tout devient lent. C'est exactement la panne qu'un
      graphe voit et qu'une sonde ne verra jamais.

  - titre: "Taille des bases"
    expr: "sum by (datname) (pg_database_size_bytes)"
    unite: octets
    raison: >-
      La croissance est la seule chose qu'on ne peut pas mesurer apres coup. Savoir qu'une
      base a double en deux mois se decide deux mois plus tot — ou jamais.

  - titre: "Transactions par seconde"
    expr: >-
      sum by (instance) (rate(pg_stat_database_xact_commit[5m])
        + rate(pg_stat_database_xact_rollback[5m]))
    unite: tps
    raison: >-
      Le contexte des trois autres. Des connexions qui montent a charge CONSTANTE ne
      disent pas la meme chose que des connexions qui montent parce que le travail a
      double — et le geste qui suit n'est pas le meme non plus.