Monitorer le serveur et le hub Mercure avec Ember¶

Vous êtes développeur·se sur Kirexo et vous voulez surveiller en temps réel le serveur FrankenPHP/Caddy et le hub Mercure pendant que la stack tourne — pour repérer un pic d'erreurs, une saturation de workers ou suivre les abonnements à un topic.

Ember est une interface en mode texte (TUI) qui affiche en direct les métriques exposées par l'admin API Caddy (:2019) : requêtes/s, latences, status codes, workers FrankenPHP et compteurs Mercure. C'est un moniteur live : il n'archive rien et ne déclenche aucune alerte (voir l'encadré « Hors périmètre » en fin de page).

Prérequis¶

La stack Docker est démarrée et healthy (castor docker:up).
Vous lancez la commande depuis un terminal hôte. Elle est refusée dans le devcontainer : Ember pilote un conteneur Docker branché sur le réseau kirexo et le socket Docker n'y est pas monté.
Pour que les panneaux Mercure se peuplent, la directive mercure doit être active côté Caddy (activée par le lot 1 de l'étape 7). Sans elle, les compteurs mercure_* et l'API des abonnements ne renvoient rien.

Lancer le moniteur¶

castor monitor

La cible démarre un conteneur jetable alexandredaubois/ember dans le réseau Docker kirexo, branché sur http://php:2019 (l'admin API interne du service FrankenPHP). Un preflight vérifie que le service php est healthy ; sinon la commande s'arrête avec un message demandant de lancer castor docker:up.

Quittez avec la touche q : le conteneur est supprimé automatiquement (--rm), rien ne persiste.

Lire les panneaux serveur¶

Requêtes/s : débit instantané traité par le serveur.
Latences : TTFB (time to first byte) et percentiles P50 → P99. La médiane (P50) reflète le cas courant ; P95/P99 révèlent la queue de distribution (requêtes lentes).
Status codes : répartition 2xx/3xx/4xx/5xx. Un pic de 5xx signale un incident applicatif à investiguer.
TLS : nombre de handshakes et version du protocole négociée.
FrankenPHP : workers actifs, threads, taille de la queue et mémoire consommée. Une queue qui gonfle pendant que les workers sont saturés indique des requêtes en attente — un signe de sous-dimensionnement ou de traitement lent.

Inspecter les abonnements Mercure¶

Le panneau Mercure d'Ember s'alimente à deux sources de l'admin API :

L'API des abonnements : GET /.well-known/mercure/subscriptions (tous les abonnements) et GET /.well-known/mercure/subscriptions/{topic} (filtré par topic). Elle liste les abonnés actuellement connectés.
Les compteurs mercure_* de /metrics : nombre d'abonnés connectés, total cumulé d'abonnés et nombre d'updates publiées.

Reliez ces données au topic privé article/{id} utilisé par l'autosave multi-onglets de l'étape 7 : ouvrir le même article dans deux onglets doit faire apparaître un abonné supplémentaire sur ce topic.

Panneaux Mercure vides ?

Ces données n'apparaissent que si la directive mercure est active côté Caddy (lot 1 de l'étape 7). Sans elle, les compteurs mercure_* et l'API des abonnements restent muets — les panneaux serveur, eux, fonctionnent indépendamment.

Endpoint interne

L'admin API :2019 n'est jamais exposée publiquement : elle n'est publiée dans aucun fichier compose et n'écoute que sur le réseau Docker kirexo. Ember y accède uniquement de l'intérieur de ce réseau. Ne publiez pas le port 2019 pour faire tourner Ember depuis l'extérieur — ce serait ouvrir une interface d'administration sans authentification.

Hors périmètre : pas d'historisation ni d'alerting

Ember est un moniteur live : il affiche un instantané continu, mais n'archive aucune métrique et ne déclenche aucune alerte. Une supervision durable (historique, seuils, alertes) nécessiterait Prometheus (scrape de /metrics) couplé à Grafana/Alertmanager — hors périmètre du projet à ce stade.

Aller plus loin¶

La cible Castor et son comportement (preflight, restriction hôte, conteneur jetable) sont décrits dans castor monitor.