没人喜欢翻日志。你想象一下，凌晨两点的告警电话打过来，你裹着被子爬起来连VPN，登到服务器上面对几万行滚动的日志，连个统一的时间戳都没有，那种崩溃感，干过三年以上后端的人都懂。真的烦。
没人愿意主动碰日志
大部分团队的日志，都是开发随手打的。写接口的时候顺手写一句log.info(“请求进来了”)，碰到异常的时候打个堆栈，剩下的全靠系统默认的输出。平时没人管，等磁盘快满了才想起来清，等服务挂了才想起来捞。很多人觉得日志是甩锅的证据——比如线上出问题了，先看哪个模块打的日志少，先找谁。这种氛围下，谁愿意主动花时间整理日志？
更麻烦的是，很多日志根本没用。比如循环里把每个参数都打一遍，一次请求生成几十条重复日志，真要找问题的时候，有效信息全被这些垃圾日志淹了。之前碰到个刚入职的开发，写的订单查询接口，每次调用都会把数据库返回的全量字段打在日志里，一晚上攒了180G日志，直接把应用服务器的磁盘打满，排查到凌晨四点才找到根源。
日志分析的价值从来不是救火
很多人对日志分析的认知，还停留在出问题了才去查。说白了，这是把日志当成了故障档案，太亏了。
90%的性能劣化，在用户投诉之前就已经写在日志里了。比如某个接口的响应时间，从平时的200毫秒慢慢涨到800毫秒，没有触发告警，没有用户投诉，但是日志里每一次的耗时都明明白白记着。还有用户的操作路径，比如用户在支付页连续点了三次提交按钮，日志里能看到三次重复的请求，这时候你根本不需要等客服反馈，就能知道页面可能有按钮失灵的问题。
现在很多团队搞可观测性，把指标、链路、日志拆成三个独立的系统，最后反而把最有价值的日志给孤立了。指标是宏观的，链路是片段的，只有日志是带着具体上下文的——哪个用户，在什么时间，点了哪个按钮，传了什么参数，最后返回了什么结果，这些细节，光靠指标是看不出来的。
别上来就堆最贵的工具
我见过太多团队，日志分析做不好，第一反应就是买更贵的平台。从最初的grep，到ELK，到商业化的可观测平台，花了大几十万上百万，结果还是查不到问题。
没有统一规范的日志分析，本质上就是在瞎找。你想啊，Java服务的日志时间戳是东八区，Python服务的日志用的是UTC时间，差了8个小时，traceId在网关生成了，到服务端直接丢了，你就算把所有日志都存在一起，串不起完整的链路，有什么用？
小团队一开始根本不需要搞什么复杂的集群。先把最基础的规范做了：所有日志的时间戳统一带时区，每个跨服务的请求都透传同一个traceId，生产环境把没用的debug日志全关掉，日志格式统一成固定的字段，能直接通过关键词检索。这些事不需要花一分钱，只要开发在写代码的时候多花两分钟注意，效果比买几十万的平台还好。
真的，日志分析从来没有什么高大上的玄学。我见过做的最好的团队，从来不是平台买的最贵的那个。是每次发版前，开发都会检查下自己新加的日志有没有用，是出问题的时候，所有人能顺着一个traceId，在3分钟内定位到具体的代码行。别把日志分析当成运维一个人的事。毕竟那些堆在服务器上的日志，本来就是写代码的人一行一行打出来的。