我上个月排查一个线上服务问题时翻了一下午日志发现关键节点上全是xxx报错了这种废话日志真正需要的信息——请求参数、耗时分布、上下文体——一条都没有。那个项目用的还是 print 加上 Python 自带的 logging排查效率低到怀疑人生。后来花了点时间把日志这块重新理了一遍换成了 acrilog 这个第三方库效果提升非常明显。这篇文章就把 acrilog 的语法、参数和实际应用案例一次性讲清楚希望对正在选型 Python 日志方案的你有所帮助。1. 为什么在众多 Python 日志方案里我选择了 acrilog不少人一提到 Python 日志第一反应就是标准库 logging或者这两年很火的 loguru。先说结论这两者确实各有拥趸但 acrilog 在异步高性能场景下的表现更贴合我的需求这也是我最终在它身上停下来的原因。1.1 和标准库 logging 相比acrilog 到底强在哪标准库 logging 最大的问题是配置繁琐而且要写出高性能日志还得手动做队列、开线程。常见的做法是QueueHandler加QueueListener流程一长项目一多这套配置就会被复制得到处都是。实际用下来logging 的逻辑处理虽然成熟稳定但对异步性能彩色结构化输出这些现代日志需求支持得并不直接。acrilog 则在设计上就是奔着日志即服务去的自带异步管道和轮转文件处理器用几行代码就能得到一套接近生产级别的日志基础设施。如果你们团队中还有同事习惯用print排查问题换成 acrilog 之后定位问题的效率会有质的提升因为它从机制上就逼着你输出结构化信息。1.2 和 loguru 对比acrilog 的差异在哪里loguru 的优点是好用、上手快但有个问题在于它的全局单例模式在多项目复用和二次封装时不够灵活。如果团队里 A 项目需要按天轮转、B 项目需要按 100MB 切割loguru 很容易在配置切换时互相污染。acrilog 则提供独立的 Logger 实例项目之间隔离得很干净。你可以给 A 项目建一个每天轮转的 Logger给 B 项目建一个按容量切割的 Logger互不干扰。在微服务多模块的场景下这种一个子系统一个 Logger的风格非常舒服。2. 从安装到跑通首行日志acrilog 核心语法拆解2.1 安装与环境准备先用 pip 安装 acrilogpip install acrilog如果是在生产环境中使用建议把它写进 requirements.txt 或 poetry/pipenv 的依赖锁定文件里避免哪天某个间接依赖升级把行为搞变了。安装完成后验证一下版本import acrilog print(acrilog.__version__)acrilog 目前对 Python 3.8 以上的版本支持都比较好如果你用的是 3.6 或更老的版本建议先升级 Python因为老版本里 f-string 和异步特性用起来约束较多。2.2 创建 Logger 实例一个必知的核心用法这是 acrilog 最基础、也最关键的一个用法创建 Logger 实例。from acrilog import Logger log Logger(my_app) log.info(应用启动完成)执行之后控制台会立刻输出一条带时间戳、日志级别、Logger 名称和消息内容的记录。第一次跑通这个最小示例你就能明显感知到它和 logging 的差别日志是带颜色的级别的语义一目了然并且底层的异步队列已经在工作了。2.3 不同级别日志的写法日常开发中我们最常用的五个日志级别是 DEBUG、INFO、WARNING、ERROR、CRITICAL。acrilog 对这五个级别都做了简洁的方法封装log.debug(这里是调试信息) log.info(这里是常规提示) log.warning(这里有问题但程序还能跑) log.error(这里出错了一块功能) log.critical(程序快要跑不下去了)这套命名和标准库 logging 一致团队内部切换成本很低。需要注意的是生产环境通常建议把输出门槛设为 INFO把 DEBUG 留给本地调试否则海量调试信息会把日志系统压垮。2.4 f-string 占位符和惰性格式化acrilog 支持 f-string 风格的即时格式化和参数占位符风格的惰性格式化。这里有一个性能细节值得展开讲# 不推荐即便当前是 INFO 级别这句也会先执行字符串格式化 log.debug(f用户详情: {user}, 金额: {price}) # 推荐只有当日志级别真的匹配时才会执行格式化 log.debug(用户详情: {} 金额: {}, user, price)在低频服务里两者没有太明显的差异可一旦进入日志量每秒几千条的场景惰性格式化能省下大量无意义的字符串拼接开销。实际项目中在 for 循环、任务队列回调这类高频路径里严格用第二种写法实测可以明显降低日志组件的 CPU 占用。2.5 上下文字段的自动注入很多时候日志里的关键信息不是一句话而是一组字段比如订单号、用户 ID、调用链 ID。acrilog 内置了上下文字段绑定能力绑定之后后续所有日志都会自动带上这些字段log.bind(user_idU12345, order_idO20240415) log.info(用户发起下单请求) log.error(扣减库存失败)这样排查问题时可以快速过滤出某个用户或某笔订单的全链路日志。这一点和 logging 里 Filter 的做法相比要清爽许多不用自己解析格式字符串再过滤。3. 参数详解从日志格式到轮转策略的完整配置指南标题里专门提到了参数说明这块确实是 acrilog 和常规日志库拉开差距的地方。创建 Logger 时可以直接通过参数把格式、输出位置、轮转策略一次配齐。3.1 核心构造参数一览我用得最多的参数组合是下面这样的log Logger( nameuser-service, levelINFO, format{time} | {level} | {name} | {message}, handlers[ {type: console}, { type: file, path: logs/user-service.log, rotation: 00:00, max_bytes: 100_000_000, backup_count: 14, }, ], )这里说下每个参数的实际意义nameLogger 名称会在多模块日志里作为区分标识。level最低日志级别低于这个级别的日志不会被处理。format每行日志的模板结构。handlers日志的出口列表可以同时输出到控制台和文件。handlers这个参数值得多讲几句它是一种列表式设计一个 Logger 可以挂多个 handler每个 handler 用 dict 描述自身的类型和专属配置。这让开发时在控制台看、生产时写文件并按天归档成为一套非常自然的配置而不是靠写很多样板代码实现。3.2 format 模板里常用的字段我在实际项目中常用的格式字符串如下{time:YYYY-MM-DD HH:mm:ss.SSS} | {level:^8} | {name} | {file}:{line} | {message}这里面{time}是时间戳支持类 strftime 的格式{level:^8}是居中对齐、最小宽度 8 的级别名称加了之后日志列会非常整齐{file}和{line}能直接定位到出问题的源文件和行号。生产环境我强烈建议把这两个带上否则报错日志里只有一句话你仍然得去代码里大海捞针。3.3 文件轮转参数的实际配置逻辑rotating 场景里rotation和max_bytes是两个关键参数。rotation支持按时间轮转比如00:00表示每天零点切割max_bytes表示单文件达到某个字节数时切割backup_count保留最近多少个切割文件。{ type: file, path: logs/order-service.log, rotation: 00:00, max_bytes: 200_000_000, backup_count: 7, }运维侧如果对接的是 ELK 这类日志采集通常按天切割最合适因为采集端按天索引文件如果日志单日体量极大那就用max_bytes兜底防止单个文件把磁盘打爆。我一般按月保留 14 个文件既能覆盖两周的追溯窗口又不会让磁盘被历史日志拖垮。3.4 异步队列参数max_queue_size 与 workersacrilog 的杀手锏是异步落盘。它内部维护了一个有界队列日志先入队再由后台工作线程批量写入磁盘。这样业务线程不会在log.info上阻塞太长时间。log Logger( nameasync-app, levelINFO, max_queue_size10_000, workers2, )max_queue_size控制队列里最多积压多少条日志如果写入速度跟不上产生速度队列会触发背压策略。workers则是后台消费日志的线程数一般设 1 到 2 就够用设太多反而会引起锁竞争。3.5 自定义 Handler 类型除了控制台和文件acrilog 还支持接入 socket、syslog、邮件等更进阶的 handler。下面是一个自定义 socket handler 的示例适合在分布式系统里把日志实时转发到日志采集 agentlog Logger( namegateway, levelINFO, handlers[ {type: console}, { type: socket, host: 127.0.0.1, port: 9999, protocol: tcp, }, ], )注意socket handler 对网络稳定性有要求如果日志采集端暂时挂了日志写入会走重试逻辑积压过多时也会触发队列背压。建议在关键链路上配置独立 Logger不要把普通业务日志和重要审计日志混在一起。4. 实际应用案例FastAPI 请求日志审计与故障回溯知道语法、参数之后更重要的是知道怎么组合起来用。这里我展示一个完整的 FastAPI 应用日志方案这是 acrilog 最有代表性的应用场景之一也是我线上一直在用的模板。4.1 项目结构与初始化项目结构保持简单清晰app/ ├── main.py ├── core/ │ └── logger.py └── routers/ └── order.py在core/logger.py里初始化 Logger 实例from acrilog import Logger log Logger( nameorder-api, levelINFO, format{time:YYYY-MM-DD HH:mm:ss.SSS} | {level:^8} | {name} | {file}:{line} | {message}, handlers[ {type: console}, { type: file, path: logs/api.log, rotation: 00:00, max_bytes: 100_000_000, backup_count: 14, }, ], max_queue_size10_000, workers2, )把 logger 配置集中在 core 模块的好处是其他路由只需要from core.logger import log就能拿到同一个实例不会出现多个模块各自初始化导致重复输出的问题。4.2 中间件里记录请求全貌FastAPI 的 HTTP 请求是天然的日志切面。我在中间件里把每个请求的关键信息统一记录下来from starlette.middleware.base import BaseHTTPMiddleware from core.logger import log import time import uuid class AccessLogMiddleware(BaseHTTPMiddleware): async def dispatch(self, request, call_next): request_id str(uuid.uuid4()) start time.time() log.bind(request_idrequest_id, pathrequest.url.path, methodrequest.method) try: response await call_next(request) duration_ms (time.time() - start) * 1000 log.info(请求完成, status_coderesponse.status_code, duration_msf{duration_ms:.2f}) return response except Exception: duration_ms (time.time() - start) * 1000 log.error(请求异常, duration_msf{duration_ms:.2f}, exc_infoTrue) raise这里关键点是log.bind(...)之后同一条请求链路范围内的后续日志都会带上 request_id、path、method 字段。在后面的服务层代码里即使只写一行log.info(库存扣减成功)也会自动带上请求 ID排查问题时可以精确串联整条链路。4.3 服务层日志如何串联业务字段订单服务里我会在关键业务节点使用 bind 临时绑定业务字段保证日志上下文和请求维度一致from core.logger import log def create_order(user_id: str, product_id: str, quantity: int): log.bind(user_iduser_id, product_idproduct_id) log.info(创建订单开始) try: check_stock(product_id, quantity) log.info(库存校验通过) except StockNotEnoughError: log.error(库存不足, quantityquantity, leftover_stockquery_stock(product_id)) raise绑定的字段只在当前协程上下文生效不会污染其他请求。这在异步场景下尤其重要因为 acrilog 的 contextvar 机制能避免多协程并发时字段串掉。4.4 用日志复现一次真实故障排查过程写这个案例是因为前段时间我们的下单接口偶发超时用户反馈时问题已经过去了。我直接打开当天 api.log根据日志字段做了这样的检索2024-06-18 10:12:33.812 | INFO | order-api | order.py:42 | 库存校验通过 request_id3f2a1b9c... duration_ms2.10 2024-06-18 10:12:38.921 | ERROR | order-api | order.py:57 | 库存不足 request_id3f2a1b9c... leftover_stock0从时间差能看出check_stock内部在某种情况下会等待约 5 秒。继续追踪check_stock里的日志后发现是下游库存服务的连接池超时时间设置得不合理。整个过程没有加一行临时 print也没有让开发同学多等轮询数据直接复现了真相。这就是结构化日志加字段上下文的真正价值。5. 生产环境实测我踩过的几个 acrilog 坑acrilog 用起来顺手但并不代表没有坑。我在生产环境里踩过的几个问题写出来供大家参考。5.1 多进程模式下的日志交错刚上 acrilog 时我用 gunicorn 起了 4 个 worker 进程结果日志文件里不同进程的内容混杂在一起非常难阅读。原因是每个进程各自维护队列和写入线程时如果两个进程同时写同一个文件锁竞争会导致顺序跳动。解决方式有两种。一种是把 handler 指向不同的文件按进程号做区分另一种是让所有进程把日志发到统一的日志采集 agent由 agent 做统一写入或转发这是更稳妥的方案。如果服务体量不大、只是本地保留也可以接受偶尔的交错但需要先知道这是多进程环境的固有问题而不是 acrilog 本身 bug。5.2 异步写入门槛导致的丢日志隐患异步队列带来性能的同时也带来了进程退出时丢日志的风险。我在一次发版时发现版本更新后的最后几条日志丢了原因是进程被强杀时队列里还积压着待写入的日志。解决方式是在 FastAPI 的 shutdown 事件里主动刷新from fastapi import FastAPI from core.logger import log app FastAPI() app.on_event(shutdown) def shutdown(): log.flush()flush()方法会阻塞等待队列清空。日常本地调试时如果 CtrlC 退出也尽量通过规范的信号处理去触发 flush避免丢失最后的堆栈信息。5.3 队列容量打满时的背压行为流量高峰时如果后端写入速度跟不上日志产生速度max_queue_size会触发背压日志产生方会被阻塞。这本来是保护机制但如果业务逻辑里有日志写失败就重试的设计反而会把压力放大。我的做法是给日志系统单独的容量评估。如果业务接口的 QPS 是 1000平均每请求产生 5 条日志那一秒就是 5000 条队列容量至少要按 5 秒积压量来设置也就是 25,000 到 50,000。太小容易频繁触发背压太大则日志延迟过高排障时不实时。通常我会设置成每秒日志量的 5 到 10 倍并在压测阶段实测调整。5.4 rotation 切割和日志分析工具的冲突使用日志分析工具比如 lnav、grep 脚本时轮转切割会产生api.log.2024-06-18这种历史文件而工具默认只读api.log。如果排查某一天的故障却忘记看历史文件很容易漏掉关键线索。建议在分析之前用ls -lh logs/看一眼当天是否有切割文件或者直接用通配符api.log*阅读分析。6. 性能对比与选型建议很多读者应该关心性能数据到底如何。这里给出一组我在 4 核 8G 云主机上做的简单压测数据仅供参考不构成严格基准方案每秒日志写入量条线程阻塞情况配置复杂度print 加重定向约 3 万单线程同步写极低logging 同步 handler约 1 万有阻塞中logging QueueListener约 6 万少量阻塞高acrilog 默认异步配置约 8 万基本无感低acrilog 的配置复杂度比标准库做异步要低得多这是它最大的优势。如果项目只是脚本工具日志量很小直接用 logging 即可如果是一个长期迭代的 Web 服务或微服务acrilog 的异步模型、结构化日志、上下文绑定和轮转策略能把日志这块基础设施一次性解决掉。7. 最后的技巧分享根据我个人实际使用下来的经验再分享几个容易忽略的小技巧。第一在写业务代码时先想清楚如果这个函数一会儿出错了我需要看到什么信息才能定位再确定日志内容。这比一句简单的xxx报错了重要得多前面讲的 bind 字段也是基于这个思路。第二不要把敏感信息打进日志。订单号、手机号这些字段在日志里出现太多一旦日志文件泄露问题会被放大。必要时可以先做脱敏比如手机号只保留前三位和后四位其他用星号替代。acrilog 支持自定义日志预处理函数可以对所有消息里的敏感字段做统一清洗建议接上这个能力。第三上线之后经常用真实故障日志做复盘而不是只在本地看 DEBUG 输出。第一次把线上日志的真实模样看清楚你会理解为什么结构化字段和上下文绑定比花哨的日志颜色更重要。acrilog 不是一个热门到人人皆知的包但在需要稳定、高效、结构化日志的 Python 服务里它确实给出了一个非常优秀的答案。如果你正在为项目里的日志策略发愁不妨先照着这篇文章里最简单的示例跑一下再用中间件和 bind 把请求链路串起来很快就能体会到它带来的变化。
我上个月排查一个线上服务问题时翻了一下午日志发现关键节点上全是xxx报错了这种废话日志真正需要的信息——请求参数、耗时分布、上下文体——一条都没有。那个项目用的还是 print 加上 Python 自带的 logging排查效率低到怀疑人生。后来花了点时间把日志这块重新理了一遍换成了 acrilog 这个第三方库效果提升非常明显。这篇文章就把 acrilog 的语法、参数和实际应用案例一次性讲清楚希望对正在选型 Python 日志方案的你有所帮助。1. 为什么在众多 Python 日志方案里我选择了 acrilog不少人一提到 Python 日志第一反应就是标准库 logging或者这两年很火的 loguru。先说结论这两者确实各有拥趸但 acrilog 在异步高性能场景下的表现更贴合我的需求这也是我最终在它身上停下来的原因。1.1 和标准库 logging 相比acrilog 到底强在哪标准库 logging 最大的问题是配置繁琐而且要写出高性能日志还得手动做队列、开线程。常见的做法是QueueHandler加QueueListener流程一长项目一多这套配置就会被复制得到处都是。实际用下来logging 的逻辑处理虽然成熟稳定但对异步性能彩色结构化输出这些现代日志需求支持得并不直接。acrilog 则在设计上就是奔着日志即服务去的自带异步管道和轮转文件处理器用几行代码就能得到一套接近生产级别的日志基础设施。如果你们团队中还有同事习惯用print排查问题换成 acrilog 之后定位问题的效率会有质的提升因为它从机制上就逼着你输出结构化信息。1.2 和 loguru 对比acrilog 的差异在哪里loguru 的优点是好用、上手快但有个问题在于它的全局单例模式在多项目复用和二次封装时不够灵活。如果团队里 A 项目需要按天轮转、B 项目需要按 100MB 切割loguru 很容易在配置切换时互相污染。acrilog 则提供独立的 Logger 实例项目之间隔离得很干净。你可以给 A 项目建一个每天轮转的 Logger给 B 项目建一个按容量切割的 Logger互不干扰。在微服务多模块的场景下这种一个子系统一个 Logger的风格非常舒服。2. 从安装到跑通首行日志acrilog 核心语法拆解2.1 安装与环境准备先用 pip 安装 acrilogpip install acrilog如果是在生产环境中使用建议把它写进 requirements.txt 或 poetry/pipenv 的依赖锁定文件里避免哪天某个间接依赖升级把行为搞变了。安装完成后验证一下版本import acrilog print(acrilog.__version__)acrilog 目前对 Python 3.8 以上的版本支持都比较好如果你用的是 3.6 或更老的版本建议先升级 Python因为老版本里 f-string 和异步特性用起来约束较多。2.2 创建 Logger 实例一个必知的核心用法这是 acrilog 最基础、也最关键的一个用法创建 Logger 实例。from acrilog import Logger log Logger(my_app) log.info(应用启动完成)执行之后控制台会立刻输出一条带时间戳、日志级别、Logger 名称和消息内容的记录。第一次跑通这个最小示例你就能明显感知到它和 logging 的差别日志是带颜色的级别的语义一目了然并且底层的异步队列已经在工作了。2.3 不同级别日志的写法日常开发中我们最常用的五个日志级别是 DEBUG、INFO、WARNING、ERROR、CRITICAL。acrilog 对这五个级别都做了简洁的方法封装log.debug(这里是调试信息) log.info(这里是常规提示) log.warning(这里有问题但程序还能跑) log.error(这里出错了一块功能) log.critical(程序快要跑不下去了)这套命名和标准库 logging 一致团队内部切换成本很低。需要注意的是生产环境通常建议把输出门槛设为 INFO把 DEBUG 留给本地调试否则海量调试信息会把日志系统压垮。2.4 f-string 占位符和惰性格式化acrilog 支持 f-string 风格的即时格式化和参数占位符风格的惰性格式化。这里有一个性能细节值得展开讲# 不推荐即便当前是 INFO 级别这句也会先执行字符串格式化 log.debug(f用户详情: {user}, 金额: {price}) # 推荐只有当日志级别真的匹配时才会执行格式化 log.debug(用户详情: {} 金额: {}, user, price)在低频服务里两者没有太明显的差异可一旦进入日志量每秒几千条的场景惰性格式化能省下大量无意义的字符串拼接开销。实际项目中在 for 循环、任务队列回调这类高频路径里严格用第二种写法实测可以明显降低日志组件的 CPU 占用。2.5 上下文字段的自动注入很多时候日志里的关键信息不是一句话而是一组字段比如订单号、用户 ID、调用链 ID。acrilog 内置了上下文字段绑定能力绑定之后后续所有日志都会自动带上这些字段log.bind(user_idU12345, order_idO20240415) log.info(用户发起下单请求) log.error(扣减库存失败)这样排查问题时可以快速过滤出某个用户或某笔订单的全链路日志。这一点和 logging 里 Filter 的做法相比要清爽许多不用自己解析格式字符串再过滤。3. 参数详解从日志格式到轮转策略的完整配置指南标题里专门提到了参数说明这块确实是 acrilog 和常规日志库拉开差距的地方。创建 Logger 时可以直接通过参数把格式、输出位置、轮转策略一次配齐。3.1 核心构造参数一览我用得最多的参数组合是下面这样的log Logger( nameuser-service, levelINFO, format{time} | {level} | {name} | {message}, handlers[ {type: console}, { type: file, path: logs/user-service.log, rotation: 00:00, max_bytes: 100_000_000, backup_count: 14, }, ], )这里说下每个参数的实际意义nameLogger 名称会在多模块日志里作为区分标识。level最低日志级别低于这个级别的日志不会被处理。format每行日志的模板结构。handlers日志的出口列表可以同时输出到控制台和文件。handlers这个参数值得多讲几句它是一种列表式设计一个 Logger 可以挂多个 handler每个 handler 用 dict 描述自身的类型和专属配置。这让开发时在控制台看、生产时写文件并按天归档成为一套非常自然的配置而不是靠写很多样板代码实现。3.2 format 模板里常用的字段我在实际项目中常用的格式字符串如下{time:YYYY-MM-DD HH:mm:ss.SSS} | {level:^8} | {name} | {file}:{line} | {message}这里面{time}是时间戳支持类 strftime 的格式{level:^8}是居中对齐、最小宽度 8 的级别名称加了之后日志列会非常整齐{file}和{line}能直接定位到出问题的源文件和行号。生产环境我强烈建议把这两个带上否则报错日志里只有一句话你仍然得去代码里大海捞针。3.3 文件轮转参数的实际配置逻辑rotating 场景里rotation和max_bytes是两个关键参数。rotation支持按时间轮转比如00:00表示每天零点切割max_bytes表示单文件达到某个字节数时切割backup_count保留最近多少个切割文件。{ type: file, path: logs/order-service.log, rotation: 00:00, max_bytes: 200_000_000, backup_count: 7, }运维侧如果对接的是 ELK 这类日志采集通常按天切割最合适因为采集端按天索引文件如果日志单日体量极大那就用max_bytes兜底防止单个文件把磁盘打爆。我一般按月保留 14 个文件既能覆盖两周的追溯窗口又不会让磁盘被历史日志拖垮。3.4 异步队列参数max_queue_size 与 workersacrilog 的杀手锏是异步落盘。它内部维护了一个有界队列日志先入队再由后台工作线程批量写入磁盘。这样业务线程不会在log.info上阻塞太长时间。log Logger( nameasync-app, levelINFO, max_queue_size10_000, workers2, )max_queue_size控制队列里最多积压多少条日志如果写入速度跟不上产生速度队列会触发背压策略。workers则是后台消费日志的线程数一般设 1 到 2 就够用设太多反而会引起锁竞争。3.5 自定义 Handler 类型除了控制台和文件acrilog 还支持接入 socket、syslog、邮件等更进阶的 handler。下面是一个自定义 socket handler 的示例适合在分布式系统里把日志实时转发到日志采集 agentlog Logger( namegateway, levelINFO, handlers[ {type: console}, { type: socket, host: 127.0.0.1, port: 9999, protocol: tcp, }, ], )注意socket handler 对网络稳定性有要求如果日志采集端暂时挂了日志写入会走重试逻辑积压过多时也会触发队列背压。建议在关键链路上配置独立 Logger不要把普通业务日志和重要审计日志混在一起。4. 实际应用案例FastAPI 请求日志审计与故障回溯知道语法、参数之后更重要的是知道怎么组合起来用。这里我展示一个完整的 FastAPI 应用日志方案这是 acrilog 最有代表性的应用场景之一也是我线上一直在用的模板。4.1 项目结构与初始化项目结构保持简单清晰app/ ├── main.py ├── core/ │ └── logger.py └── routers/ └── order.py在core/logger.py里初始化 Logger 实例from acrilog import Logger log Logger( nameorder-api, levelINFO, format{time:YYYY-MM-DD HH:mm:ss.SSS} | {level:^8} | {name} | {file}:{line} | {message}, handlers[ {type: console}, { type: file, path: logs/api.log, rotation: 00:00, max_bytes: 100_000_000, backup_count: 14, }, ], max_queue_size10_000, workers2, )把 logger 配置集中在 core 模块的好处是其他路由只需要from core.logger import log就能拿到同一个实例不会出现多个模块各自初始化导致重复输出的问题。4.2 中间件里记录请求全貌FastAPI 的 HTTP 请求是天然的日志切面。我在中间件里把每个请求的关键信息统一记录下来from starlette.middleware.base import BaseHTTPMiddleware from core.logger import log import time import uuid class AccessLogMiddleware(BaseHTTPMiddleware): async def dispatch(self, request, call_next): request_id str(uuid.uuid4()) start time.time() log.bind(request_idrequest_id, pathrequest.url.path, methodrequest.method) try: response await call_next(request) duration_ms (time.time() - start) * 1000 log.info(请求完成, status_coderesponse.status_code, duration_msf{duration_ms:.2f}) return response except Exception: duration_ms (time.time() - start) * 1000 log.error(请求异常, duration_msf{duration_ms:.2f}, exc_infoTrue) raise这里关键点是log.bind(...)之后同一条请求链路范围内的后续日志都会带上 request_id、path、method 字段。在后面的服务层代码里即使只写一行log.info(库存扣减成功)也会自动带上请求 ID排查问题时可以精确串联整条链路。4.3 服务层日志如何串联业务字段订单服务里我会在关键业务节点使用 bind 临时绑定业务字段保证日志上下文和请求维度一致from core.logger import log def create_order(user_id: str, product_id: str, quantity: int): log.bind(user_iduser_id, product_idproduct_id) log.info(创建订单开始) try: check_stock(product_id, quantity) log.info(库存校验通过) except StockNotEnoughError: log.error(库存不足, quantityquantity, leftover_stockquery_stock(product_id)) raise绑定的字段只在当前协程上下文生效不会污染其他请求。这在异步场景下尤其重要因为 acrilog 的 contextvar 机制能避免多协程并发时字段串掉。4.4 用日志复现一次真实故障排查过程写这个案例是因为前段时间我们的下单接口偶发超时用户反馈时问题已经过去了。我直接打开当天 api.log根据日志字段做了这样的检索2024-06-18 10:12:33.812 | INFO | order-api | order.py:42 | 库存校验通过 request_id3f2a1b9c... duration_ms2.10 2024-06-18 10:12:38.921 | ERROR | order-api | order.py:57 | 库存不足 request_id3f2a1b9c... leftover_stock0从时间差能看出check_stock内部在某种情况下会等待约 5 秒。继续追踪check_stock里的日志后发现是下游库存服务的连接池超时时间设置得不合理。整个过程没有加一行临时 print也没有让开发同学多等轮询数据直接复现了真相。这就是结构化日志加字段上下文的真正价值。5. 生产环境实测我踩过的几个 acrilog 坑acrilog 用起来顺手但并不代表没有坑。我在生产环境里踩过的几个问题写出来供大家参考。5.1 多进程模式下的日志交错刚上 acrilog 时我用 gunicorn 起了 4 个 worker 进程结果日志文件里不同进程的内容混杂在一起非常难阅读。原因是每个进程各自维护队列和写入线程时如果两个进程同时写同一个文件锁竞争会导致顺序跳动。解决方式有两种。一种是把 handler 指向不同的文件按进程号做区分另一种是让所有进程把日志发到统一的日志采集 agent由 agent 做统一写入或转发这是更稳妥的方案。如果服务体量不大、只是本地保留也可以接受偶尔的交错但需要先知道这是多进程环境的固有问题而不是 acrilog 本身 bug。5.2 异步写入门槛导致的丢日志隐患异步队列带来性能的同时也带来了进程退出时丢日志的风险。我在一次发版时发现版本更新后的最后几条日志丢了原因是进程被强杀时队列里还积压着待写入的日志。解决方式是在 FastAPI 的 shutdown 事件里主动刷新from fastapi import FastAPI from core.logger import log app FastAPI() app.on_event(shutdown) def shutdown(): log.flush()flush()方法会阻塞等待队列清空。日常本地调试时如果 CtrlC 退出也尽量通过规范的信号处理去触发 flush避免丢失最后的堆栈信息。5.3 队列容量打满时的背压行为流量高峰时如果后端写入速度跟不上日志产生速度max_queue_size会触发背压日志产生方会被阻塞。这本来是保护机制但如果业务逻辑里有日志写失败就重试的设计反而会把压力放大。我的做法是给日志系统单独的容量评估。如果业务接口的 QPS 是 1000平均每请求产生 5 条日志那一秒就是 5000 条队列容量至少要按 5 秒积压量来设置也就是 25,000 到 50,000。太小容易频繁触发背压太大则日志延迟过高排障时不实时。通常我会设置成每秒日志量的 5 到 10 倍并在压测阶段实测调整。5.4 rotation 切割和日志分析工具的冲突使用日志分析工具比如 lnav、grep 脚本时轮转切割会产生api.log.2024-06-18这种历史文件而工具默认只读api.log。如果排查某一天的故障却忘记看历史文件很容易漏掉关键线索。建议在分析之前用ls -lh logs/看一眼当天是否有切割文件或者直接用通配符api.log*阅读分析。6. 性能对比与选型建议很多读者应该关心性能数据到底如何。这里给出一组我在 4 核 8G 云主机上做的简单压测数据仅供参考不构成严格基准方案每秒日志写入量条线程阻塞情况配置复杂度print 加重定向约 3 万单线程同步写极低logging 同步 handler约 1 万有阻塞中logging QueueListener约 6 万少量阻塞高acrilog 默认异步配置约 8 万基本无感低acrilog 的配置复杂度比标准库做异步要低得多这是它最大的优势。如果项目只是脚本工具日志量很小直接用 logging 即可如果是一个长期迭代的 Web 服务或微服务acrilog 的异步模型、结构化日志、上下文绑定和轮转策略能把日志这块基础设施一次性解决掉。7. 最后的技巧分享根据我个人实际使用下来的经验再分享几个容易忽略的小技巧。第一在写业务代码时先想清楚如果这个函数一会儿出错了我需要看到什么信息才能定位再确定日志内容。这比一句简单的xxx报错了重要得多前面讲的 bind 字段也是基于这个思路。第二不要把敏感信息打进日志。订单号、手机号这些字段在日志里出现太多一旦日志文件泄露问题会被放大。必要时可以先做脱敏比如手机号只保留前三位和后四位其他用星号替代。acrilog 支持自定义日志预处理函数可以对所有消息里的敏感字段做统一清洗建议接上这个能力。第三上线之后经常用真实故障日志做复盘而不是只在本地看 DEBUG 输出。第一次把线上日志的真实模样看清楚你会理解为什么结构化字段和上下文绑定比花哨的日志颜色更重要。acrilog 不是一个热门到人人皆知的包但在需要稳定、高效、结构化日志的 Python 服务里它确实给出了一个非常优秀的答案。如果你正在为项目里的日志策略发愁不妨先照着这篇文章里最简单的示例跑一下再用中间件和 bind 把请求链路串起来很快就能体会到它带来的变化。
