Journaux
Ce chapitre décrit où vont les journaux de Chatbotaurus, dans quel format, et comment les lire. Il distingue ce que le code fait de ce que votre hôte doit configurer.
Confidentialité. Le backend n'a, par défaut, aucune destination externe pour ses journaux : ils restent sur les hôtes que vous exploitez. Un export de la chaîne d'audit vers VictoriaLogs existe, il est désactivé par défaut et ne vise que l'adresse que vous configurez.
Où écrit le backend
forge-api écrit ses journaux sur la sortie standard, avec la bibliothèque
tracing. Le backend n'écrit pas ses journaux applicatifs dans un fichier.
| Réglage | Effet |
|---|---|
| Format par défaut | JSON, une ligne par événement |
Variable LOG_FORMAT à pretty ou compact | Sortie compacte lisible, pour le développement |
Variable RUST_LOG | Filtre par cible et niveau |
Variable TRACING_JSON | Sans effet sur forge-api : posée dans podman-compose.yml, elle n'est pas lue par ce binaire |
RUST_LOG absente ou invalide | info,forge_api=debug,forge_mcp=debug |
Chaque ligne JSON porte l'horodatage, le niveau, la cible (le module Rust) et
les champs du contexte de requête (request_id, méthode, chemin, statut,
durée). Source : init_tracing dans crates/forge-api/src/main.rs.
Filtres RUST_LOG
La syntaxe est celle de tracing-subscriber : des directives cible=niveau
séparées par des virgules. Un niveau seul fixe le défaut.
# Développement : forge-api détaillé, le reste en info
RUST_LOG=info,forge_api=debug
# Production : anomalies seules, avec la couche HTTP en info
RUST_LOG=warn,tower_http=info
# Diagnostic ponctuel, très verbeux
RUST_LOG=trace
L'unité de déploiement de forge-api fixe RUST_LOG à info.
Secrets et données personnelles
Toutes les lignes passent par un filtre de rédaction avant d'atteindre la sortie : clés d'API, jetons JWT et bearer, clés privées et adresses e-mail sont masqués (filtre de rédaction du code). C'est un filet : la règle reste de ne pas journaliser de secret.
Lire les journaux d'un conteneur
Les services tournent dans des conteneurs Podman. Lancez les commandes avec le compte qui exécute les conteneurs.
# Suivre un service en direct
podman logs -f forge-api
# Les 100 dernières lignes
podman logs --tail 100 forge-api
# Avec horodatage, sur les dernières 24 heures
podman logs -t --since 24h forge-api
Résultat attendu : des lignes JSON, une par événement. Si Podman répond que le conteneur
n'existe pas, vérifiez le nom avec podman ps -a et le compte qui lance la commande (voir
Problèmes connus).
Les noms de conteneurs du plan backend (podman-compose.yml) :
| Service | Conteneur |
|---|---|
API Chatbotaurus (profil container-api) | forge-api |
| PostgreSQL | forge-postgres |
| Valkey | forge-valkey |
| Qdrant | forge-qdrant |
| Ollama | forge-ollama |
| Authentik | forge-authentik |
| OpenBao | forge-openbao |
| VictoriaMetrics | forge-victoriametrics |
| VictoriaLogs | forge-victorialogs |
| Administration PostgreSQL (pgAdmin) | forge-pgadmin |
| Transcription (Speaches) | forge-faster-whisper |
| Téléchargement des modèles vocaux | forge-tts-models |
| Synthèse vocale (Kokoro) | forge-kokoro-tts |
| LiveKit | forge-livekit |
| CrowdSec | forge-crowdsec |
| Agent de sauvegarde | forge-backup-agent |
| Téléversement (tusd) | forge-tusd |
| Stockage objet S3 | forge-seaweedfs |
Les services du plan client portent le préfixe mcp- (podman-compose.vps2.yml).
Pour les connaître : podman ps --format "{{.Names}}" sur l'hôte client.
En développement local, forge-api ne tourne pas en conteneur : il est lancé
par scripts/dev/run-forge-api.ps1 et écrit dans le terminal qui l'a lancé.
Le frontend (dx serve) écrit la compilation et le rechargement dans son
propre terminal ; ses erreurs d'exécution apparaissent dans la console du
navigateur.
Ce que le dépôt ne règle pas
- Rotation et taille. Aucune option de taille ou de rotation des journaux de
conteneurs n'est fixée dans les fichiers Compose. Dans les unités Quadlet, une
seule (
searxng) choisit un pilote de journal (journald). Vérifiez la politique de votre hôte avant de laisser un conteneur bavard tourner. - Collecte centralisée.
forge-victorialogstourne dans le plan backend de développement. Aucun agent du dépôt n'y envoie les journaux des conteneurs. Ce qui y arrive aujourd'hui, c'est la chaîne d'audit, quand vous activez l'export (voir la section « Chaîne d'audit et export vers VictoriaLogs » plus bas).
Chaîne d'audit et export vers VictoriaLogs
Les événements d'audit (connexions, actions sensibles) forment une chaîne
chaînée par empreintes (crates/forge-audit). Un export optionnel les envoie en
plus vers VictoriaLogs au format jsonline :
| Variable | Effet | Défaut |
|---|---|---|
FORGE_SIEM_ENABLED | À 1, active l'export | désactivé |
FORGE_SIEM_URL | Base de VictoriaLogs | http://localhost:9428 |
L'export est au mieux : si VictoriaLogs est arrêté, l'écriture dans la chaîne
n'est jamais bloquée, et le nombre d'échecs est compté
(crates/forge-audit/src/victorialogs_sink.rs).
Pour vérifier que l'export fonctionne, posez les deux variables, redémarrez forge-api
(il ne relit pas la configuration à chaud), puis interrogez VictoriaLogs (section
« Interroger VictoriaLogs » de Supervision).
Voir aussi
- Supervision — métriques, points de santé et stockage des journaux en développement
- Variables d'environnement — variables de journalisation et d'export de la chaîne d'audit
- Diagnostics et signalement — retrouver une ligne de journal par son identifiant de requête
- Problèmes connus — lire les journaux d'un conteneur qui ne démarre pas
- Gestion des erreurs — niveau de trace par statut HTTP et identifiant de requête