日志系统：为什么线上排查离不开结构化日志

很多同学刚开始写服务时，对日志的理解往往很朴素：哪里想看就 fmt.Println 一下，出错了就打印一个字符串。这种方式在本地调试时当然够用，但只要服务开始跑在测试环境、上线环境，日志的角色就完全变了。它不再只是给开发者“看一眼”，而是变成了线上排查、链路定位、故障复盘时最重要的证据之一。

日志系统真正要解决的，不是“把内容打出来”，而是让你在请求量上来、问题变复杂、多人协作时，仍然能快速找到和某个请求、某个错误、某段调用链相关的信息。

为什么随手打印很快就不够用

因为线上问题从来不是按单个函数发生的。

你需要知道这个请求来自哪里、参数是什么、走了哪个下游、耗时多久、为什么失败、和其他日志能不能串起来。如果日志只是零散的中文字符串，就很难被检索、聚合、过滤和分析。

尤其是当多个请求并发到来时，如果日志没有统一字段和上下文信息，输出再多也很难形成真正有用的排查线索。

结构化日志的关键，不是“长得像 JSON”这么简单，而是它把日志拆成了明确字段。

比如一次请求日志，除了 message 以外，通常还会包含。

这样做的意义是，日志不再只是给人肉阅读，而是也能被系统检索和聚合。你可以快速筛出某个请求 ID 的全部日志，也可以统计某段时间内某类错误的分布。

因为后端服务上线以后，很多问题并不能直接复现。

用户说一个请求失败了，接口已经过了；某个下游偶发超时，本地根本打不出来；某次参数组合触发了异常分支，问题只出现了一次。这个时候，日志几乎就是你唯一能回看的现场。

如果日志打得随意，线上问题就会非常难查；如果日志字段清晰、上下文一致，很多问题甚至不需要重现就能先定位到大方向。

第一，不要把日志当成随手输出，而要当成事件记录。

第二，尽量统一日志格式和字段命名。

第三，重要路径要带上下文，例如请求 ID、接口路径、错误原因、耗时。

第四，不要在业务各处用不同风格随意打印，否则后面检索和归类会非常痛苦。

很多人初学时不太在意 debug、info、warn、error 的区别，觉得反正都能看。但服务一旦进入真实环境，日志级别就很重要了。

因为不同级别对应不同的观测重点。

普通运行信息适合 info，可能异常但尚未失败的情况适合 warn，真正错误和失败适合 error。如果所有内容都用同一层级打印，后面既无法聚焦，也会制造噪声。

1	fmt.Println("query user failed")

这条日志的问题不是不能看，而是信息量太低。你不知道是哪个请求、哪个用户、哪个下游、什么错误、耗时多久。等请求量一上来，它几乎没有排查价值。

更合理的方式是，让日志至少具备上下文。

例如你在记录错误时，最好能关联请求路径、请求 ID、耗时、错误对象。即便日志内容依然是简洁中文，它也应该附带足够结构化字段，让你后续能在大量日志中把这次失败找回来。

给你的最小 Go 服务增加请求日志和错误日志。

要求至少记录。

然后再模拟一次错误返回，把错误日志和请求日志关联起来。只要你做过这个练习，就会直观感受到：结构化日志的价值，不在“好看”，而在“能查”。

日志系统是后端工程化里最容易被轻视、却最不能缺的一部分。很多时候，一个服务的维护难度并不取决于代码本身有多复杂，而取决于出问题时你还能不能看见足够清楚的现场。结构化日志的意义，就是把服务运行过程变成可检索、可串联、可复盘的证据链。这是线上排查能力真正的起点。