PyTorch Lightning 控制台日志配置指南捕获、分级与重定向训练日志【免费下载链接】pytorch-lightningPretrain, finetune ANY AI model of ANY size on 1 or 10,000 GPUs with zero code changes.项目地址: https://gitcode.com/gh_mirrors/py/pytorch-lightning本指南围绕 PyTorch Lightning 的控制台console日志机制展开讲解如何通过 Python 标准库logging捕获 Lightning 在训练过程中输出的进度信息与用户警告并实现日志级别调整、模块级细粒度配置以及将日志重定向到文件的完整方案。读完本文你将掌握lightning.pytorch等 logger 命名空间的来源与结构理解分布式训练下仅 rank 0 打印日志的实现原理并能基于仓库源码定位任意一条训练日志的出处。Lightning 的控制台日志从哪里来Lightning 在训练过程中会向控制台输出两类信息训练过程的有用信息例如训练启动时的设备/加速器配置、从检查点恢复状态的提示和面向用户的警告例如传入val_dataloader却未定义validation_step等配置问题。这些输出并非自研的打印框架而是完全基于Python 标准库的logging模块实现。因此你不需要学习任何 Lightning 专属的日志 API——只要熟悉 Pythonlogging的getLogger、setLevel、addHandler等常规操作就能完全接管和控制 Lightning 的控制台输出。从源码可以确认Lightning 的日志输出遍布整个训练流程。例如训练器调用链 中检测到KeyboardInterrupt时会输出Detected KeyboardInterrupt, attempting graceful shutdown ...检查点连接器 在恢复检查点时输出Restoring states from the checkpoint path at ...配置验证器 在检测到val_dataloader但缺少validation_step时发出警告加速器连接器 输出设备与分布式策略相关的启动信息。这些信息统一通过rank_zero_info/rank_zero_warn等函数输出详见下文分布式训练与 rank_zero一节而它们的底层 logger 就是本文要操作的对象。获取 Lightning 的控制台 loggerLightning 为不同层级准备了独立的 logger 命名空间使用 Pythonlogging的getLogger即可获取无需任何额外配置import logging # 获取 Lightning 根级 logger覆盖 pytorch 训练流程 logging.getLogger(lightning.pytorch)代码中写入lightning.pytorch这一命名空间正是因为源码里 logger 名称取自模块名__name__。查看 pytorch 包初始化代码_root_logger logging.getLogger() _logger logging.getLogger(__name__) # 即 lightning.pytorch _logger.setLevel(logging.INFO) # 如果根 logger 没有任何 handler则为 Lightning logger 添加一个 StreamHandler if not _root_logger.hasHandlers(): _logger.addHandler(logging.StreamHandler()) _logger.propagate False__name__在导入lightning.pytorch时即展开为字符串lightning.pytorch这正是文档示例中可直接getLogger(lightning.pytorch)的原因。同理Fabric 包初始化 注册了lightning.fabric这一命名空间结构与 pytorch 分支完全一致setLevel(logging.INFO) 条件性StreamHandler顶层 lightning 包 注册了lightning命名空间并额外指定了格式器logging.Formatter(%(levelname)s: %(message)s)使输出呈现INFO: .../WARNING: ...的经典前缀样式。因此无论你使用的是TrainerPyTorch 训练流程还是Fabric自定义训练循环都能通过对应的命名空间控制其控制台输出。若使用旧版独立的pytorch_lightning包则对应命名空间为pytorch_lightning操作方式完全相同。调整日志级别静默或放大 Lightning 的输出Lightning 默认把日志级别设置为INFO见上文源码中的_logger.setLevel(logging.INFO)这意味着训练过程中的常规进度信息会直接打印到控制台。当你不希望看到这些信息、只想在出现错误时才知道发生了问题时可以将根级 logger 的级别提高到ERRORimport logging # 在 root level 配置 Lightning 的日志级别仅显示 ERROR 及以上 logging.getLogger(lightning.pytorch).setLevel(logging.ERROR)Pythonlogging的级别自低到高为DEBUG(10)、INFO(20)、WARNING(30)、ERROR(40)、CRITICAL(50)。设置生效后logger会过滤掉所有低于该级别的记录setLevel(logging.ERROR)只保留错误与致命错误训练过程的 INFO 提示和 WARNING 警告全部静默setLevel(logging.DEBUG)输出最详细的调试信息适合排查 Lightning 内部行为setLevel(logging.WARNING)只保留警告与错误隐藏常规进度信息setLevel(logging.INFO)即 Lightning 的默认行为。需要说明的是Pythonlogging的级别具有继承特性子 logger 若未显式setLevel会沿命名空间向上使用最近父级的有效级别。因此对lightning.pytorch设置级别会统一作用于其下所有子模块 logger如lightning.pytorch.core、lightning.pytorch.trainer等而单独设置某个子模块的级别则只影响该模块的输出。模块级配置精细化控制与重定向到文件除了在根级统一调整Lightning 的日志体系还支持模块级配置。你可以针对某个子模块单独设置级别、添加自定义 handler甚至把该模块的输出重定向到日志文件import logging # 模块级配置为 lightning.pytorch.core 模块单独添加文件输出 logger logging.getLogger(lightning.pytorch.core) logger.addHandler(logging.FileHandler(core.log))执行上述代码后lightning.pytorch.core模块产生的日志会在继续输出到控制台的同时追加写入core.log文件FileHandler默认以追加模式打开文件。由于 handler 是独立于 logger 级别存在的控制台与文件的输出可以分别控制例如import logging file_handler logging.FileHandler(training.log) file_handler.setLevel(logging.DEBUG) # 文件里记录最详细的信息 console_handler logging.StreamHandler() console_handler.setLevel(logging.INFO) # 控制台只显示常规信息 logger logging.getLogger(lightning.pytorch) logger.addHandler(file_handler) logger.addHandler(console_handler) logger.setLevel(logging.DEBUG) # logger 本身放行 DEBUG由各 handler 自行过滤这样便形成了控制台看概览、文件留全量的典型生产配置。模块级命名空间的来源同样可以从源码得到印证。例如 核心模块 module.py 中log logging.getLogger(__name__)其__name__即展开为lightning.pytorch.corecheckpoint 保存模块 与 可服务模块校验器 也都采用同样的模式。这意味着你可以按lightning.pytorch.core、lightning.pytorch.trainer、lightning.pytorch.callbacks等命名空间对任意子系统单独定制日志行为。分布式训练与 rank_zero为什么只打印一份日志在多卡/多机分布式训练中如果每个进程都向控制台打印日志输出会被严重刷屏且难以阅读。Lightning 通过rank_zero_*系列函数解决了这个问题只有 rank 0 进程会输出日志其余进程的日志被过滤。其实现位于 Fabric 的 rank_zero 工具通过_get_rank()按优先级读取RANK、LOCAL_RANK、SLURM_PROCID、JSM_NAMESPACE_RANK等环境变量来确定当前进程的 rank并将rank_zero_only.rank初始化为此值。之后rank_zero_info、rank_zero_warn、rank_zero_debug等函数由 lightning_utilities 的 rank_zero 模块 提供并重导出只会让 rank 0 真正发出日志。pytorch 侧的 rank_zero 模块 对此做了再导出并将其底层 logger 指向logging.getLogger(lightning.pytorch.utilities.rank_zero)。因此你通过logging.getLogger(lightning.pytorch)调整的级别同样会作用于这些 rank_zero 输出——两者是同一套 logging 体系。这一点也解释了当你把lightning.pytorch的级别调高到ERROR后训练过程中原本刷屏的GPU available: True, used: True、LOCAL_RANK: 0等 rank 0 提示会一并消失因为它们都是经rank_zero_info输出的 INFO 级别信息。测试如何验证日志行为仓库的测试体系也直接利用了这套 logging 机制可以作为验证配置效果与排查日志问题的参考。在 tests/tests_pytorch/conftest.py 中定义了自定义的caplogfixture由于 Lightning 在根 logger 无 handler 时会关闭 propagate_logger.propagate Falsepytest 的caplog默认可能捕获不到日志该 fixture 会临时将根 logger 及所有lightning.pytorch.*子 logger 的propagate置为True测试结束后再恢复原状。这给了我们两点实战启示如果你在自己的测试或脚本里用pytest的caplog断言 Lightning 日志需要参照上述 fixture 处理propagate如果你在自定义脚本中想统一接管所有 Lightning 输出例如项目自身的 logging 配置已在根 logger 上挂了 handler可以在根 logger 已配置 handler 的前提下将lightning.pytorch的propagate设为True让消息上抛到你的根 logger 统一格式化——这与源码中if not _root_logger.hasHandlers(): ... propagate False的初始逻辑正好互补。完整实战示例与配置建议将上述各节组合起来一个典型的控制台静默 全量落盘配置如下import logging # 1) 根级只让 ERROR 及以上输出到控制台配合源码默认的 StreamHandler logging.getLogger(lightning.pytorch).setLevel(logging.ERROR) # 2) 模块级core 模块的 DEBUG 日志单独写入文件便于深挖模型逻辑 core_logger logging.getLogger(lightning.pytorch.core) core_logger.setLevel(logging.DEBUG) core_handler logging.FileHandler(core.log) core_handler.setFormatter(logging.Formatter(%(asctime)s %(levelname)s %(name)s: %(message)s)) core_logger.addHandler(core_handler) # 3) Fabric 用户可同样配置其命名空间 logging.getLogger(lightning.fabric).setLevel(logging.ERROR)实践建议与注意事项汇总先getLogger再setLevel/addHandler所有配置都基于 Python 标准库logging无需导入 Lightning 专属日志模块命名空间三选一lightning.pytorchTrainer 流程、lightning.fabricFabric 流程、lightning顶层聚合旧独立包对应pytorch_lightning级别与 handler 相互独立setLevel决定哪些记录被放行addHandler决定放行后的记录送往哪里二者可分别精细化配置分布式场景下默认只有 rank 0 打印由rank_zero_*机制保证见 rank_zero 源码无需自行去重注意 propagate 行为默认根 logger 无 handler 时 Lightning 关闭向上传播若项目已在根 logger 配置统一 handler可显式开启propagate True实现集中管理。至此你已掌握从获取 logger、调整级别到模块级重定向文件的完整控制台日志方案并能在源码层面定位任意一条 Lightning 日志的产生位置与输出条件。【免费下载链接】pytorch-lightningPretrain, finetune ANY AI model of ANY size on 1 or 10,000 GPUs with zero code changes.项目地址: https://gitcode.com/gh_mirrors/py/pytorch-lightning创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PyTorch Lightning 控制台日志配置指南：捕获、分级与重定向训练日志
PyTorch Lightning 控制台日志配置指南捕获、分级与重定向训练日志【免费下载链接】pytorch-lightningPretrain, finetune ANY AI model of ANY size on 1 or 10,000 GPUs with zero code changes.项目地址: https://gitcode.com/gh_mirrors/py/pytorch-lightning本指南围绕 PyTorch Lightning 的控制台console日志机制展开讲解如何通过 Python 标准库logging捕获 Lightning 在训练过程中输出的进度信息与用户警告并实现日志级别调整、模块级细粒度配置以及将日志重定向到文件的完整方案。读完本文你将掌握lightning.pytorch等 logger 命名空间的来源与结构理解分布式训练下仅 rank 0 打印日志的实现原理并能基于仓库源码定位任意一条训练日志的出处。Lightning 的控制台日志从哪里来Lightning 在训练过程中会向控制台输出两类信息训练过程的有用信息例如训练启动时的设备/加速器配置、从检查点恢复状态的提示和面向用户的警告例如传入val_dataloader却未定义validation_step等配置问题。这些输出并非自研的打印框架而是完全基于Python 标准库的logging模块实现。因此你不需要学习任何 Lightning 专属的日志 API——只要熟悉 Pythonlogging的getLogger、setLevel、addHandler等常规操作就能完全接管和控制 Lightning 的控制台输出。从源码可以确认Lightning 的日志输出遍布整个训练流程。例如训练器调用链 中检测到KeyboardInterrupt时会输出Detected KeyboardInterrupt, attempting graceful shutdown ...检查点连接器 在恢复检查点时输出Restoring states from the checkpoint path at ...配置验证器 在检测到val_dataloader但缺少validation_step时发出警告加速器连接器 输出设备与分布式策略相关的启动信息。这些信息统一通过rank_zero_info/rank_zero_warn等函数输出详见下文分布式训练与 rank_zero一节而它们的底层 logger 就是本文要操作的对象。获取 Lightning 的控制台 loggerLightning 为不同层级准备了独立的 logger 命名空间使用 Pythonlogging的getLogger即可获取无需任何额外配置import logging # 获取 Lightning 根级 logger覆盖 pytorch 训练流程 logging.getLogger(lightning.pytorch)代码中写入lightning.pytorch这一命名空间正是因为源码里 logger 名称取自模块名__name__。查看 pytorch 包初始化代码_root_logger logging.getLogger() _logger logging.getLogger(__name__) # 即 lightning.pytorch _logger.setLevel(logging.INFO) # 如果根 logger 没有任何 handler则为 Lightning logger 添加一个 StreamHandler if not _root_logger.hasHandlers(): _logger.addHandler(logging.StreamHandler()) _logger.propagate False__name__在导入lightning.pytorch时即展开为字符串lightning.pytorch这正是文档示例中可直接getLogger(lightning.pytorch)的原因。同理Fabric 包初始化 注册了lightning.fabric这一命名空间结构与 pytorch 分支完全一致setLevel(logging.INFO) 条件性StreamHandler顶层 lightning 包 注册了lightning命名空间并额外指定了格式器logging.Formatter(%(levelname)s: %(message)s)使输出呈现INFO: .../WARNING: ...的经典前缀样式。因此无论你使用的是TrainerPyTorch 训练流程还是Fabric自定义训练循环都能通过对应的命名空间控制其控制台输出。若使用旧版独立的pytorch_lightning包则对应命名空间为pytorch_lightning操作方式完全相同。调整日志级别静默或放大 Lightning 的输出Lightning 默认把日志级别设置为INFO见上文源码中的_logger.setLevel(logging.INFO)这意味着训练过程中的常规进度信息会直接打印到控制台。当你不希望看到这些信息、只想在出现错误时才知道发生了问题时可以将根级 logger 的级别提高到ERRORimport logging # 在 root level 配置 Lightning 的日志级别仅显示 ERROR 及以上 logging.getLogger(lightning.pytorch).setLevel(logging.ERROR)Pythonlogging的级别自低到高为DEBUG(10)、INFO(20)、WARNING(30)、ERROR(40)、CRITICAL(50)。设置生效后logger会过滤掉所有低于该级别的记录setLevel(logging.ERROR)只保留错误与致命错误训练过程的 INFO 提示和 WARNING 警告全部静默setLevel(logging.DEBUG)输出最详细的调试信息适合排查 Lightning 内部行为setLevel(logging.WARNING)只保留警告与错误隐藏常规进度信息setLevel(logging.INFO)即 Lightning 的默认行为。需要说明的是Pythonlogging的级别具有继承特性子 logger 若未显式setLevel会沿命名空间向上使用最近父级的有效级别。因此对lightning.pytorch设置级别会统一作用于其下所有子模块 logger如lightning.pytorch.core、lightning.pytorch.trainer等而单独设置某个子模块的级别则只影响该模块的输出。模块级配置精细化控制与重定向到文件除了在根级统一调整Lightning 的日志体系还支持模块级配置。你可以针对某个子模块单独设置级别、添加自定义 handler甚至把该模块的输出重定向到日志文件import logging # 模块级配置为 lightning.pytorch.core 模块单独添加文件输出 logger logging.getLogger(lightning.pytorch.core) logger.addHandler(logging.FileHandler(core.log))执行上述代码后lightning.pytorch.core模块产生的日志会在继续输出到控制台的同时追加写入core.log文件FileHandler默认以追加模式打开文件。由于 handler 是独立于 logger 级别存在的控制台与文件的输出可以分别控制例如import logging file_handler logging.FileHandler(training.log) file_handler.setLevel(logging.DEBUG) # 文件里记录最详细的信息 console_handler logging.StreamHandler() console_handler.setLevel(logging.INFO) # 控制台只显示常规信息 logger logging.getLogger(lightning.pytorch) logger.addHandler(file_handler) logger.addHandler(console_handler) logger.setLevel(logging.DEBUG) # logger 本身放行 DEBUG由各 handler 自行过滤这样便形成了控制台看概览、文件留全量的典型生产配置。模块级命名空间的来源同样可以从源码得到印证。例如 核心模块 module.py 中log logging.getLogger(__name__)其__name__即展开为lightning.pytorch.corecheckpoint 保存模块 与 可服务模块校验器 也都采用同样的模式。这意味着你可以按lightning.pytorch.core、lightning.pytorch.trainer、lightning.pytorch.callbacks等命名空间对任意子系统单独定制日志行为。分布式训练与 rank_zero为什么只打印一份日志在多卡/多机分布式训练中如果每个进程都向控制台打印日志输出会被严重刷屏且难以阅读。Lightning 通过rank_zero_*系列函数解决了这个问题只有 rank 0 进程会输出日志其余进程的日志被过滤。其实现位于 Fabric 的 rank_zero 工具通过_get_rank()按优先级读取RANK、LOCAL_RANK、SLURM_PROCID、JSM_NAMESPACE_RANK等环境变量来确定当前进程的 rank并将rank_zero_only.rank初始化为此值。之后rank_zero_info、rank_zero_warn、rank_zero_debug等函数由 lightning_utilities 的 rank_zero 模块 提供并重导出只会让 rank 0 真正发出日志。pytorch 侧的 rank_zero 模块 对此做了再导出并将其底层 logger 指向logging.getLogger(lightning.pytorch.utilities.rank_zero)。因此你通过logging.getLogger(lightning.pytorch)调整的级别同样会作用于这些 rank_zero 输出——两者是同一套 logging 体系。这一点也解释了当你把lightning.pytorch的级别调高到ERROR后训练过程中原本刷屏的GPU available: True, used: True、LOCAL_RANK: 0等 rank 0 提示会一并消失因为它们都是经rank_zero_info输出的 INFO 级别信息。测试如何验证日志行为仓库的测试体系也直接利用了这套 logging 机制可以作为验证配置效果与排查日志问题的参考。在 tests/tests_pytorch/conftest.py 中定义了自定义的caplogfixture由于 Lightning 在根 logger 无 handler 时会关闭 propagate_logger.propagate Falsepytest 的caplog默认可能捕获不到日志该 fixture 会临时将根 logger 及所有lightning.pytorch.*子 logger 的propagate置为True测试结束后再恢复原状。这给了我们两点实战启示如果你在自己的测试或脚本里用pytest的caplog断言 Lightning 日志需要参照上述 fixture 处理propagate如果你在自定义脚本中想统一接管所有 Lightning 输出例如项目自身的 logging 配置已在根 logger 上挂了 handler可以在根 logger 已配置 handler 的前提下将lightning.pytorch的propagate设为True让消息上抛到你的根 logger 统一格式化——这与源码中if not _root_logger.hasHandlers(): ... propagate False的初始逻辑正好互补。完整实战示例与配置建议将上述各节组合起来一个典型的控制台静默 全量落盘配置如下import logging # 1) 根级只让 ERROR 及以上输出到控制台配合源码默认的 StreamHandler logging.getLogger(lightning.pytorch).setLevel(logging.ERROR) # 2) 模块级core 模块的 DEBUG 日志单独写入文件便于深挖模型逻辑 core_logger logging.getLogger(lightning.pytorch.core) core_logger.setLevel(logging.DEBUG) core_handler logging.FileHandler(core.log) core_handler.setFormatter(logging.Formatter(%(asctime)s %(levelname)s %(name)s: %(message)s)) core_logger.addHandler(core_handler) # 3) Fabric 用户可同样配置其命名空间 logging.getLogger(lightning.fabric).setLevel(logging.ERROR)实践建议与注意事项汇总先getLogger再setLevel/addHandler所有配置都基于 Python 标准库logging无需导入 Lightning 专属日志模块命名空间三选一lightning.pytorchTrainer 流程、lightning.fabricFabric 流程、lightning顶层聚合旧独立包对应pytorch_lightning级别与 handler 相互独立setLevel决定哪些记录被放行addHandler决定放行后的记录送往哪里二者可分别精细化配置分布式场景下默认只有 rank 0 打印由rank_zero_*机制保证见 rank_zero 源码无需自行去重注意 propagate 行为默认根 logger 无 handler 时 Lightning 关闭向上传播若项目已在根 logger 配置统一 handler可显式开启propagate True实现集中管理。至此你已掌握从获取 logger、调整级别到模块级重定向文件的完整控制台日志方案并能在源码层面定位任意一条 Lightning 日志的产生位置与输出条件。【免费下载链接】pytorch-lightningPretrain, finetune ANY AI model of ANY size on 1 or 10,000 GPUs with zero code changes.项目地址: https://gitcode.com/gh_mirrors/py/pytorch-lightning创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考