尧图网站建设 
TradingAgents-CN 错误日志分离实战双文件处理器架构与 error.log 配置全解析【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN在 TradingAgents-CN 这类多智能体金融交易框架中日志是排查问题、监控告警的核心抓手。本指南以仓库内 错误日志分离功能文档 为主线完整讲解该项目将 WARNING 及以上级别日志单独输出到error.log的实现方案——包括tradingagents与app两个目录的处理器实现、config/logging.toml配置参数逐项说明、日志轮转机制以及基于真实源码与测试用例的运维最佳实践。读完本文你将掌握如何在本项目中配置、启用、监控与二次调整错误日志分离从而快速定位数据源切换、LLM 调用等高频异常。一、需求背景为什么要把错误日志单独分离在实施分离之前项目的 WARNING、ERROR、CRITICAL 级别日志与普通日志全部混写在tradingagents.log中。多智能体交易系统一天会产生大量 INFO 级日志股票分析、Token 消耗、模块流转等运维人员排查问题时需要在海量日志中反复grep效率低下且容易遗漏关键错误。该功能的核心需求有三点将WARNING、ERROR、CRITICAL三个级别的日志单独输出到error.log保持原有tradingagents.log记录所有级别日志不影响完整追踪与调试便于快速定位、实时监控与告警减少监控系统噪音。二、架构设计双文件处理器方案方案采用标准的 Pythonlogging双 Handler 结构同一份日志记录被多个处理器按各自级别阈值分流主日志文件tradingagents.log记录全部级别DEBUG、INFO、WARNING、ERROR、CRITICAL承担完整日志追踪职责错误日志文件error.log只记录 WARNING 及以上级别承担快速定位与监控告警职责。日志级别分流对照级别说明tradingagents.logerror.logDEBUG调试信息✅❌INFO一般信息✅❌WARNING警告信息✅✅ERROR错误信息✅✅CRITICAL严重错误✅✅从源码结构看这套一份记录、多处理器按级别过滤的机制是 Python 标准库logging的天然能力Handler.setLevel()决定单个处理器接收的最低级别而根 Logger 的级别决定记录能否进入分发流程。项目在 tradingagents/utils/logging_manager.py 的_setup_logging()中依次挂载 console、file、error、structured 四个处理器正是这一机制的完整落地。三、tradingagents 侧实现logging_manager.py 核心剖析tradingagents目录核心交易分析逻辑的日志由 tradingagents/utils/logging_manager.py 统一管理。3.1 在设置流程中挂载错误处理器_setup_logging()中错误处理器与文件处理器一起被挂载logging_manager.py# 添加处理器 self._add_console_handler(root_logger) if not self.config[docker][enabled] or not self.config[docker][stdout_only]: self._add_file_handler(root_logger) self._add_error_handler(root_logger) # 添加错误日志处理器 if self.config[handlers][structured][enabled]: self._add_structured_handler(root_logger)注意这里的 Docker 条件判断当docker.enabled为真且docker.stdout_only为真时不挂载任何文件处理器包括错误处理器日志只走 stdout。这是容器环境下避免日志文件失控的设计。3.2 _add_error_handler() 方法实现该方法logging_manager.py是错误日志分离的核心def _add_error_handler(self, logger: logging.Logger): 添加错误日志处理器只记录WARNING及以上级别 # 检查错误处理器是否启用 error_config self.config[handlers].get(error, {}) if not error_config.get(enabled, True): return log_dir Path(error_config.get(directory, self.config[handlers][file][directory])) error_log_file log_dir / error_config.get(filename, error.log) # 使用RotatingFileHandler进行日志轮转 max_size self._parse_size(error_config.get(max_size, 10MB)) backup_count error_config.get(backup_count, 5) error_handler logging.handlers.RotatingFileHandler( error_log_file, maxBytesmax_size, backupCountbackup_count, encodingutf-8 ) # 只记录WARNING及以上级别WARNING, ERROR, CRITICAL error_level getattr(logging, error_config.get(level, WARNING)) error_handler.setLevel(error_level) formatter logging.Formatter(self.config[format][file]) error_handler.setFormatter(formatter) logger.addHandler(error_handler)关键设计点默认值与容错enabled缺省为Truedirectory缺省继承handlers.file.directoryfilename缺省为error.log——即使配置节不完整也不会报错编码固定encodingutf-8保证中文日志本项目大量使用中文与 emoji 标识不乱码级别过滤通过error_handler.setLevel(error_level)实现默认为WARNING格式复用复用format.file格式串与主日志保持一致的解析格式。3.3 默认配置中的 error 处理器当配置文件加载失败或未提供配置时_load_default_config()提供内置兜底配置logging_manager.pyerror: { enabled: True, level: WARNING, # 只记录WARNING及以上级别 max_size: 10MB, backup_count: 5, directory: log_dir, filename: error.log },log_dir来自环境变量TRADINGAGENTS_LOG_DIR默认./logs根级别来自TRADINGAGENTS_LOG_LEVEL默认INFO。这意味着即便不写任何配置文件仅靠环境变量也能驱动整套双文件日志方案。四、配置文件详解config/logging.toml 逐项说明项目日志配置以 TOML 形式存放于 config/logging.toml加载与格式转换逻辑见 logging_manager.py 的_load_config_file()/_convert_toml_config()按config/logging_docker.toml→config/logging.toml→./logging.toml顺序查找。4.1 错误处理器配置节# 错误日志处理器只记录WARNING及以上级别 [logging.handlers.error] enabled true level WARNING # 只记录WARNING, ERROR, CRITICAL max_size 10MB backup_count 5 directory ./logs filename error.log4.2 参数速查表参数默认值取值范围/说明enabledtruetrue/false控制错误处理器是否挂载levelWARNINGDEBUG/INFO/WARNING/ERROR/CRITICAL决定 error.log 记录的最低级别max_size10MB支持KB/MB/GB后缀解析逻辑见 logging_manager.py 的_parse_size()也支持纯数字字节backup_count5保留的轮转备份文件数量超出自动删除最旧文件directory./logs日志目录缺省时继承handlers.file.directoryfilenameerror.log错误日志文件名可自定义4.3 与其他处理器协同同一份配置中还定义了 console、file、structured 处理器与各命名 Logger 的级别# 文件处理器 [logging.handlers.file] enabled true level DEBUG # 主日志记录全部级别 max_size 10MB backup_count 5 directory ./logs # 结构化日志处理器JSON格式 [logging.handlers.structured] enabled false # 默认关闭生产环境可启用 level INFO directory ./logs[logging.loggers]节可为第三方库单独降噪如urllib3、requests、matplotlib均设为WARNING这与错误日志分离配合能进一步保证error.log只包含业务相关的有效告警。五、app/Web 侧实现app/core/logging_config.pyTradingAgents-CN 的 FastAPI 后端app目录采用另一套基于logging.config.dictConfig的日志装配方案位于 app/core/logging_config.py。该模块同样完整支持错误日志分离且经历了专门的修复详见 docs/bugfix/2025-10-27-app-error-logging-fix.md修复前app目录日志缺少error_file处理器导致 webapi/worker 的错误无法统一收集到error.log。5.1 TOML 读取与 dictConfig 构建setup_logging()优先通过 resolve_logging_cfg_path() 选择配置文件Docker 环境或LOGGING_PROFILEdocker时使用config/logging_docker.toml否则使用config/logging.toml解析后动态构建 dictConfiglogging_config.py# 错误日志文件 error_handler_cfg handlers_cfg.get(error, {}) error_log error_handler_cfg.get(filename, str(Path(file_dir) / error.log)) error_enabled error_handler_cfg.get(enabled, True) error_level error_handler_cfg.get(level, WARNING) error_max_bytes _parse_size(error_handler_cfg.get(max_size, 100MB)) error_backup_count int(error_handler_cfg.get(backup_count, 5))# 添加错误日志处理器如果启用 if error_enabled: handlers_config[error_file] { class: logging.handlers.RotatingFileHandler, formatter: json_file_fmt if use_json_file else file_fmt, level: error_level, filename: error_log, maxBytes: error_max_bytes, backupCount: error_backup_count, encoding: utf-8, filters: [request_context], }5.2 Logger 到 Handler 的挂载关系dictConfig 中tradingagents、webapi、worker、uvicorn、fastapi等 Logger 均挂载了error_file处理器logging_config.py日志器处理器输出文件级别webapiconsole / file / error_filestdout / webapi.log / error.logINFO / DEBUG / WARNINGworkerconsole / worker_file / error_filestdout / worker.log / error.logDEBUG / DEBUG / WARNINGuvicornconsole / file / error_filestdout / webapi.log / error.logINFO / DEBUG / WARNINGfastapiconsole / file / error_filestdout / webapi.log / error.logINFO / DEBUG / WARNING5.3 内置兜底配置当 TOML 加载失败时setup_logging()回退到内置 dictConfiglogging_config.py其中同样包含error_file处理器logs/error.logWARNING 级别10MB × 5 备份。另外在 Windows 平台会优先使用concurrent_log_handler.ConcurrentRotatingFileHandler避免文件占用导致的轮转失败logging_config.py。5.4 其他关键细节trace_id 关联无论 console 还是 file 格式若格式串未显式包含%(trace_id)ssetup_logging()会自动追加trace%(trace_id)slogging_config.py便于按请求链路追踪错误JSON 文件日志[logging.format] file_json true时文件 Handler含 error_file改用SimpleJsonFormatter输出 JSON 行logging_config.py方便日志采集系统解析Docker 环境config/logging_docker.toml中 error 处理器同样启用级别WARNING、max_size 100MB、路径为/app/logs/error.log且docker.stdout_only false同时输出到文件与 stdout。六、使用效果日志文件结构与示例6.1 日志文件结构启用后logs/目录结构如下logs/ ├── tradingagents.log # 所有级别的日志 ├── tradingagents.log.1 # 轮转备份 ├── tradingagents.log.2 ├── ... ├── error.log # 只有WARNING及以上级别 ├── error.log.1 # 轮转备份 ├── error.log.2 └── ...在 Web 后端场景下还会额外出现webapi.log、worker.log等按服务拆分的主日志文件而error.log是所有 Logger 共享的统一错误汇聚文件。6.2 示例日志内容对比tradingagents.log含全部级别来自数据源切换的真实场景2025-10-13 08:21:08,199 | dataflows | INFO | interface:get_china_stock_data_unified:1180 | [统一数据接口] 分析股票: 600519 2025-10-13 08:21:08,205 | dataflows | WARNING | data_source_manager:get_stock_data:461 | ⚠️ [数据来源: MongoDB] 未找到daily数据: 600519 2025-10-13 08:21:08,206 | dataflows | ERROR | data_source_manager:get_stock_data:512 | mongodb失败尝试备用数据源获取daily数据... 2025-10-13 08:21:08,207 | dataflows | INFO | data_source_manager:get_stock_data:520 | 尝试备用数据源获取daily数据: akshareerror.log只有 WARNING 及以上INFO 行被过滤2025-10-13 08:21:08,205 | dataflows | WARNING | data_source_manager:get_stock_data:461 | ⚠️ [数据来源: MongoDB] 未找到daily数据: 600519 2025-10-13 08:21:08,206 | dataflows | ERROR | data_source_manager:get_stock_data:512 | mongodb失败尝试备用数据源获取daily数据...可以看到一次 MongoDB 数据源失败、切换到 akshare 的完整故障链路在error.log中仅保留两行关键告警定位效率大幅提升。七、配置选项按需调整错误日志行为7.1 启用 / 禁用[logging.handlers.error] enabled false # 设置为false禁用错误日志7.2 调整记录级别[logging.handlers.error] level ERROR # 只记录ERROR和CRITICAL不记录WARNING7.3 调整文件大小与备份数量[logging.handlers.error] max_size 20MB # 单个文件最大20MB backup_count 10 # 保留10个备份文件7.4 自定义文件名与路径[logging.handlers.error] directory ./logs/errors # 自定义目录 filename warnings_and_errors.log # 自定义文件名八、技术细节轮转机制、格式与性能8.1 日志轮转机制两套实现logging_manager 与 logging_config均使用 Python 标准库的logging.handlers.RotatingFileHandler按大小轮转文件达到max_size时自动轮转备份管理保留backup_count个备份文件命名规则为error.log.1、error.log.2…自动清理超过备份数量的最旧文件自动删除。轮转示例backup_count 5error.log (当前文件10MB) error.log.1 (第1个备份10MB) error.log.2 (第2个备份10MB) error.log.3 (第3个备份10MB) error.log.4 (第4个备份10MB) error.log.5 (第5个备份10MB最旧的会被删除)8.2 日志格式错误日志复用主日志的文件格式串包含时间、Logger 名、级别、源码定位四要素%(asctime)s | %(name)-20s | %(levelname)-8s | %(module)s:%(funcName)s:%(lineno)d | %(message)s示例2025-10-13 08:21:08,205 | dataflows | WARNING | data_source_manager:get_stock_data:461 | ⚠️ [数据来源: MongoDB] 未找到daily数据: 600519%(module)s:%(funcName)s:%(lineno)d提供了精确的源码定位模块、函数、行号配合docs/bugfix/2025-10-27-app-error-logging-fix.md中的修复记录可以快速回溯到对应代码路径。8.3 性能影响从实现看增加错误处理器带来的开销非常有限磁盘 I/O多一个文件处理器但仅写入 WARNING 及以上级别低频、高价值影响很小内存占用每个 Handler 仅占用数 KB可忽略不计CPU 开销格式串复用 标准库轮转格式化与写入开销微乎其微。九、最佳实践监控、告警与分析9.1 实时监控tail -f logs/error.log9.2 定期巡检建议每天检查一次error.log结合轮转备份统计趋势及时发现并解决累积性问题。9.3 告警触发可用 Prometheus Alertmanager 等监控工具观察error.log增长速率例如统计最近 1 小时错误数量# 统计最近1小时的错误数量 tail -n 1000 logs/error.log | grep $(date -d 1 hour ago %Y-%m-%d %H) | wc -l9.4 错误类型与模块分布分析# 统计各类错误的数量 grep ERROR logs/error.log | awk -F| {print $5} | sort | uniq -c | sort -rn # 统计各模块的错误数量 grep ERROR logs/error.log | awk -F| {print $2} | sort | uniq -c | sort -rn十、验证与测试仓库提供了针对 app 侧错误日志配置的自动化验证脚本 tests/test_app_error_logging.py覆盖三类断言TOML 配置测试调用setup_logging(log_levelINFO)后检查webapi/workerLogger 是否挂载了指向error.log的处理器并核对maxBytes、backupCount、level错误日志功能测试分别写入 DEBUG / INFO / WARNING / ERROR / CRITICAL 级别的日志验证 error.log 中只出现 WARNING 及以上条目日志器验证确认 webapi 与 worker 的处理器挂载与级别设置正确。运行方式python tests/test_app_error_logging.py十一、总结修改内容一览✅ 在 tradingagents/utils/logging_manager.py 中新增_add_error_handler()方法✅ 在_setup_logging()中挂载错误处理器✅ 更新默认配置含 error 处理器节与兜底配置✅ 在 config/logging.toml 与 config/logging_docker.toml 中新增[logging.handlers.error]配置节✅ 在 app/core/logging_config.py 的 dictConfig 方案中同步支持error_file处理器含 Docker 路径error.log。修改效果✅ WARNING、ERROR、CRITICAL 日志单独输出到error.log✅tradingagents.log/webapi.log/worker.log仍记录完整日志向后兼容✅ 支持通过配置文件自定义级别、大小、备份数与路径✅ 支持按大小自动轮转与备份清理✅ 提供内置兜底配置与环境变量驱动TRADINGAGENTS_LOG_LEVEL、TRADINGAGENTS_LOG_DIR配置缺失不中断启动。后续演进方向接入日志监控与告警系统如 Prometheus Alertmanager引入日志分析与可视化工具统计错误频率与类型分布制定日志归档与清理策略控制长期磁盘占用默认或按需启用结构化 JSON 日志structured.enabled true/file_json true为采集与检索系统提供机器可读格式。【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 TradingAgents-CN 错误日志分离实战：双文件处理器架构与 error.log 配置全解析
TradingAgents-CN 错误日志分离实战双文件处理器架构与 error.log 配置全解析【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN在 TradingAgents-CN 这类多智能体金融交易框架中日志是排查问题、监控告警的核心抓手。本指南以仓库内 错误日志分离功能文档 为主线完整讲解该项目将 WARNING 及以上级别日志单独输出到error.log的实现方案——包括tradingagents与app两个目录的处理器实现、config/logging.toml配置参数逐项说明、日志轮转机制以及基于真实源码与测试用例的运维最佳实践。读完本文你将掌握如何在本项目中配置、启用、监控与二次调整错误日志分离从而快速定位数据源切换、LLM 调用等高频异常。一、需求背景为什么要把错误日志单独分离在实施分离之前项目的 WARNING、ERROR、CRITICAL 级别日志与普通日志全部混写在tradingagents.log中。多智能体交易系统一天会产生大量 INFO 级日志股票分析、Token 消耗、模块流转等运维人员排查问题时需要在海量日志中反复grep效率低下且容易遗漏关键错误。该功能的核心需求有三点将WARNING、ERROR、CRITICAL三个级别的日志单独输出到error.log保持原有tradingagents.log记录所有级别日志不影响完整追踪与调试便于快速定位、实时监控与告警减少监控系统噪音。二、架构设计双文件处理器方案方案采用标准的 Pythonlogging双 Handler 结构同一份日志记录被多个处理器按各自级别阈值分流主日志文件tradingagents.log记录全部级别DEBUG、INFO、WARNING、ERROR、CRITICAL承担完整日志追踪职责错误日志文件error.log只记录 WARNING 及以上级别承担快速定位与监控告警职责。日志级别分流对照级别说明tradingagents.logerror.logDEBUG调试信息✅❌INFO一般信息✅❌WARNING警告信息✅✅ERROR错误信息✅✅CRITICAL严重错误✅✅从源码结构看这套一份记录、多处理器按级别过滤的机制是 Python 标准库logging的天然能力Handler.setLevel()决定单个处理器接收的最低级别而根 Logger 的级别决定记录能否进入分发流程。项目在 tradingagents/utils/logging_manager.py 的_setup_logging()中依次挂载 console、file、error、structured 四个处理器正是这一机制的完整落地。三、tradingagents 侧实现logging_manager.py 核心剖析tradingagents目录核心交易分析逻辑的日志由 tradingagents/utils/logging_manager.py 统一管理。3.1 在设置流程中挂载错误处理器_setup_logging()中错误处理器与文件处理器一起被挂载logging_manager.py# 添加处理器 self._add_console_handler(root_logger) if not self.config[docker][enabled] or not self.config[docker][stdout_only]: self._add_file_handler(root_logger) self._add_error_handler(root_logger) # 添加错误日志处理器 if self.config[handlers][structured][enabled]: self._add_structured_handler(root_logger)注意这里的 Docker 条件判断当docker.enabled为真且docker.stdout_only为真时不挂载任何文件处理器包括错误处理器日志只走 stdout。这是容器环境下避免日志文件失控的设计。3.2 _add_error_handler() 方法实现该方法logging_manager.py是错误日志分离的核心def _add_error_handler(self, logger: logging.Logger): 添加错误日志处理器只记录WARNING及以上级别 # 检查错误处理器是否启用 error_config self.config[handlers].get(error, {}) if not error_config.get(enabled, True): return log_dir Path(error_config.get(directory, self.config[handlers][file][directory])) error_log_file log_dir / error_config.get(filename, error.log) # 使用RotatingFileHandler进行日志轮转 max_size self._parse_size(error_config.get(max_size, 10MB)) backup_count error_config.get(backup_count, 5) error_handler logging.handlers.RotatingFileHandler( error_log_file, maxBytesmax_size, backupCountbackup_count, encodingutf-8 ) # 只记录WARNING及以上级别WARNING, ERROR, CRITICAL error_level getattr(logging, error_config.get(level, WARNING)) error_handler.setLevel(error_level) formatter logging.Formatter(self.config[format][file]) error_handler.setFormatter(formatter) logger.addHandler(error_handler)关键设计点默认值与容错enabled缺省为Truedirectory缺省继承handlers.file.directoryfilename缺省为error.log——即使配置节不完整也不会报错编码固定encodingutf-8保证中文日志本项目大量使用中文与 emoji 标识不乱码级别过滤通过error_handler.setLevel(error_level)实现默认为WARNING格式复用复用format.file格式串与主日志保持一致的解析格式。3.3 默认配置中的 error 处理器当配置文件加载失败或未提供配置时_load_default_config()提供内置兜底配置logging_manager.pyerror: { enabled: True, level: WARNING, # 只记录WARNING及以上级别 max_size: 10MB, backup_count: 5, directory: log_dir, filename: error.log },log_dir来自环境变量TRADINGAGENTS_LOG_DIR默认./logs根级别来自TRADINGAGENTS_LOG_LEVEL默认INFO。这意味着即便不写任何配置文件仅靠环境变量也能驱动整套双文件日志方案。四、配置文件详解config/logging.toml 逐项说明项目日志配置以 TOML 形式存放于 config/logging.toml加载与格式转换逻辑见 logging_manager.py 的_load_config_file()/_convert_toml_config()按config/logging_docker.toml→config/logging.toml→./logging.toml顺序查找。4.1 错误处理器配置节# 错误日志处理器只记录WARNING及以上级别 [logging.handlers.error] enabled true level WARNING # 只记录WARNING, ERROR, CRITICAL max_size 10MB backup_count 5 directory ./logs filename error.log4.2 参数速查表参数默认值取值范围/说明enabledtruetrue/false控制错误处理器是否挂载levelWARNINGDEBUG/INFO/WARNING/ERROR/CRITICAL决定 error.log 记录的最低级别max_size10MB支持KB/MB/GB后缀解析逻辑见 logging_manager.py 的_parse_size()也支持纯数字字节backup_count5保留的轮转备份文件数量超出自动删除最旧文件directory./logs日志目录缺省时继承handlers.file.directoryfilenameerror.log错误日志文件名可自定义4.3 与其他处理器协同同一份配置中还定义了 console、file、structured 处理器与各命名 Logger 的级别# 文件处理器 [logging.handlers.file] enabled true level DEBUG # 主日志记录全部级别 max_size 10MB backup_count 5 directory ./logs # 结构化日志处理器JSON格式 [logging.handlers.structured] enabled false # 默认关闭生产环境可启用 level INFO directory ./logs[logging.loggers]节可为第三方库单独降噪如urllib3、requests、matplotlib均设为WARNING这与错误日志分离配合能进一步保证error.log只包含业务相关的有效告警。五、app/Web 侧实现app/core/logging_config.pyTradingAgents-CN 的 FastAPI 后端app目录采用另一套基于logging.config.dictConfig的日志装配方案位于 app/core/logging_config.py。该模块同样完整支持错误日志分离且经历了专门的修复详见 docs/bugfix/2025-10-27-app-error-logging-fix.md修复前app目录日志缺少error_file处理器导致 webapi/worker 的错误无法统一收集到error.log。5.1 TOML 读取与 dictConfig 构建setup_logging()优先通过 resolve_logging_cfg_path() 选择配置文件Docker 环境或LOGGING_PROFILEdocker时使用config/logging_docker.toml否则使用config/logging.toml解析后动态构建 dictConfiglogging_config.py# 错误日志文件 error_handler_cfg handlers_cfg.get(error, {}) error_log error_handler_cfg.get(filename, str(Path(file_dir) / error.log)) error_enabled error_handler_cfg.get(enabled, True) error_level error_handler_cfg.get(level, WARNING) error_max_bytes _parse_size(error_handler_cfg.get(max_size, 100MB)) error_backup_count int(error_handler_cfg.get(backup_count, 5))# 添加错误日志处理器如果启用 if error_enabled: handlers_config[error_file] { class: logging.handlers.RotatingFileHandler, formatter: json_file_fmt if use_json_file else file_fmt, level: error_level, filename: error_log, maxBytes: error_max_bytes, backupCount: error_backup_count, encoding: utf-8, filters: [request_context], }5.2 Logger 到 Handler 的挂载关系dictConfig 中tradingagents、webapi、worker、uvicorn、fastapi等 Logger 均挂载了error_file处理器logging_config.py日志器处理器输出文件级别webapiconsole / file / error_filestdout / webapi.log / error.logINFO / DEBUG / WARNINGworkerconsole / worker_file / error_filestdout / worker.log / error.logDEBUG / DEBUG / WARNINGuvicornconsole / file / error_filestdout / webapi.log / error.logINFO / DEBUG / WARNINGfastapiconsole / file / error_filestdout / webapi.log / error.logINFO / DEBUG / WARNING5.3 内置兜底配置当 TOML 加载失败时setup_logging()回退到内置 dictConfiglogging_config.py其中同样包含error_file处理器logs/error.logWARNING 级别10MB × 5 备份。另外在 Windows 平台会优先使用concurrent_log_handler.ConcurrentRotatingFileHandler避免文件占用导致的轮转失败logging_config.py。5.4 其他关键细节trace_id 关联无论 console 还是 file 格式若格式串未显式包含%(trace_id)ssetup_logging()会自动追加trace%(trace_id)slogging_config.py便于按请求链路追踪错误JSON 文件日志[logging.format] file_json true时文件 Handler含 error_file改用SimpleJsonFormatter输出 JSON 行logging_config.py方便日志采集系统解析Docker 环境config/logging_docker.toml中 error 处理器同样启用级别WARNING、max_size 100MB、路径为/app/logs/error.log且docker.stdout_only false同时输出到文件与 stdout。六、使用效果日志文件结构与示例6.1 日志文件结构启用后logs/目录结构如下logs/ ├── tradingagents.log # 所有级别的日志 ├── tradingagents.log.1 # 轮转备份 ├── tradingagents.log.2 ├── ... ├── error.log # 只有WARNING及以上级别 ├── error.log.1 # 轮转备份 ├── error.log.2 └── ...在 Web 后端场景下还会额外出现webapi.log、worker.log等按服务拆分的主日志文件而error.log是所有 Logger 共享的统一错误汇聚文件。6.2 示例日志内容对比tradingagents.log含全部级别来自数据源切换的真实场景2025-10-13 08:21:08,199 | dataflows | INFO | interface:get_china_stock_data_unified:1180 | [统一数据接口] 分析股票: 600519 2025-10-13 08:21:08,205 | dataflows | WARNING | data_source_manager:get_stock_data:461 | ⚠️ [数据来源: MongoDB] 未找到daily数据: 600519 2025-10-13 08:21:08,206 | dataflows | ERROR | data_source_manager:get_stock_data:512 | mongodb失败尝试备用数据源获取daily数据... 2025-10-13 08:21:08,207 | dataflows | INFO | data_source_manager:get_stock_data:520 | 尝试备用数据源获取daily数据: akshareerror.log只有 WARNING 及以上INFO 行被过滤2025-10-13 08:21:08,205 | dataflows | WARNING | data_source_manager:get_stock_data:461 | ⚠️ [数据来源: MongoDB] 未找到daily数据: 600519 2025-10-13 08:21:08,206 | dataflows | ERROR | data_source_manager:get_stock_data:512 | mongodb失败尝试备用数据源获取daily数据...可以看到一次 MongoDB 数据源失败、切换到 akshare 的完整故障链路在error.log中仅保留两行关键告警定位效率大幅提升。七、配置选项按需调整错误日志行为7.1 启用 / 禁用[logging.handlers.error] enabled false # 设置为false禁用错误日志7.2 调整记录级别[logging.handlers.error] level ERROR # 只记录ERROR和CRITICAL不记录WARNING7.3 调整文件大小与备份数量[logging.handlers.error] max_size 20MB # 单个文件最大20MB backup_count 10 # 保留10个备份文件7.4 自定义文件名与路径[logging.handlers.error] directory ./logs/errors # 自定义目录 filename warnings_and_errors.log # 自定义文件名八、技术细节轮转机制、格式与性能8.1 日志轮转机制两套实现logging_manager 与 logging_config均使用 Python 标准库的logging.handlers.RotatingFileHandler按大小轮转文件达到max_size时自动轮转备份管理保留backup_count个备份文件命名规则为error.log.1、error.log.2…自动清理超过备份数量的最旧文件自动删除。轮转示例backup_count 5error.log (当前文件10MB) error.log.1 (第1个备份10MB) error.log.2 (第2个备份10MB) error.log.3 (第3个备份10MB) error.log.4 (第4个备份10MB) error.log.5 (第5个备份10MB最旧的会被删除)8.2 日志格式错误日志复用主日志的文件格式串包含时间、Logger 名、级别、源码定位四要素%(asctime)s | %(name)-20s | %(levelname)-8s | %(module)s:%(funcName)s:%(lineno)d | %(message)s示例2025-10-13 08:21:08,205 | dataflows | WARNING | data_source_manager:get_stock_data:461 | ⚠️ [数据来源: MongoDB] 未找到daily数据: 600519%(module)s:%(funcName)s:%(lineno)d提供了精确的源码定位模块、函数、行号配合docs/bugfix/2025-10-27-app-error-logging-fix.md中的修复记录可以快速回溯到对应代码路径。8.3 性能影响从实现看增加错误处理器带来的开销非常有限磁盘 I/O多一个文件处理器但仅写入 WARNING 及以上级别低频、高价值影响很小内存占用每个 Handler 仅占用数 KB可忽略不计CPU 开销格式串复用 标准库轮转格式化与写入开销微乎其微。九、最佳实践监控、告警与分析9.1 实时监控tail -f logs/error.log9.2 定期巡检建议每天检查一次error.log结合轮转备份统计趋势及时发现并解决累积性问题。9.3 告警触发可用 Prometheus Alertmanager 等监控工具观察error.log增长速率例如统计最近 1 小时错误数量# 统计最近1小时的错误数量 tail -n 1000 logs/error.log | grep $(date -d 1 hour ago %Y-%m-%d %H) | wc -l9.4 错误类型与模块分布分析# 统计各类错误的数量 grep ERROR logs/error.log | awk -F| {print $5} | sort | uniq -c | sort -rn # 统计各模块的错误数量 grep ERROR logs/error.log | awk -F| {print $2} | sort | uniq -c | sort -rn十、验证与测试仓库提供了针对 app 侧错误日志配置的自动化验证脚本 tests/test_app_error_logging.py覆盖三类断言TOML 配置测试调用setup_logging(log_levelINFO)后检查webapi/workerLogger 是否挂载了指向error.log的处理器并核对maxBytes、backupCount、level错误日志功能测试分别写入 DEBUG / INFO / WARNING / ERROR / CRITICAL 级别的日志验证 error.log 中只出现 WARNING 及以上条目日志器验证确认 webapi 与 worker 的处理器挂载与级别设置正确。运行方式python tests/test_app_error_logging.py十一、总结修改内容一览✅ 在 tradingagents/utils/logging_manager.py 中新增_add_error_handler()方法✅ 在_setup_logging()中挂载错误处理器✅ 更新默认配置含 error 处理器节与兜底配置✅ 在 config/logging.toml 与 config/logging_docker.toml 中新增[logging.handlers.error]配置节✅ 在 app/core/logging_config.py 的 dictConfig 方案中同步支持error_file处理器含 Docker 路径error.log。修改效果✅ WARNING、ERROR、CRITICAL 日志单独输出到error.log✅tradingagents.log/webapi.log/worker.log仍记录完整日志向后兼容✅ 支持通过配置文件自定义级别、大小、备份数与路径✅ 支持按大小自动轮转与备份清理✅ 提供内置兜底配置与环境变量驱动TRADINGAGENTS_LOG_LEVEL、TRADINGAGENTS_LOG_DIR配置缺失不中断启动。后续演进方向接入日志监控与告警系统如 Prometheus Alertmanager引入日志分析与可视化工具统计错误频率与类型分布制定日志归档与清理策略控制长期磁盘占用默认或按需启用结构化 JSON 日志structured.enabled true/file_json true为采集与检索系统提供机器可读格式。【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考