Operations Monitoring¶

Le monitoring permet d'observer en permanence l'état de fonctionnement de CMonChoix Platform.

Son objectif n'est pas uniquement de détecter les erreurs.

Il doit également permettre de comprendre le comportement global de la Platform, d'anticiper les dégradations et de fournir les informations nécessaires aux analyses, aux audits et aux décisions d'exploitation.

Le monitoring constitue ainsi l'un des piliers de l'exploitation industrielle de CMonChoix.

État CURRENT — P1.4¶

L'infrastructure d'observabilité et la livraison d'alertes ont été certifiées CLOSED / PASS le 5 septembre 2026.

Révision Git de clôture :

c1b2f6a356f23c1ace064a2a7e4f71c33ffb584e

État certifié :

Prometheus healthy/ready ;
14/14 règles Prometheus saines ;
cibles prometheus, node, cadvisor et alertmanager up ;
Alertmanager comme autorité unique de routage externe ;
Discord firing + resolved certifiés ;
API Alertmanager hôte limitée à 127.0.0.1:9093 ;
échecs systemd backup/maintenance routés vers Alertmanager ;
autorité systemd backup/maintenance : 13 artefacts sur 13 conformes à Git.

Cette fermeture certifie l'observabilité infrastructure et le chemin de livraison des alertes. Elle ne certifie pas encore les SLO métier ni la capacité quantitative du VPS ; ces mesures relèvent du chantier Capacity & SLO suivant.

Voir :

Objectifs¶

Le monitoring poursuit plusieurs objectifs.

détecter rapidement une anomalie ;
suivre l'état des traitements ;
mesurer les performances ;
contrôler la qualité des données ;
faciliter les investigations ;
garantir la stabilité de la Platform.

Une anomalie détectée rapidement coûte généralement beaucoup moins cher à corriger qu'une anomalie découverte plusieurs jours après son apparition.

Position dans l'architecture¶

Le monitoring couvre l'ensemble des couches de la Platform.

                Monitoring
                      │
      ┌───────────────┼───────────────┐
      │               │               │
  Pipeline        Runtime        Frontend
      │               │
      └────── Database ───────────────┘

Il ne participe jamais directement aux traitements.

Il observe uniquement leur comportement.

Principes¶

Le monitoring repose sur plusieurs principes.

Observation continue¶

Les composants critiques doivent pouvoir être observés en permanence.

Le monitoring ne doit pas dépendre d'une intervention manuelle.

Données objectives¶

Les indicateurs doivent représenter un état mesurable.

Ils ne doivent pas être interprétés directement comme une décision métier.

Vision globale¶

Le monitoring ne se limite pas à un composant.

Une dégradation peut provenir :

du Pipeline ;
de la Database ;
du Runtime ;
du Frontend ;
d'une interaction entre plusieurs couches.

Historisation¶

Les mesures importantes doivent être conservées.

Cette conservation permet :

d'identifier des tendances ;
de comparer plusieurs périodes ;
d'expliquer une régression ;
de mesurer les effets d'une évolution.

Domaines observés¶

Le monitoring couvre plusieurs domaines complémentaires.

Pipeline¶

Les traitements d'import et de transformation doivent être surveillés.

Exemples :

synchronisations en cours ;
durée des traitements ;
volume de données traité ;
progression des exécutions ;
erreurs de traitement.

Voir :

Pipeline Overview

Runtime¶

Le Runtime doit rester observable.

Les principaux indicateurs concernent notamment :

état des traitements ;
durée des exécutions ;
disponibilité des services ;
consommation des ressources.

Voir :

Runtime Overview

Database¶

La couche Database fait l'objet d'un suivi spécifique.

Les principaux objectifs sont :

vérifier la disponibilité des données ;
suivre les performances de lecture ;
contrôler les temps d'accès ;
identifier les reconstructions nécessaires.

Voir :

Database Overview

Frontend¶

Le Frontend est observé afin de garantir une expérience utilisateur stable.

Les mesures concernent notamment :

disponibilité ;
temps de réponse ;
comportement des pages ;
stabilité des projections consultées.

Indicateurs¶

Les indicateurs doivent être simples à interpréter.

Ils peuvent être regroupés en plusieurs familles.

Disponibilité¶

Ils permettent de répondre à une question simple :

Les composants fonctionnent-ils normalement ?

Performance¶

Ils mesurent notamment :

temps d'exécution ;
temps de réponse ;
évolution des performances ;
stabilité des traitements.

Qualité des données¶

Ces indicateurs permettent de vérifier que les traitements produisent un résultat cohérent.

Ils peuvent notamment mettre en évidence :

une baisse du taux de résolution ;
une augmentation des données incomplètes ;
une évolution inhabituelle des projections.

Activité¶

Ils décrivent le fonctionnement général de la Platform.

Exemples :

