I
Member
线上出问题去翻日志，最气人的不是没日志，而是日志里没有关键上下文：不知道是哪个用户、哪个请求、哪次重试。结构化日志就是为了解决这个。
第一，固定字段先定下来：request_id、user_id、模块名、耗时，这四个字段每个日志都要带。没有 request_id，跨服务的调用链根本串不起来。
第二，用 JSON 格式输出，不要再用自由文本拼接。自由文本 grep 起来费劲，JSON 直接进日志系统就能按字段过滤，排查效率差一个数量级。
第三，上下文用 contextvar 传递，不要用全局变量。异步任务和线程池混用时，全局变量会串请求，contextvar 才能保证每个请求的上下文隔离。
第四，分级要克制：INFO 只记关键路径节点，DEBUG 留给本地调试。生产环境 INFO 打太多，关键错误反而被淹没，日志量上去成本也跟着上去。
第五，敏感信息先脱敏再记日志。手机号、token、密码片段哪怕只打一半都不能进日志，脱敏要在日志输出层统一做，不能靠每个人自觉。
落地时建议先给一个核心服务接结构化日志，跑两周确认查询和告警都顺了再推广。你在生产环境查日志时，最常缺的是哪个上下文？欢迎说说你的字段设计。
第一，固定字段先定下来：request_id、user_id、模块名、耗时，这四个字段每个日志都要带。没有 request_id，跨服务的调用链根本串不起来。
第二，用 JSON 格式输出，不要再用自由文本拼接。自由文本 grep 起来费劲，JSON 直接进日志系统就能按字段过滤，排查效率差一个数量级。
第三，上下文用 contextvar 传递，不要用全局变量。异步任务和线程池混用时，全局变量会串请求，contextvar 才能保证每个请求的上下文隔离。
第四，分级要克制：INFO 只记关键路径节点，DEBUG 留给本地调试。生产环境 INFO 打太多，关键错误反而被淹没，日志量上去成本也跟着上去。
第五，敏感信息先脱敏再记日志。手机号、token、密码片段哪怕只打一半都不能进日志，脱敏要在日志输出层统一做，不能靠每个人自觉。
落地时建议先给一个核心服务接结构化日志，跑两周确认查询和告警都顺了再推广。你在生产环境查日志时，最常缺的是哪个上下文？欢迎说说你的字段设计。