日志的目的是可追溯，而不是堆量

很多项目的日志量很大，但真出事时依然难以定位。原因是日志写成了单点状态的流水账：某个函数进入了、某个分支走了、某次调用返回了什么，却缺少把它们串起来的那条线。排障要回答的问题是这一次请求经历了什么，而不是系统整体做了什么。

把这一次请求串起来的较有效做法，是给每条日志带上同一标识。入口生成一个请求编号，之后所有输出都带上它，检索时一次过滤就能拿到完整链路。跨服务调用要把标识传下去，否则链在中间断开，前后两段各自完整但连不起来。

日志的详略要按层级区分。稳定的常规路径只记录摘要与耗时即可，出错时才展开细节。全量记录原始数据的代价很高，存储成本上升之外，还会让人在大量正常输出里找异常。常见折中是保留全部指标数据、对原始内容做抽样，并对超过阈值的慢请求做完整追踪。

写日志还要避免两种极端。一种是把内部变量全部打印出来，看起来信息丰富，实际上没有任何结构，检索困难；另一种是只在错误时记录一行简短描述，缺少输入条件，无法复现。有用的日志通常说明三件事：在做什么、输入是什么、结果与预期差在哪里。

最后一个容易被忽略的点：日志本身要有测试。给关键路径写一条断言，检查在正常与异常两种情况下是否输出了应有字段。听起来多余，但线上事故常常来自日志代码本身出错，比如格式化失败导致异常被覆盖，反而把原始问题藏得更深。