Johan LEROY
dc952d13aa
L'API exposait /metrics, mais aucun collecteur ne le lisait : monitoring/ ne contenait que des .gitkeep. Sous le profil Compose `monitoring` : prometheus, alertmanager, grafana, postgres-exporter, node-exporter et cadvisor. Tous ont un mem_limit, pour environ 700 Mo au total sur la VM de 8 Go, et leurs interfaces n'écoutent que sur 127.0.0.1. Le profil est actif en prod via COMPOSE_PROFILES, donc à chaque déploiement, et se lance à la demande ailleurs (make monitoring-up). - Neuf règles d'alerte (API, base, hôte, cibles). Chacune a un cas dans les tests joués par `promtool test rules`, en CI comme par make monitoring-check. - Alertmanager route les alertes par courriel vers Mailpit ; un critical masque le warning de la même cible. - Grafana est provisionné : sources Prometheus et TimescaleDB, et trois tableaux de bord (API, données et dérive du modèle, infrastructure). - Le rôle PostgreSQL `supervision` est en lecture seule sur les seules tables métier (db/roles/supervision.sql), posé par make db-ensure-supervision et par stack-up quand le profil est actif. - Le jeton de /metrics passe à Prometheus en secret Compose (APP_METRICS_TOKEN) ; provision-host.sh génère ce secret et les deux autres. Backend : - un APP_METRICS_TOKEN vide vaut absent ; - les sondes de santé ne comptent plus dans les métriques ; - seaux de latence fins autour de 500 ms ; - un registre Prometheus par application, sans quoi toute application créée après la première (dans les tests) ne mesurait rien. Réf : #26
Base de donnees
PostgreSQL 17 avec l'extension TimescaleDB, servie en local par le service db du
docker-compose.yml racine (image timescale/timescaledb-ha:pg17).
init: scripts de bootstrap joues au premier demarrage du conteneur.migrations: migrations SQL versionnees.seeds: jeux de donnees de reference.demo.sqlseme trois sitesdemo-*, 72 heures de releves, des alertes et des rapports de derive pour la CI, l'e2e et les tirs de charge. Base jetable seulement.roles: roles PostgreSQL hors schema applicatif.supervision.sqlpose le role en lecture seule de Grafana et de postgres-exporter, rejoue parmake db-ensure-supervision(et parmake stack-upquand la supervision est active) plutot que parinit, qui ne rejoue jamais.
Les migrations du schema applicatif expose par l'API vivent dans
apps/backend/alembic, pas ici.
init ne rejoue jamais
Ces scripts sont montes sur /docker-entrypoint-initdb.d, dont PostgreSQL ne joue le
contenu qu'a la toute premiere initialisation, quand PGDATA est vide. Modifier ou
ajouter un script ensuite reste sans effet sur une base existante : il faut detruire
le volume, ce que fait make db-reset.
L'image apporte ses propres scripts dans ce dossier, et ils comptent :
| Script | Origine | Role |
|---|---|---|
000_install_timescaledb.sh |
image | Cree l'extension dans postgres, template1 et la base applicative, et fixe timescaledb.telemetry_level. |
001_timescaledb_tune.sh |
image | Lance timescaledb-tune sur la memoire et les CPU vus par le conteneur. |
010_install_timescaledb_toolkit.sh |
image | Ajoute timescaledb_toolkit. |
100-extensions.sql |
ce depot | Declare explicitement les extensions attendues. |
110-test-database.sql |
ce depot | Cree enervision_test, attendue par la suite de tests du backend. |
D'ou deux contraintes dans docker-compose.yml. Nos fichiers sont montes un par un,
et non par leur dossier : un montage de ./db/init sur /docker-entrypoint-initdb.d
remplacerait le dossier de l'image au lieu de s'y ajouter, et ferait disparaitre les trois
scripts ci-dessus sans le moindre message. Ajouter un fichier ici impose donc d'ajouter
une ligne la-bas. Et leur numerotation commence a 100 pour passer apres 010, y compris
en locale C ou un prefixe a deux chiffres se trierait avant.
Comme un bootstrap peut toujours avoir ete saute, deux gardes le rattrapent :
/api/v1/health/ready repond 503 si l'extension n'est pas chargee, et la premiere
revision Alembic refuse de s'appliquer.