日志分析从来不是后台的边角料工作

上周跟一个做了7年运维的老同事在路边摊撸串，他攥着冰可乐骂了十分钟，说上个月大促的时候出了个用户下单失败的问题，全组人轮班熬了14个小时，翻了8台服务器的日志，最后发现是某个边缘网关的日志把用户ID字段写错了，和后端服务的日志对不上，根本拼不起来完整链路。

没人真的喜欢翻日志

说实话，大部分工程师对日志的态度都很矛盾。平时写代码的时候，能在关键节点打个日志就算负责任，谁会特意花时间规范格式？更别说很多人写日志的时候全凭手感，有的人喜欢打”执行成功”，有的人喜欢打”处理完成”，同一个业务逻辑的日志，换个开发写，读起来像两个完全不同的系统。

日志不好读。

很多团队花了大价钱搭的日志检索平台，平时的日活还不如公司内部的订餐群，只有当告警短信炸了所有人的手机，大家才会慌慌张张登进去，输入报错码搜半天，翻出来的日志不是时间戳对不上，就是没有上下文，越翻越急。

太费眼。

我之前问过一个刚工作两年的开发，他说最怕的就是半夜被喊起来排查线上问题，对着满屏的日志找线索，有时候找半小时才发现，是某段代码打日志的时候多输了个空格，导致检索的时候根本匹配不到。

日志分析的成本从来不是买软件的钱

麻烦在于，很多团队算日志系统的账，只算一开始买平台、搭集群的显性成本，从来不算后面持续产生的隐性开销。你每个应用节点每天打10G日志，100个节点就是1T的日增量，存一年就是365T，光冷存储的费用每个月就够招两个初级运维。

更别说很多日志从打出来的那一刻起就没有任何分析价值，比如代码里循环打调试日志，一个批量任务跑十万次循环，打出来的日志占了总存储量的六成，全是重复的无效信息，既占空间，还会把真正有用的故障日志埋在里面。

真的离谱。

我之前见过一个团队的月度日志账单，13万，其中9万是上线的时候忘了把DEBUG级别的日志关掉，整整跑了三周，没人发现。最后财务对着账单找过来，全组人都傻了。

很多人觉得日志分析就是把日志收上来、能搜就行，其实不对。你收上来的东西越杂，后面清洗、检索、排查的成本就越高，到最后你为了存那些没用的日志花的钱，比整个故障造成的损失还大。

有用的日志分析从来不是大而全

这事没那么玄。不是说你把所有日志都存下来、检索速度能做到毫秒级，就是好的日志分析。

之前接触过一个做工业设备联网的团队，最开始他们想把所有采集到的设备运行数据、操作日志全传到中心服务器，算下来一年的存储和带宽成本要两百万，后来拉着一线运维和设备厂商一起梳理了三天，发现真正出故障需要追溯的日志，只占总采集量的3%，剩下的97%都是设备正常运行的心跳包、常规状态上报，根本不需要传到核心日志库，直接在边缘网关节点上过滤掉，只保留异常状态的日志就行。

一下子成本砍了九成。

说白了，日志分析的核心从来不是”存得多、搜得快”，是你能不能在故障发生的最短时间里，找到和问题直接相关的那几行字。很多团队踩过的最大的坑，就是一开始追求大而全，恨不得把系统运行的每一秒细节都记下来，最后检索一个报错关键字出来几万条结果，翻半小时都找不到重点，反而比没有日志还耽误事。

我见过最务实的一套日志规则，是一个二十来人的创业团队定的，没有买任何昂贵的商业可观测性产品，就用开源组件搭了个简单的日志系统，只定了三条死规矩：所有跨服务调用必须带统一的traceId，所有ERROR级别的日志必须写清楚错误发生的位置和触发的业务参数，上线前必须删掉所有循环里的调试日志。就这三条，他们的平均故障排查时间从4小时降到了20分钟，一年省下来的运维成本，比买整套商业平台的费用还多。

别信那些吹得天花乱坠的行业方案。你把最基本的规则捋顺了，比买再贵的系统都有用。