Monitoring de CMonChoix Platform¶

Le monitoring sert à observer l'état de CMonChoix sans modifier son comportement. Pour une personne qui reprend le projet, c'est le premier endroit où regarder lorsqu'on se demande : « Est-ce que tout fonctionne normalement ? »

À quoi sert le monitoring ?¶

Le monitoring permet de surveiller la plateforme dans le temps afin de :

détecter une panne ou une anomalie ;
suivre les synchronisations ;
observer les performances ;
repérer une dégradation de la qualité des données ;
comparer l'état actuel à une période précédente ;
disposer de preuves utiles avant une intervention.

Le monitoring ne corrige rien automatiquement. Il observe et alerte.

Petit lexique¶

Métrique¶

Une métrique est une valeur mesurable : durée d'un run, nombre de lignes traitées, taux d'erreur, mémoire utilisée, temps de réponse, etc.

Log / journal¶

Un log est une trace textuelle ou structurée produite pendant l'exécution. Il aide à comprendre ce qu'un composant a fait ou pourquoi il a échoué.

Alerte¶

Une alerte signale qu'un indicateur sort d'une zone considérée comme normale. Une alerte n'est pas encore un diagnostic.

KPI¶

Un KPI (Key Performance Indicator) est un indicateur retenu pour suivre un objectif important : par exemple le taux de résolution des produits ou le nombre de lignes rejetées pendant une synchronisation.

Où le monitoring observe-t-il ?¶

Le monitoring couvre plusieurs couches :

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

Il ne devient jamais propriétaire de la logique métier de ces couches.

Les quatre questions à poser en premier¶

Quand quelque chose semble anormal, commencer par :

Le site répond-il ?
Les services Docker sont-ils démarrés ?
Le dernier traitement ou run s'est-il terminé ?
Les données produites semblent-elles cohérentes avec les runs précédents ?

Ces questions permettent rapidement de distinguer une panne technique d'un problème métier.

Contrôle global de premier niveau¶

La commande versionnée de diagnostic global est :

make doctor

Elle vérifie notamment :

la configuration Docker Compose ;
l'état des services ;
la réponse HTTP du site ;
la documentation ;
les montages du plugin ;
WordPress ;
MariaDB ;
certains marqueurs d'erreurs récents.

Un contrôle réussi doit se terminer par les statuts PASS attendus, notamment lorsque le garde Runtime est évalué :

RUNTIME_GUARD_STATUS=PASS

Si make doctor échoue, ne pas modifier immédiatement les données. Identifier d'abord la section du diagnostic qui échoue.

Observer le Pipeline¶

Le Pipeline doit permettre de suivre :

nombre de lignes reçues ;
lignes acceptées et rejetées ;
progression du run ;
durée ;
erreurs ;
lignes projetées ;
résultats de qualité.

Exemple¶

Si un marchand produisait habituellement 20 000 lignes et que le nouveau run n'en lit que 300, cela peut indiquer :

un feed tronqué ;
une erreur d'acquisition ;
un changement de format ;
une mauvaise configuration.

Ce signal ne dit pas encore quelle est la cause. Il indique où commencer l'investigation.

Voir Présentation du Pipeline.

Observer le Runtime¶

Le Runtime doit renseigner :

état des runs ;
progression ;
reprises ;
erreurs techniques ;
durée des traitements ;
disponibilité des workers.

Une panne Runtime signifie souvent que le traitement ne s'exécute pas correctement.

Un mauvais résultat métier avec un Runtime parfaitement sain indique plutôt qu'il faut regarder le Pipeline, le Domain Core ou les règles concernées.

Voir Runtime.

Observer la base de données¶

Le monitoring de la base aide à répondre à des questions comme :

MariaDB répond-elle ?
les temps de lecture se dégradent-ils ?
les tables attendues existent-elles ?
les projections ont-elles été reconstruites ?
l'espace disque évolue-t-il anormalement ?

Le monitoring ne doit pas transformer une anomalie en correction SQL automatique.

Voir Base de données.

Observer le Frontend¶

