Supervision et journaux
Points de contrôle de santé, journaux et ce qui n'existe pas encore dans le code.
Supervision et journaux
Le code expose des points de contrôle de santé et écrit ses journaux sur la sortie standard. Il n'expose ni métriques (/metrics) ni traces. La supervision (alertes, tableaux de bord) se met en place dans le cluster.
Points de contrôle de santé
| Service | Endpoint | Utilisé par |
|---|---|---|
server | GET /health, GET /ready (réponse OK) | Sondes Kubernetes |
rag-agent | GET /healthz | Sondes Helm et HEALTHCHECK de l'image |
| Index API | GET / | Sondes Helm et HEALTHCHECK de l'image |
document-processor | GET /health | HEALTHCHECK de l'image |
web | racine du site | Sondes Helm |
Les sondes Helm du RAG Agent et de l'Index API démarrent après 120 secondes : le préchargement du reranker et la connexion à la base peuvent être longs au premier démarrage.
Journaux
- Les services Python journalisent au niveau
INFO(logging.basicConfig). Le document-processor respecteLOG_LEVEL. - Les journaux du serveur passent par la console Node.
- Les requêtes
/healthdu document-processor sont filtrées des journaux d'accès.
Le prompt complet (contexte récupéré et question) n'est journalisé qu'au niveau DEBUG. N'activez pas LOG_LEVEL=DEBUG en production : les journaux contiendraient alors des données de documents et de conversations.
Le RAG Agent journalise aussi les clés des métadonnées d'authentification et l'identifiant de l'utilisateur à chaque requête.
Que surveiller
- Disponibilité : réponses des points de santé ci-dessus, redémarrages de pods, échecs de sondes.
- Erreurs du chat : événements
errordu flux SSE derag-agent, et lignesERRORde ses journaux. - Régénération d'index : échecs renvoyés par
POST /regenerate-index. - Traitement des documents : jobs en échec ou en dépassement (
JOB_TIMEOUT_SECONDS) dans le document-processor. - Ressources : mémoire du document-processor (le modèle Docling et l'OCR sont gourmands) et du RAG Agent (index FAISS et reranker chargés en mémoire).
Rollback
En cas de régression après un déploiement, la première action est un retour arrière Helm sur la release du bot, voir Stratégie de déploiement.