feat(monitoring): supervise l'API, la base et l'hôte avec Prometheus et Grafana
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
This commit is contained in:
@@ -0,0 +1,15 @@
|
||||
-- Contrainte : rôle en lecture seule de la supervision (Grafana, postgres-exporter) -
|
||||
-- supervision.sql. Ses droits ne portent que sur les tables métier : jamais `app_user`, les
|
||||
-- jetons ni le journal d'audit. `pg_monitor` donne à l'exportateur les vues de statistiques.
|
||||
-- Rejoué par `make db-ensure-supervision`, qui passe `mot_de_passe` et `base` en variables psql :
|
||||
-- crée le rôle au besoin, puis réaligne à chaque passage mot de passe et droits.
|
||||
-- Piège : les tables doivent exister, d'où l'appel après `alembic upgrade head` dans `stack-up`.
|
||||
|
||||
SELECT 'CREATE ROLE supervision LOGIN'
|
||||
WHERE NOT EXISTS (SELECT 1 FROM pg_roles WHERE rolname = 'supervision') \gexec
|
||||
|
||||
ALTER ROLE supervision WITH LOGIN PASSWORD :'mot_de_passe';
|
||||
GRANT pg_monitor TO supervision;
|
||||
GRANT CONNECT ON DATABASE :"base" TO supervision;
|
||||
GRANT USAGE ON SCHEMA public TO supervision;
|
||||
GRANT SELECT ON site, reading, alert, prediction, recommendation, drift_report TO supervision;
|
||||
Reference in New Issue
Block a user