Le Frontend doit être surveillé notamment pour :

disponibilité HTTP ;
temps de réponse ;
erreurs visibles ;
pages qui ne chargent plus ;
projections absentes ou incohérentes.

Diagnostic simple¶

Si les données sont correctes en base mais mauvaises à l'écran, le problème peut être dans le Frontend ou la projection consommée.

Si les données sont déjà incorrectes avant le Frontend, il faut remonter vers la couche qui les produit.

Différence entre panne technique et anomalie métier¶

Cette distinction est fondamentale.

Panne technique¶

Exemples :

MariaDB indisponible ;
conteneur arrêté ;
erreur PHP fatale ;
disque saturé ;
worker qui ne démarre plus.

Anomalie métier¶

Exemples :

produit classé dans la mauvaise catégorie ;
identité ambiguë ;
image incohérente ;
baisse du taux de résolution ;
mauvais regroupement de variantes.

Le monitoring doit aider à savoir dans laquelle de ces deux familles se situe le problème.

Les indicateurs à suivre¶

Disponibilité¶

Répond à : « le composant fonctionne-t-il ? »

Performance¶

Mesure :

temps d'exécution ;
temps de réponse ;
mémoire et CPU lorsque pertinent ;
évolution par rapport à l'historique.

Qualité des données¶

Peut révéler :

baisse de résolution ;
hausse des inconnus ;
hausse des conflits ;
changements anormaux de projections.

Activité¶

Mesure le volume d'utilisation :

nombre de synchronisations ;
volume de lignes ;
fréquence des reconstructions ;
charge globale.

Une alerte n'est pas une conclusion¶

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

dépasse un seuil ;
chute brutalement ;
disparaît ;
devient incohérent avec les autres mesures.

Mais il faut ensuite analyser :

depuis quand ;
quel composant ;
quel périmètre ;
quels changements récents ;
quelles autres métriques ont changé en même temps.

Procédure d'investigation de premier niveau¶

Lorsqu'un problème apparaît :

noter l'heure et le symptôme ;
exécuter les contrôles read-only appropriés ;
vérifier l'état Docker et make doctor ;
identifier le dernier run concerné ;
comparer ses compteurs avec un run normal ;
consulter les logs du composant concerné ;
déterminer si l'anomalie est technique ou métier ;
seulement ensuite ouvrir la procédure de troubleshooting adaptée.

Ne pas commencer par modifier des données « pour voir si ça revient ».

État Docker¶

La commande suivante aide à observer l'utilisation de l'espace Docker :

docker system df

Un incident historique snapshotter.Usage failed a déjà été corrigé par recréation ciblée du conteneur ccx-platform-worker. Cette information est historique : elle ne signifie pas que toute future erreur Docker doit être corrigée de la même manière.

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

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

Cela évite qu'un conteneur remplisse le disque uniquement avec ses journaux.

Sauvegarde et capacité de reprise¶

Le monitoring du fonctionnement courant ne prouve pas qu'une sauvegarde est restaurable.

Ces contrôles sont séparés :

make backup-verify
make restore-check

Voir Sauvegarde et contrôle de restauration.

Ce qu'il ne faut jamais faire¶

Ne jamais :

utiliser une alerte comme justification suffisante pour écrire en base ;
mélanger monitoring et correction automatique ;
conclure sur une seule métrique sans contexte ;
supprimer les logs avant la fin d'une investigation ;
considérer un run « réussi » uniquement parce qu'il n'a pas crashé ;
ignorer une variation métier importante sous prétexte que les conteneurs sont verts.

Checklist quotidienne simple¶

Pour une surveillance de base :

[ ] le site répond ;
[ ] make doctor ne remonte pas de nouveau problème ;
[ ] les services Docker attendus sont actifs ;
[ ] les synchronisations prévues se terminent ;
[ ] les volumes traités restent plausibles ;
[ ] les erreurs ne progressent pas anormalement ;
[ ] les métriques métier critiques restent cohérentes ;
[ ] les sauvegardes et contrôles de restauration restent à jour selon leur fréquence prévue.