Health checks & monitoring

Deux endpoints de santé non authentifiés existent pour les moniteurs, plus un dashboard de santé admin dans l'application. Cette page explique ce qu'ils rapportent et comment les intégrer dans le monitoring.

GET /health : la vérification complète

L'endpoint de santé propre de l'instance n'est pas qu'un ping ; il exécute un ensemble de vérifications et rapporte les résultats individuellement :

• Accessibilité de la base de données (critique) : le cas majoritaire pour la réponse « bad » de l'endpoint.
• Santé du moteur de templates (une compilation rapide d'un template de test).
• Mémoire : le RSS du processus est lu sur Linux, comparé à un seuil de 512 Mio (avertissement informatif quand au-dessus).
• Des vérifications supplémentaires couvrent l'environnement script/sortie de build ; chaque vérification porte son propre statut, détail, sévérité (critique/avertissement/info), et latence mesurée.

La réponse de premier niveau rapporte status comme critical si une vérification critique a échoué, warning si seulement des avertissements se sont déclenchés, sinon ok, plus un timestamp UTC, le nombre de vérifications, la liste par vérification, et un tableau d'avertissements. Un moniteur de disponibilité peut lire seulement le champ status ; un ingénieur d'astreinte obtient la liste des vérifications à la place.

GET /api/health : le résumé au niveau du site

Adapté aux moniteurs machine : statut (ok ou un état d'avertissement si le site a du contenu mais jamais de build), nombre de pages publiées, timestamp du dernier build, et si un build est en cours. Intégrez celui-ci dans vos vérificateurs externes de disponibilité.

Le moniteur cron de build

Le dépôt fournit un script cron prêt (bin/cron-build-monitor.sh) conçu pour tourner toutes les 5 minutes : il surveille que les builds se terminent avec succès et que les pages existent dans l'arborescence de sortie (pointe vers le répertoire de sortie de l'instance via l'environnement CHINASKI_OUTPUT). Programmez-le depuis la crontab tel quel ou utilisez-le comme template pour votre propre moniteur.

La demande de la checklist de production

La checklist de mise en ligne du README demande exactement ce câblage : surveiller l'endpoint de santé (/health joignable depuis votre moniteur ; 503 quand la base de données est injoignable), vérifier que les sauvegardes tournent selon la planification (systemctl list-timers chinaski-backup@<N> montre un NEXT), et garder un œil sur les logs basés sur le journal après les changements.