Skip to main content
W&B capture le stdout et le stderr de votre script et les enregistre dans output.log, dans l’onglet Files du run. Par défaut, ce fichier est téléversé à la fin du run. Un journal vide ou manquant est donc souvent dû à un problème de synchronisation, et non à un échec de capture. Pour en savoir plus sur les téléversements multipart (console_multipart), la rotation des fragments et quand les activer, voir Logs de la console et wandb.Settings. Pour télécharger les journaux, voir Comment puis-je télécharger le fichier journal de la console d’un run ?.

​
La capture de la console est désactivée

Vous pouvez désactiver la capture de la console dans les paramètres ou à l’aide d’une variable d’environnement : 
wandb.init(settings=wandb.Settings(console="off"))

WANDB_CONSOLE=off python my_script.py
Vérifiez si l’un ou l’autre est défini dans votre environnement ou votre configuration de lancement. Pour le réactiver, supprimez ce paramètre ou définissez WANDB_CONSOLE=wrap.

​
Entraînement distribué (DDP / multiprocessing)

L’onglet Logs ne journalise la sortie que du processus qui détient le run W&B actif. Avec Lightning/DDP, les appels à print() ou wandb.termlog() effectués depuis des processus workers qui ne détiennent pas le run n’apparaissent que dans le terminal local. Initialisez le run sur le rang 0 et utilisez console="wrap". 
import wandb
from lightning.pytorch import Trainer
from lightning.pytorch.loggers import WandbLogger

wandb_logger = WandbLogger(
    project="my_project",
    settings=wandb.Settings(console="wrap"),  # ou WANDB_CONSOLE=wrap
)
trainer = Trainer(logger=wandb_logger, strategy="ddp", devices=2, accelerator="gpu")
Si l’onglet Logs reste vide, essayez console="redirect". La sortie peut apparaître dans output.log dans l’onglet Files, même si elle ne s’affiche pas en direct. Voir Journaliser des expériences distribuées pour les schémas de journalisation sur le rang 0.

​
Run toujours actif, mais aucun fichier dans l’onglet Files

Tant qu’un run est en cours, l’onglet Logs affiche la sortie en continu, mais output.log n’apparaît généralement pas dans Files tant que le run n’est pas terminé, à moins que vous n’ayez activé la journalisation multipart de la console lors de l’appel à wandb.init(). La fréquence de téléversement ne peut pas être modifiée après le démarrage du run.

​
Le run a planté avant le vidage

Sans journalisation multipart, un run interrompu de force (OOM, SIGKILL, etc.) peut ne téléverser aucun output.log et ne pas afficher de bouton de téléchargement. Activez console_multipart avant le démarrage du run afin que les fragments téléversés avant le plantage restent sur le serveur. Une copie locale est toujours écrite dans wandb/run-[TIMESTAMP]-[ID]/logs/output.log.

​
Les runs repris perdent les sorties de console précédentes

Sur les anciennes versions du SDK, wandb.init(resume="allow", id=...) peut écraser un unique fichier output.log. Avec console_multipart=True, chaque session écrit des fragments distincts dans logs/. Voir Logs de la console pour la configuration.

​
L’onglet Logs affiche moins de lignes que prévu

L’onglet Logs limite l’affichage pour des raisons de performances : un run stocke jusqu’à 100 000 lignes au total, et l’application en affiche jusqu’à 10 000 à la fois. Faites défiler les logs pour afficher les lignes plus anciennes. Le journal complet se trouve dans output.log ou dans des fragments en plusieurs parties. Téléchargez-le depuis l’onglet Files des détails du run, ou via l’API.
Logs Runs