上周在园区楼下碰到个做SaaS的技术负责人，蹲在台阶上抽第三根烟，说刚因为订单支付失败的事被产品追了半小时，翻了快4G的应用日志才找到问题——不是代码bug，是网关侧的超时阈值设得比第三方支付的回调等待时间短了200ms。
别把日志分析等同于出问题才查的应急手段
很多团队对日志分析的认知还停留在“救火工具”的阶段。平时攒的日志要么直接滚存删了，要么堆在对象存储里落灰，连个基础分类标签都没有。真等到系统报红、业务侧催着要定位原因的时候，才发现之前攒的日志全是没结构化的纯文本，要找个特定用户的操作路径，得在几十个节点的日志里grep来grep去，半小时过去，业务侧已经把投诉电话打爆了。
没人算过这笔账。很多团队花大价钱买了可观测性平台，最后只开了告警推送的功能，把日志分析的模块扔在一边，本质上还是没搞清楚——日志里记的从来不是冷冰冰的时间戳和状态码，是每一次请求在系统里走过的完整脚印。结构化日志的核心价值，是把原来零散的文本块，拆解成可以被机器快速检索、关联的字段，比如用户ID、请求路径、接口耗时、上游返回码，这些字段不用人工逐行翻，平台几秒钟就能把同一次请求跨节点的日志串成完整的链路。
我见过不少团队在这上面走弯路。为了图省事，所有日志全用print语句打在控制台，连个日志级别都不设，debug、info、error的信息混在一起，等真要找异常的时候，翻几页全是“接口请求成功”的废话，真正的报错信息早就被刷没了。
日志分析的成本从来不是软件授权费
很多人算日志分析的投入账，只算买平台的 license 费用，其实最大的两笔成本，从来不是软件钱。一笔是写日志、维护日志规则的人力成本，另一笔是存储日志的硬件成本。
之前碰到个做电商的技术团队，为了所谓的“全量可观测”，把所有接口的入参出参全打在日志里，连用户上传头像的base64编码都原封不动存进去了。跑了三个月，存储账单涨了四倍，真要找问题的时候，海量的冗余日志把真正有用的信息全埋住了。
太蠢了。
日志不是打越多越好。你得做取舍。哪些信息是真的需要长期留存的？比如核心交易链路的全链路日志，至少要存够30天，方便回溯用户投诉的历史问题；哪些是临时调试用的？比如某个模块的开发调试日志，排查完问题就应该把级别从debug调到info，不然天天刷的日志占了存储，还会把真正的error级别的告警给淹了。
还有个容易被忽略的隐形成本，就是日志的权限管控。之前有团队把所有日志的查询权限开给了全公司的技术人员，结果有人为了找个测试环境的问题，随手拉了上周的全量用户操作日志，差点把包含用户手机号的敏感数据导出去，最后花了快两周补流程、做数据脱敏，这部分的隐形成本，比买三套日志平台的钱都贵。说白了，日志分析从来不是买个软件往服务器上一装就完事的事，是要跟着业务的迭代不断调整规则的——今天加了个新的第三方支付渠道，日志里就要多记一个渠道返回的交易流水号；明天上了新的缓存集群，就要把缓存命中的耗时字段加上，不然等缓存击穿的时候，你翻半天日志都不知道是哪层出了问题。
没人能靠日志分析写出完美的系统
很多做可观测的厂商会吹，说上了日志分析平台，系统故障的定位时间能从小时级降到分钟级。这话半真半假。
真的能快。
但别神化。
之前参加过一次大促前的压测复盘，团队靠日志分析找到三个隐藏的问题：一个是数据库连接池的配置太小，峰值的时候有请求排队等连接；一个是消息队列的消费延迟没设告警，积压了两万条消息都没人发现；还有个是前端埋点的日志打错了字段，把接口的耗时全记成了页面渲染的时间。这些问题靠单看监控指标是找不出来的——监控只会告诉你接口的平均耗时涨了，不会告诉你是哪个环节拖慢了速度，这时候日志分析的价值才真的体现出来。
说实话，我从来没见过哪个团队把日志分析做的十全十美。有的团队日志打不全，跨服务的链路串不起来；有的团队日志字段定义混乱，同一个用户ID，在网关日志里叫uid，在应用日志里叫user_id，在数据库日志里叫userid，每次查问题都要先花十分钟对齐字段定义；还有的团队告警规则设的太松，一天弹几百条warning，最后大家都对告警麻木了，真的error来了都没人看。
这都很正常。毕竟写日志的是不同的开发，每个人的习惯不一样，总有人觉得“这个日志不重要不用打”，也总有人为了图省事把异常栈整个打出来，占了好几行的存储。前阵子碰到个做了十年运维的老工程师，说他现在做日志分析的习惯，是每次新功能上线前，先把这次上线涉及的几个接口的日志规则先过一遍——哪些字段是必须记的，哪些日志是要设告警的，日志存多久，查的时候要走哪个权限组。
不是什么高深的技术。就是把之前踩过的坑，每次都提前堵上。很多人觉得日志分析是运维的专属活，其实根本不是。开发写代码的时候要不要记关键节点的日志？产品要不要看日志里用户的操作路径，找产品体验的问题？安全团队要不要靠日志找异常的访问请求？这事没那么玄。就是你系统里发生的所有事，都在日志里记着，你愿意花点时间把这些碎的信息串起来，就能少踩很多没必要的坑。别等系统崩了，用户投诉了，才想起来翻那堆没人整理过的日志。