上周跟个做电商的技术负责人吃饭，他说上次大促前压测，核心链路转了三圈都没测出问题，结果上线十分钟，支付成功率掉了两个点，查了俩小时才发现是某个边缘服务的超时阈值没对齐，日志里明明白白写了半小时，没人看。
大多数人对日志的第一认知就错了
很多团队一开始搞日志，就是出了问题才去捞，搜报错码，查堆栈，跟开盲盒似的。说白了，这就是把日志当事后诸葛亮的工具。
代价是什么？就是每次故障的平均定位时间，能拉到两三个小时，中间的资损、用户流失，算下来比整套日志系统的成本贵十倍都不止。
他说之前团队每次出问题，第一反应是找开发要堆栈，找运维看监控指标，翻来覆去对，就是没人去把全链路的日志按traceid串起来看。等串起来才发现，用户点了支付按钮之后，请求先过了风控校验，风控查用户画像的时候，缓存里的过期数据没清，给了个延迟200ms的返回，后面的支付服务扛不住积压，直接超时了。
这事没那么玄。很多人觉得日志分析就是要上大平台，搞AI异常检测，其实不是，最基础的，把同一个请求跨服务的日志串起来，能省掉一半的排查时间。
搞日志分析的钱到底要花在哪
很多团队一上来就踩坑，上来就买最贵的商业日志平台，把所有服务器、所有服务的日志全接进去，存30天，结果呢？日常根本没人看，真出问题的时候，搜出来几万条无关日志，翻都翻不动。
麻烦在于，日志这东西，不是越多越好。比如你个内部管理系统，一天的请求量才几千条，日志级别设成debug，把每个接口的入参出参全存，除了占磁盘，半毛钱用没有。
真正该花钱的地方，是核心业务链路的日志字段标准化。比如所有涉及交易的服务，日志里必须带统一的traceid，必须记录请求的入参关键值、处理时长、返回码，不能每个开发写日志的时候，想打啥打啥，有的写“处理失败”，有的写“报错了”，有的直接啥都不写。日志分析的基础，从来不是存了多少日志，而是你能不能在需要的时候，快速定位到和问题相关的那几行。
之前有个团队，为了省存储成本，把所有非核心链路的日志留存时间设成3天，结果有次用户投诉说，上周买的东西没收到退款，回头查的时候，日志已经被清了，只能挨个翻数据库的流水，花了一周时间才把用户的操作路径拼出来，用户早就注销账号走了，品牌口碑的损失，根本不是那点存储费能补回来的。
其实根本不用纠结全量日志存多久，核心链路的日志，至少存3个月，非核心的，存7天足够。甚至你可以把日志按价值分层，交易链路的、用户操作的，单独存，系统层面的常规日志，压成冷数据存对象存储，查询的时候再拉出来，成本能降70%都不止。
别等出了故障才想起日志分析
很多团队对日志的使用场景，还停留在故障排查阶段。其实日常的业务优化，根本离不开日志分析。
比如你做个活动页面，上线之后，日志里能看到有多少用户点了立即报名，多少用户卡在了填手机号的步骤，多少用户提交之后跳回了首页，这些数据，你靠埋点统计是有误差的，但是日志里记的是每一次真实的请求，没有任何美化。
上次跟个做SaaS的团队聊，他们之前一直觉得自己的用户流失率高是因为产品功能不好，结果翻了一周的访问日志才发现，有快两成的用户，点了登录按钮之后，页面直接白屏，根本没进到产品里，之前的监控只盯着服务的可用率，没盯着用户端的真实请求返回，修了这个问题之后，用户的周留存直接涨了八个点。这个事，换做以前，可能要花几十万做用户调研，找产品顾问来分析，结果靠日志分析，花了俩小时就找到根因了。
别神化日志分析。这事没那么玄。不需要你一开始就搞什么大数据平台，搞什么实时分析引擎。先从最小的事做起：把核心链路的日志字段统一，把跨服务的traceid串起来，把日常排查最常搜的几个关键词，做成固定的检索面板。等这些基础的事做扎实了，再考虑要不要接实时告警，要不要做异常检测。
我见过太多团队，日志系统搭了快一年，连最基础的日志字段统一都没做好，天天喊着要上大模型分析日志，纯纯的本末倒置。
上次跟那个电商的负责人吃完饭，他回去就把团队的日志规范改了，把之前存了90天的全量debug日志全清了，只留核心链路的结构化日志，成本砍了一半，上次大促的时候，有个服务的响应时间突然涨了30%，靠日志分析，五分钟就定位到是缓存集群的节点出问题了，连半夜都没叫人起来。