nombre de synchronisations ;
volume de données traité ;
fréquence des reconstructions ;
évolution de la charge.

Alertes¶

Le monitoring doit permettre de détecter rapidement une situation anormale.

Une alerte peut être déclenchée lorsqu'un indicateur :

dépasse un seuil ;
évolue brutalement ;
devient incohérent ;
disparaît complètement.

Une alerte n'est pas une erreur.

Elle constitue un signal nécessitant une analyse.

Analyse¶

Une anomalie détectée par le monitoring doit conduire à une investigation.

L'analyse consiste notamment à répondre aux questions suivantes.

Quel composant est concerné ?
Depuis quand la situation est-elle apparue ?
L'anomalie est-elle reproductible ?
Une évolution récente peut-elle l'expliquer ?
Les autres composants sont-ils affectés ?

Cette approche permet d'éviter des corrections inadaptées.

Dépendances¶

Le monitoring consulte les informations produites par :

le Pipeline ;
le Runtime ;
la Database ;
les Read Services ;
les outils d'exploitation.

Il ne modifie jamais directement leur comportement.

Invariants¶

Le monitoring respecte plusieurs propriétés fondamentales.

Aucune logique métier¶

Le monitoring observe.

Il ne prend aucune décision métier.

Aucun impact fonctionnel¶

Les mécanismes de supervision ne doivent pas modifier les traitements observés.

Indicateurs reproductibles¶

Les mesures doivent être calculées de manière cohérente afin de permettre les comparaisons dans le temps.

Observabilité durable¶

Les informations utiles doivent rester disponibles suffisamment longtemps pour permettre les analyses.

Garde-fous¶

Afin de conserver un monitoring pertinent, plusieurs règles doivent toujours être respectées.

Ne jamais :

utiliser le monitoring pour corriger directement une anomalie ;
remplacer les audits par les seuls indicateurs ;
interpréter une alerte sans analyse préalable ;
créer des indicateurs sans objectif clairement défini ;
mélanger supervision technique et logique métier.

Évolutions futures¶

Le monitoring évoluera progressivement afin d'offrir :

une observabilité plus fine du Pipeline ;
une meilleure analyse des performances ;
des tableaux de bord spécialisés ;
une détection plus précoce des anomalies ;
une automatisation progressive des alertes.

Ces évolutions devront conserver un principe fondamental : fournir une vision fidèle et objective de l'état de fonctionnement de CMonChoix Platform sans modifier son comportement.

Voir aussi¶

Audit global¶

L'état du runtime est contrôlé avec la commande versionnée :

make doctor

Elle vérifie la configuration Compose, les services, la réponse HTTP, le montage canonique du plugin, WordPress, MariaDB et les marqueurs d'erreur récents.

Un contrôle réussi se termine notamment par :

RUNTIME_GUARD_STATUS=PASS

La capacité de reprise est contrôlée séparément avec make backup-verify et make restore-check. Voir Sauvegarde et contrôle de restauration.

État Docker¶

Le contrôle Docker inclut :

docker system df

L'erreur snapshotter.Usage failed a été corrigée par recréation ciblée du conteneur ccx-platform-worker.

Les logs Docker sont limités par /etc/docker/daemon.json :

log-driver=json-file
max-size=50m
max-file=5

P1.1 Observability Storage v2¶

Objectif¶

Les données persistantes à croissance continue de Prometheus, Loki et Grafana ne doivent plus dépendre du petit filesystem racine. Le contrat Storage v2 conserve des volumes Docker nommés, mais les adosse à des répertoires explicites sur /mnt/data.

Le Compose canonique utilise :

Service	Volume v2	Device hôte	Identité runtime certifiée
Prometheus	`cmonchoix-platform_prometheus_data_v2`	`/mnt/data/cmonchoix-infra/observability/prometheus`	`65534:65534`
Loki	`cmonchoix-platform_loki_data_v2`	`/mnt/data/cmonchoix-infra/observability/loki`	`10001:10001`
Grafana	`cmonchoix-platform_grafana_data_v2`	`/mnt/data/cmonchoix-infra/observability/grafana`	`472:0`

Les volumes utilisent le driver Docker local avec type: none, o: bind et un device absolu. Les répertoires cibles doivent donc exister avant la création des volumes. Cette propriété est volontaire : une préparation absente doit faire échouer le cutover plutôt que provoquer une écriture silencieuse sur un autre stockage.

Baseline de préflight P1.1B¶

Le préflight de production du 3 septembre 2026 a certifié :

/ sur /dev/sda1, environ 3,5 GiB disponibles après le nettoyage P1.1 ;
/mnt/data sur /dev/sdb, filesystem ext4 distinct, environ 216 GiB disponibles ;
cible totale à migrer : environ 1,6 GiB ;
Prometheus : environ 1,3 GiB ;
Loki : environ 223 MiB ;
Grafana : environ 49 MiB ;
les trois répertoires cibles absents ;
les trois noms de volumes v2 absents ;
Prometheus et Loki prêts sur leurs endpoints locaux ;
WordPress, MariaDB, Redis, platform-worker, .env et les sources protégées inchangés.

