服务器日志太多，只看这三类就够

2026-09-21 服务器日志,故障排查,运维效率

我的后台服务刚上线那阵，日志一天能涨到几十兆，我打开看两分钟就关掉——不是看不懂，是不知道从哪看起。后来我把服务器日志太多怎么看这件事收成一条规则：绝大多数行都不用看，只有三类行值得你停下。

一、先明确一点：全看等于不看

日志的价值不在数量，在比例。一份日志里 99% 是正常请求的流水，它们的唯一作用是在你需要定位时提供上下文，平时完全可以不看。

我早期犯的错是打开日志从上往下读，读到第三屏就放弃了。翻日志翻到放弃，最后的结果就是出问题全靠猜。

具体动作：给你的日志行分个级，请求流水和错误分开落盘。哪怕只是两个文件，也比混在一起强。

分完之后你会发现，值得看的量级从「一天几十兆」掉到「一屏以内」。

服务刚起来的那几行，信息密度最高。

它会告诉你配置读到了什么、监听的端口对不对、依赖连上没有。很多「服务起不来」的问题，答案就在这几行里，只是被后面的流水淹了。

我的习惯是每次部署完先看这一段，确认关键项都正常，再去看别的。启动日志干净，后面 90% 的问题都不会发生。

具体动作：只抓服务启动后短时间内的日志，逐行看完。

如果这几行里有你看不懂的警告，先别放过它。看不懂本身就是信号。

单次报错可以忽略，同一条错误在短时间内反复出现就是信号。它通常意味着某个下游挂了、某个参数错了、某段逻辑进了死循环。

我判断的标准很简单：同样的错误在一屏里出现两次以上，就停下来查。

具体动作：按错误信息聚合，看数量排序，从最多的那条看起，而不是从最早的那条看起。

顺序反过来会让你追着一个已经自愈的偶发问题跑很久。

慢不等于错，但慢往往是错的先兆。

日志里如果带了耗时字段，重点看尾部那几条。一次请求比别人慢十倍，通常说明它撞上了锁、等了下游、或者数据量涨了。

这类行平时不影响使用，所以最容易被忽略，等到用户投诉的时候已经积累了一段时间。看日志不只是为了找错，也是为了在变成错之前发现异常。

具体动作：给关键路径的日志加上耗时，然后定期扫一眼最大值。

注意看的是最大值，不是平均值。平均值会把那几次最慢的请求抹平，而那几次才是线索。

剩下的行我用两种方式处理：一是保留一段时间的原始日志，出问题时再回头翻；二是定期清理，别让磁盘被日志填满。

日志堆在服务器上不是资产，是为了万一出事能复盘。留够回溯的时间窗口就够了，不用留到天荒地老。

如果你连日志都还没稳定落盘，先解决那个问题再看内容。

看了半天没看出问题，很多时候不是你不会看，是日志本身没写对——该有的字段没有，该区分级别的没区分。

我现在写日志只守两条：错误必须带上能定位的上下文，正常流程不要刷屏。做到这两条，服务器日志太多怎么看就不再是个问题。

Q：服务器日志太多怎么看，需要上日志系统吗？

A：个人项目大多数不需要。先保证日志分级落盘、错误带上下文，用命令行按关键词和数量排序就够用了。

Q：日志要保留多久？

A：按你能接受的排查窗口来定，一般保留到「上次稳定运行」之前就够了。超过这个窗口的日志，价值会快速下降。

Q：日志里要不要记录用户信息？

A：尽量不要记敏感信息，需要追踪时用可关联的标识替代。判断标准是这份日志泄漏出去会不会造成麻烦。