Logs & monitoring

Chinaski vous donne plusieurs surfaces d'observation : le journal système (avec des événements de sécurité JSON structurés), les vues de logs dans l'application (journal des événements, journal d'auth, historique de build), des endpoints de santé multi-vérifications pour le monitoring externe, et un résumé de métriques. Cette page indexe les pièces et lie vers chaque sous-page :

• Logs système et événements de sécurité : où les logs atterrissent, les lignes d'événements JSON, les conseils PII/rétention, et le journal de sécurité externe optionnel.
• Vues de logs dans l'application : journal des événements, historique d'auth, historique de build et le dashboard de métriques.
• Health checks et monitoring : /health, /api/health, et comment les intégrer dans un monitoring de disponibilité.

Les réponses rapides

• Les logs vivent dans systemd-journald (journalctl -u chinaski@<N> -f), avec les événements à fort signal émis en plus comme lignes JSON lisibles par machine sur le même flux (grep '"event"' les isole).
• La piste des builds est dans l'application, pas seulement dans journalctl : l'historique de build conserve les logs par exécution, les temps par phase, et les résultats de validation.
• Les moniteurs externes devraient viser l'endpoint de santé ; le projet fournit un moniteur cron de 5 minutes pour le succès des builds et la présence des pages, comme template prêt à l'emploi.
• Les données sensibles (IPs client) voyagent dans les champs de log ; le README inclut un snippet de politique de rétention journald et conseille de faire correspondre la rétention dans tout SIEM externe.

Dans cette section

• Health checks et monitoring
• Vues de logs dans l'application
• Logs système et événements de sécurité