第1章日志系统概述

1. 日志系统概述：为什么需要日志？

说实话，我做了十几年后端系统，见过太多系统崩溃的惨案。每次复盘时，大家最常说的一句话就是——「要是日志打全一点就好了」。日志这东西，平时你可能觉得它不起眼，但真到了出问题的时候，它就是你的救命稻草。

我个人习惯把日志比作飞机的黑匣子。飞机正常飞行时，没人会去翻黑匣子。可一旦出了事故，黑匣子就是还原真相的唯一依据。软件系统也一样，日志记录了系统运行过程中的每一个关键节点。

说白了，日志就干三件事：记录、追踪、诊断。我把它拆开来讲：

故障排查：系统崩了，你总得知道为什么崩吧？日志就是你的第一手资料。我记得有一次线上服务突然 OOM，全靠日志里最后几行异常堆栈定位到了问题——一个循环里忘了释放连接池。
行为审计：谁在什么时候干了什么？日志一查便知。这在金融、电商系统里尤其重要。我曾经帮一个客户排查数据篡改问题，就是通过操作日志锁定了某个异常 IP。
性能分析：接口慢了，是数据库慢了还是网络慢了？日志里的耗时数据会告诉你答案。我习惯在每个关键操作前后打上时间戳，一对比就知道瓶颈在哪。
业务监控：用户登录失败率突然飙升？订单支付成功率下降？日志里的业务指标能帮你第一时间发现异常。

一句话总结：没有日志的系统，就像蒙着眼睛开车。你永远不知道下一秒会撞上什么。

日志的应用场景其实比你想的要多。我挑几个最典型的说说：

这是最常用的场景。系统出问题了，第一反应就是翻日志。我一般会按这个顺序查：

嗯，这里要注意：日志级别一定要设置合理。线上环境我一般只开 WARN 和 ERROR，避免 INFO 日志刷屏影响排查效率。

你想想看，产品经理天天问「用户点击了这个按钮没有？」「用户在哪一步流失了？」。这些数据从哪来？日志。我在做电商系统时，每个页面曝光、每个按钮点击都会打一条日志，最后汇总到数据分析平台。

金融、医疗这些行业，监管要求必须保留操作日志。谁登录了系统？改了什么数据？什么时候改的？一条都不能少。我曾经遇到过监管检查，要求提供半年前的所有操作记录。幸好日志系统设计得够完善，不然真要吃罚单。

微服务架构下，一个请求可能要经过十几个服务。如果每个服务各自打日志，出了问题根本连不起来。这时候就需要链路追踪日志——给每个请求分配一个唯一的 Trace ID，所有服务都带上这个 ID 打日志。我习惯用这种方式快速定位跨服务的性能瓶颈。

我的小建议：刚开始做日志系统时，别想着一步到位。先保证「有日志可查」，再慢慢优化「日志好不好查」。很多团队一上来就搞复杂的日志分析平台，结果基础日志都没打全，本末倒置了。

日志不是乱打的，它有自己的层次。我一般把日志分成三层：

这三层各有各的用处。基础层用来保命，业务层用来追责，分析层用来优化。我建议你在设计日志系统时，先把基础层和业务层做好，分析层可以慢慢迭代。

最后分享一个我踩过的坑。几年前我负责一个支付系统，上线前测试环境一切正常。结果上线第一天，用户反馈支付成功后页面一直转圈。我翻遍所有日志，发现支付回调的日志居然没打！

为什么？因为开发觉得「回调成功是正常流程，没必要打日志」。结果回调成功了，但页面没刷新，我们根本不知道回调到底有没有到达。后来花了整整一个下午，在代码里加了一堆临时日志才定位到问题。

从那以后，我定了一个规矩：所有外部接口的调用，不管成功还是失败，必须打日志。这个习惯帮我避免了很多次类似的尴尬。

避坑指南：我曾经见过一个团队，日志打得特别多，但全是 INFO 级别的「开始执行」「执行结束」这种废话。真正出问题时，有用的信息全被淹没了。记住：日志不是越多越好，而是越精准越好。

好了，这一章我们聊了日志为什么重要、用在哪些地方、以及我的一些实战经验。下一章我会深入讲讲日志级别的选择——到底什么时候用 INFO，什么时候用 DEBUG，什么时候该用 ERROR。这些东西看似简单，但用错了真的会出大问题。