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
45 lines
2.5 KiB
Markdown
45 lines
2.5 KiB
Markdown
# 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.sql` seme trois sites `demo-*`, 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.sql` pose le role en lecture
|
|
seule de Grafana et de postgres-exporter, rejoue par `make db-ensure-supervision` (et par
|
|
`make stack-up` quand la supervision est active) plutot que par `init`, 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.
|