logging.getLogger() 总返回同一实例,因模块用字典缓存logger名称;子logger自动继承父级handler和level,但propagate=True易致重复输出;多进程需避免共用FileHandler,推荐独立文件或QueueHandler;JSON日志需预处理字段并确保换行。
因为 Python 的 logging 模块内部用字典缓存了所有已创建的 logger 实例,键是 logger 名称。调用 logging.getLogger("a.b.c") 时,如果该名称已存在,就直接返回缓存对象;不存在才新建并缓存。
这导致两个常见误解:
getLogger() 会新建 logger —— 实际不会,配置需在首次获取后统一设置getLogger("a.b.c"))自动继承父 logger("a" 或 "a.b")的 handler 和 level,但 propagate=True 是默认行为,容易造成日志重复输出logger = logging.getLogger(__name__),这是推荐做法,能天然形成层级结构,但必须确保根 logger 或上级 logger 已配置 handler,否则日志“发出去却没人收”FileHandler 或 RotatingFileHandler 在目录不存在、权限不足、磁盘满等情况下,通常静默失败——日志不写入,也不抛异常,只在内部记录一次 warning 到 logging.lastResort(一个默认的 StreamHandler),而这个 lastResort 默认只在 root logger 未配置 handler 时启用,且输出到 stderr,很容易被忽略。
排查建议:
os.path.isdir(os.path.dirname(log_path)) and os.access(os.path.dirname(log_path), os.W_OK)
try: handler = RotatingFileHandler(...) except OSError as e: print(f"Handler init failed: {e}")
lastResort,始终为 root 或关键 logger 显式添加至少一个可用 handler(如 StreamHandler(sys.stderr))标准 FileHandler 不支持多进程并发写入,直接共用会导致内容错乱或丢失。Python 官方不提供跨进程安全的内置 handler,必须绕开或封装。
可行方案:
app.log.12345,后续用 logrotate 或脚本合并分析QueueHandler + 单独日志进程:主进程将日志 record 发送到 multiprocessing.Queue,由唯一消费者进程用 FileHandler 写入,避免竞争syslog(SysLogHandler)、redis、或 fluentd 等,把并发压力交给中间件FileHandler 实例,即使加锁也难保底层 OS write 调用的原子性想让每行日志是合法 JSON(便于 ELK、Loki 解析),不能只靠重写 Formatter.format() —— 因为 LogRecord 中的 exc_info、stack_info 是元组或字符串,直接 json.dumps() 会失败;且默认字段(如 asctime、funcName)可能含不可序列化对象或特殊字符。
稳妥方式:
logging.Formatter,在 format() 中预处理:把 record.exc_text(已格式化的异常字符串)加入 dict,跳过 record.exc_info 原始元组str(getattr(record, 'asctime', ''))、record.levelname or 'UNKNOWN'
traceback.format_exc() 等耗时操
makeRecord() 或日志产生侧完成python-json-logger),注意其默认不处理 extra 中的嵌套 dict 或 datetime 对象,仍需自定义 json_default 函数最易被忽略的一点:日志行末尾必须有换行符,否则多条 JSON 日志会粘连成非法格式——json.dumps(...)+ '\n' 是必须的。