上个月跟一个做零售的技术团队吃夜宵，值班的运维小哥揉着通红的眼睛吐槽，上周618大促峰值刚过，支付接口的P99延迟突然飙到7秒，全组人对着七八块监控面板翻了快40分钟，才发现是灰度发布的时候流量路由规则配错，把15%的用户请求导到了已经下线的旧版本订单节点上。
说真的，这种场景我见得太多了。
很多人提起云原生可观测性体系建设，第一反应就是装几个开源组件，搭几个炫酷的可视化面板，就算交差了。真到出问题的时候，面板上一片红，但是没人能说清楚到底是哪个环节出的问题。
你以为的可观测性，可能只是告警收集器
我见过最夸张的团队，给所有线上服务配了上百条告警规则，CPU涨了要告警，内存涨了要告警，甚至某个中间件的空闲连接数低于阈值也要告警。最忙的时候值班群里一小时能跳几百条消息，真正和业务受损相关的告警，反而被淹在一堆无效通知里，没人注意到。
直到有次用户投诉支付失败率到了5%，他们才发现，之前的所有监控指标，都是盯着服务器和中间件的资源情况，压根没埋核心交易链路的业务指标——比如从用户点下“提交订单”到支付成功的全流程成功率，跨服务调用的错误占比。
说白了，你搭的那套东西，本质上只是个资源告警收集器。离真正的可观测性，差了十万八千里。
别把三个支柱当成要凑齐的KPI
现在行业里讲可观测性，总绕不开日志、指标、链路追踪这三个支柱。听着像要集齐三个道具才能解锁成就似的，很多团队为了凑齐这三个支柱的“完成度”，上来就把全链路的采样率拉到100%，给所有服务打满debug级别的日志，光日志存储的成本每个月就多花了十几万。
结果呢？真排查问题的时候，翻日志翻到眼瞎——因为大量无意义的中间件调用日志、参数打印日志，把真正的错误堆栈、异常请求记录全淹了。链路追踪的数据量太大，查询一次要等十几秒，根本没法用来实时定位问题。
我当时给那个团队提的调整建议很简单：先把和核心交易链路相关的日志级别保留在info，非核心的内部管理服务的日志全压到debug，链路追踪只对错误请求、超过阈值的慢请求做全量采样，正常请求按1%的比例采样就行。
调整完之后，存储成本直接砍了62%，故障排查的平均时间反而从之前的35分钟压到了8分钟。
落地的时候别想着一步到位
我碰到过不少技术负责人，一提起要做可观测性体系建设，上来就拍胸脯要做全公司统一的平台，要把所有业务线的服务、所有中间件、所有基础设施的可观测数据全接进来。
结果搞了大半年，业务线怨声载道——接入流程繁琐，自定义的告警规则配不了，想查个自己业务的专属指标还要提申请走审批，最后大家还是用回了自己原来搭的零散监控，花了几十万的平台成了没人用的摆设。
其实真没必要这么急。
你先从团队最痛的场景切入就行。比如电商团队就先把商品浏览、加购、下单、支付这整条核心链路的指标打通，让值班的人能在一个面板上看到全链路的延迟分布，哪个节点出了性能问题、哪个服务抛了异常，点进去就能看到对应的日志和trace详情，先把这部分的体验做顺了。
上次有个做在线教育的团队，之前想一次性接完全平台的服务，搞了三个月没见动静。后来咬咬牙先从直播上课的核心链路切入，两周就把直播卡顿的排查时间从原来的40分钟压到了3分钟，业务部门看到效果，主动排期要把自己负责的模块接进来，根本不需要技术团队追着催。
最离谱的是有个团队，花了大价钱买了商业可观测平台，结果因为没把业务标签、环境标签、服务版本标签和可观测数据打通，告警弹出来的时候只说“服务异常”，连是哪个业务线、哪个环境的服务出问题都标不清楚，最后还是用回了原来的开源监控，钱全打了水漂——说真的，这钱拿来给值班团队发夜宵补贴不好吗！
可观测性从来不是给技术团队炫技的工具。
别贪多。
别求全。
你只要记住，所有的体系建设，最终都是为了在用户感知到故障之前，就把问题找出来；是为了让值班的兄弟少熬几个通宵；是为了大促的时候不用全组人盯着面板人肉找问题。
做到这些，你的可观测性体系，就算建对了。