云原生可观测性体系建设落地实战手记

上个月帮南京一个做生鲜电商的客户做大促前的最后一轮巡检。 本来以为他们装了Prometheus加Grafana，监控全乎了。 结果压测到第17分钟，整个可观测面板直接卡成PPT。点开Pod指标，全是空白。Traces链路从网关出来就断了，日志堆了12G的无用爬虫访问记录，连个用户下单失败的堆栈都找不到。那晚三个人轮着刷临时脚本捞数据，天快亮的时候才找到根因——他们把所有可观测组件的资源配额压得比业务Pod还低，节点一忙，最先被驱逐的就是采集Agent。

那些被忽略的基础细节

很多团队做可观测建设的时候，总想着先上大平台、搞复杂的关联分析，偏偏把最基础的资源配额给漏了。采集Agent本质上也是跑在集群里的一个普通Pod，你不给它留够CPU和内存，不设高优先级的调度策略，真到节点资源紧张的时候，它就是第一个被牺牲的对象。到时候你存了再多的规则、搭了再炫的面板，关键时刻采不上数据，全白搭。

别把工具堆出来的东西叫可观测体系

说出来都好笑，这已经是我今年遇到的第五个把”装了监控工具”等同于”做完可观测建设”的团队了。 之前接触过一个做在线教育的客户，光可观测平台的采购预算就花了近百万，日志、指标、链路三个模块全接满，结果真出故障的时候，开发对着面板翻了二十分钟，说”我根本不知道哪个告警跟我负责的服务有关”。还有更离谱的，把可观测的建设任务全甩给SRE团队，业务开发连自己服务埋的什么traceid都没透传，整个链路断了半层，查了两个小时才发现埋点漏了。 很多人对可观测的理解，还停留在”把所有能采的数据都存下来”的阶段。真的没必要。可观测的核心从来不是存了多少T的数据，而是当系统出问题时，你能在三分钟内定位到根因，而不是对着几个T的日志翻一下午。

落地的时候别一开始就追求大而全

不过话说回来，做可观测建设最容易踩的坑，就是上来就追求”全场景覆盖””全链路打通”。 我们现在给客户做方案，第一步根本不是先对比哪个工具的功能多，是先拉着业务、SRE、开发坐下来，把过去半年所有的线上故障摊开列一遍：每一个故障当时排查花了多久，缺了什么数据，哪个环节卡了最久。比如之前那个生鲜电商，过去半年的线上故障里，60%是因为库存服务超时导致下单失败，那第一优先级就是把库存服务的指标、链路、日志先打通关联，其他边缘营销服务的采集先放一放，根本没必要一开始就全量铺。 第二个要注意的，就是给采集组件留足生存空间。之前有个客户把otel-collector的资源限制设成500mCPU，压测的时候直接被节点的kubelet干掉，我们给调到1core，加了高优先级的PriorityClass，再也没出过采集中断的问题。别让你的采集Agent跟业务Pod抢资源，更别让它在节点压力大的时候第一个被踢出去——不然你花几十万搭的系统，关键时刻连数据都采不上来，纯纯摆设。 还有成本的问题，别搞”所有日志永久留存”。按业务场景分级，核心交易链路的日志留30天，边缘的爬虫访问日志留7天就行，光这一项就能把存储成本砍六成。 可观测体系从来不是搭完就一劳永逸的，每个季度要做一次故障演练。故意把某个服务搞挂，看整个可观测系统能不能在五分钟内给出准确的告警和定位路径。上次我们给那个生鲜电商做演练，故意把支付服务的数据库连接池打满，结果告警等了八分钟才弹出来，根因是告警阈值设得太保守，改完之后下次演练，2分10秒就定位到了问题点。 之前跟做云原生的朋友聊天，说现在很多厂商把可观测吹得神乎其神，好像买了他们的产品就能实现零故障。 哪有那好事。 说白了，可观测从来不是什么高大上的技术概念，就是你给云原生系统装的一套”神经系统”——你手被扎了能立刻感觉到疼，知道是哪个位置出了问题，而不是等整个胳膊肿得抬不起来了，才反应过来哪里出了问题。 就这么简单。