Cette baseline est une preuve de préparation, pas une autorisation permanente de mutation. Un nouveau drift critique impose un nouvel audit avant cutover.

Volumes historiques à conserver¶

Pendant tout P1.1B, les volumes historiques restent des artefacts de rollback :

cmonchoix-platform_prometheus_data
cmonchoix-platform_loki_data
cmonchoix-platform_grafana_data

Interdictions pendant le chantier :

aucun docker volume rm sur ces volumes ;
aucun docker volume prune ;
aucun docker system prune --volumes ;
aucune réutilisation des répertoires source comme cible v2.

Ordre de cutover¶

La migration live doit être réalisée comme une opération contrôlée et fail-closed :

revalider le HEAD Git autorisé, les IDs runtime critiques, .env, les trois volumes v1 et /mnt/data ;
créer les trois répertoires cibles avec les propriétaires numériques certifiés ;
effectuer une première copie à chaud pour réduire la fenêtre d'arrêt ;
arrêter uniquement prometheus, loki et grafana ;
effectuer la copie finale avec conservation des UID/GID, modes, timestamps, liens et suppression des écarts côté destination ;
comparer tailles, nombres de fichiers/répertoires et preuves d'intégrité adaptées à chaque store ;
créer les volumes v2 depuis le Compose canonique ;
recréer uniquement les trois services stateful sur les volumes v2 ;
vérifier mounts, identité runtime, rétention effective, endpoints Prometheus/Loki et démarrage Grafana ;
vérifier que WordPress, MariaDB, Redis et platform-worker n'ont pas changé ;
conserver les volumes v1 intacts après succès.

Aucun cutover ne doit utiliser un docker compose up non ciblé sur l'ensemble de la plateforme.

Rollback¶

Le dépôt fournit docker-compose.observability-storage-v1-rollback.yml.

Cet override remplace les trois mounts stateful par leurs volumes historiques exacts, déclarés external: true. Cette déclaration est fail-closed : si un volume historique attendu est absent, Compose ne doit pas créer un volume vide à sa place.

Le rollback doit :

arrêter uniquement Prometheus, Loki et Grafana ;
vérifier l'existence des trois volumes v1 ;
rendre le Compose canonique avec l'override de rollback ;
recréer uniquement les trois services stateful ;
vérifier que /prometheus, /loki et /var/lib/grafana sont de nouveau adossés aux volumes v1 exacts ;
vérifier Prometheus ready, Loki ready et Grafana accessible ;
ne supprimer ni les volumes v2 ni les répertoires /mnt/data pendant l'incident.

Les données écrites uniquement après le cutover v2 ne sont pas automatiquement réinjectées dans v1 lors d'un rollback. Le rollback est donc un retour de service vers le snapshot v1 figé au moment du cutover, pas une réplication bidirectionnelle.

Après stabilisation¶

La suppression éventuelle des volumes v1 constitue une opération de maintenance distincte. Elle ne fait pas partie de P1.1B et exige sa propre preuve de rétention, son propre audit de dépendances et une nouvelle autorisation opérateur.

Autorité de release et permissions des bind mounts¶

Une release utilisée comme working_dir Compose et comme source de bind mounts doit être préparée avec le script versionné :

bash scripts/observability-release-authority-prepare.sh <sha-40-caracteres>

Le script crée un worktree détaché sous /mnt/data/cmonchoix-release-authority/<sha> et vérifie que /mnt/data est un filesystem distinct de /. Il applique ensuite explicitement les permissions nécessaires : le répertoire racine de release reste traversable et le sous-arbre monitoring/ devient lisible/traversable par les UID non-root de Prometheus, Loki et Grafana.

Cette étape est obligatoire même si l'opérateur travaille avec umask 077. Un git worktree add brut sous un umask restrictif peut produire un répertoire de release en 0700 et des YAML en 0600. Dans ce cas, les bind mounts existent mais les processus non-root des containers reçoivent permission denied au démarrage.

Invariants :

ne jamais corriger ce problème avec chmod -R 777 ;
ne jamais changer le contenu Git pour résoudre un problème de modes filesystem ;
ne jamais faire de git reset --hard, git restore ou stash du checkout historique pour créer l'autorité de release ;
la release doit rester propre au sens Git après ajustement des modes ;
en cas d'échec de préparation, le script retire uniquement le worktree incomplet qu'il vient de créer ;
la release utilisée par des containers actifs ne doit pas être supprimée tant que leurs bind mounts la référencent.

Le marqueur attendu est :

CCX_OBSERVABILITY_RELEASE_AUTHORITY_PREPARE=PASS