日志这件事，几乎所有团队都在做，但不是所有团队都做得好。好的日志帮你快速定位问题，坏的日志制造告警疲劳和存储浪费。DZone 上的 The Art of Logging 总结了日志最佳实践，我把要点整理成几条清单，方便对照。
日志级别选择
最常见的错误是什么都打成 ERROR。如果所有东西都是错误，错误信号就没有意义了。
- INFO ：有意义的业务事件或状态变更。用户下单、服务启动、定时任务执行完成。
- WARN ：非预期但已被妥善处理的情况，可能需要关注。第三方接口超时后重试成功、配置项使用了默认值。
- ERROR ：确实需要人工调查的故障。数据库连不上、数据损坏、未捕获的异常。
- DEBUG ：详细的排障信息，线上环境默认关闭。
关键原则：预期会发生的事件不应该打 ERROR。用户输错验证码、下游返回业务校验失败、第三方拒绝请求（因为参数不对），这些都是正常业务逻辑的一部分，记录日志可以，但不该打 ERROR。把预期内的业务失败也打 ERROR，告警系统就会失效，值班工程师也逐渐不再信任告警。
上下文该记什么
一条日志有没有用，取决于它能不能回答这几个问题：发生了什么、在哪发生的、是预期还是异常、有多严重、工程师接下来该查什么。
好的日志上下文包括：
- 请求 ID 或 trace ID
- 操作名称（如"支付授权"）
- 服务名称和环境
- 涉及的外部依赖
- 失败原因或错误码
- 关键业务标识（订单号、用户 ID）
看两个例子对比：
- 差：
Error occurred - 好：
Payment authorization failed for orderId=84219, provider=stripe, reason=card_declined, retryable=false
后者有价值，是因为它把事情说清楚了：哪笔订单哪个环节出了什么问题，工程师看到这条日志可以直接判断怎么处理。
敏感数据清单
上下文有用，但不是什么东西都能往日志里写。以下内容不应该出现在日志中：
- 密码和 token
- 完整的信用卡号
- 个人身份信息（身份证号、手机号、地址）
- 敏感的业务 payload
记了不该记的东西，轻则违反合规要求，重则数据泄露。判断标准：这条日志如果被第三方看到了，你会不会紧张？
业务失败 vs 系统故障
这是区分日志级别的核心。很多告警系统在这件事上跑偏了。
业务失败（预期内的） ：信用卡被拒、密码输错、404（资源不存在）。这些是产品流程中的正常分支，用 INFO 或 WARN 记录，配业务元数据用于分析即可。不需要告警。
系统故障（非预期） ：超时、未捕获异常、依赖服务中断、数据损坏。这些需要打 ERROR 并触发告警。
两者的本质区别：前者是你的业务逻辑主动返回的"不行"，后者是你的系统"本不该这样"。监控应该把工程注意力引向真正出了问题的地方，而不是业务上不顺的地方。
避免过度记录
过度记录是日志系统退化的最快路径。每个函数调用都记、每个循环迭代都记、每个状态变更都记。那真正有用的信息就会被淹没。搜索变慢、仪表盘变乱、存储成本上升。
加日志之前问自己：
- 排障时我会搜这条日志吗？
- 它记录的是有意义的状态变更或决策点吗？
- 这条日志帮回答"发生了什么"吗？
如果答案都是否，就不该记。
最佳实践要点
最后几条实操建议：
- 统一格式 ：所有日志用相同格式输出，方便解析和查询
- 结构化日志 ：用 JSON 等结构化格式替代纯文本，比用 grep 搜字符串可靠得多
- 人类可读的 message ：结构化的字段留给机器处理，日志正文还是要让人一眼看懂
- 关联 trace ID ：跨服务的调用链靠 trace ID 串联，没有这个标识分布式排障基本靠猜
- 定期清理噪声 ：像重构代码一样定期审查日志，删掉那些已经没用的、过于聒噪的
总结
好的日志只记录重要的事情，而且要说清楚。用正确的级别、带上足够的上下文、区分预期失败和真故障。日志是系统和运维人员沟通的渠道，它不是代码的附属品。
这篇文章列的都是基础原则，不算新鲜。但偶尔翻出来对照一下清单，看看有没有跑偏的地方也不错。