前几天跟一个做基础设施的朋友吃饭，聊到他们公司的可观测性支出。他翻了翻账单，说了句让我愣了一下的话："我们现在花在监控上的钱，已经比花在业务系统本身还多了。"

我当时以为他在夸张。回去之后翻了一下自己这边的情况，虽然没有那么离谱，但确实有一个数字让我坐不住——可观测性相关的基础设施开销，已经占到了整体基础设施预算的百分之十几。

Grephr创始人最近抛出一个观点：可观测性预算通常占基础设施的5%到20%，但可靠性的回报是递减的。前半句我验证过了，后半句，我自己踩了几个坑之后，才真正理解什么叫"递减"。

看得见的花费，看不见的成本

可观测性的花费是很隐蔽的。不像服务器、带宽那样一目了然，它藏在各种角落里：Prometheus的存储、Grafana的实例、日志系统的索引、告警链路的计算资源、Trace数据的采样和回传。

我之前让一个同事算过，我们一个中等规模的业务系统，光Prometheus+Grafana就要占两台高配机器，日志系统每天写入大概200GB，再加上全链路追踪的采样数据，一个月的存储和计算开销折合下来，差不多是业务系统本身的三分之一。

这还只是显性成本。更隐蔽的是人的时间。配置监控规则、维护Dashboard、处理误报告警、升级采集Agent——这些活儿不产出业务价值，但确实需要有人做。我们有一个同学，一半以上的时间花在"维护监控系统"上，而不是"用监控系统解决问题"。

23条告警，4条是噪音

两年前我经历过一件事。某天凌晨，系统告警像放鞭炮一样连着响了十几条。值班同学爬起来一看，其中大部分是关联告警——同一个根因触发了不同层级的监控规则。真正需要他处理的问题，其实只有一个。

但那十几条告警已经让他花了将近二十分钟去逐条判断"这个要不要管"。

后来我们统计了一下，当时每天产生的告警大概有200多条，其中真正需要介入的不到20条。也就是说，超过90%的告警是"正确的噪音"——它确实反映了某种异常，但这种异常不需要人来处理。

问题是，这90%的噪音会钝化你对那10%有效信号的敏感度。值班同学看多了"误报"，开始条件反射地忽略告警，直到有一天一条真正严重的告警也被他划过去了。

这是可观测性的第一个悖论：数据越多，判断力越差。不是数据本身有问题，而是人处理数据的带宽是有限的。

后来我们做了一轮告警瘦身，把200多条砍到40多条，标准很简单——"如果这条告警响了，值班同学需要在5分钟内做点什么"。不满足这个条件的，一律降级为日报或周报。效果很明显，告警响应时间反而缩短了。

度量的错觉

可观测性还有一个更隐蔽的问题：它擅长度量容易度量的东西，而不是真正重要的东西。

我们的监控Dashboard上有一堆指标：QPS、延迟P99、错误率、CPU利用率、内存占用、连接池使用率。这些数字都很精确，曲线都很漂亮。但用户真正关心的问题——"这个页面能不能正常打开"、"这笔交易能不能顺利完成"——你很难用一个指标直接衡量。

有一回我们接到用户投诉，说某个功能用不了。查监控，所有指标正常。查日志，没有报错。最后排查了半天，发现是上游服务返回了一个"格式正确但内容不对"的数据——HTTP 200，JSON结构完整，但里面的关键字段是个空字符串。

监控告诉你"一切正常"的时候，你可能恰恰正在出问题。这种错觉比没有监控更危险，因为你以为自己兜住了底。

这让我想到一个类比：可观测性和GDP有点像。GDP能精确衡量经济活动的"量"，但衡量不了经济体的"健康程度"。你盯着GDP增速做决策，可能会忽略结构性的问题。可观测性也一样——指标全面不等于认知全面。

可靠性回报递减这件事

Grephr那个"回报递减"的说法，我自己的体感是这样的：从0到80分的可观测性建设，投入产出比极高。几行配置就能让你从"两眼一黑"变成"心中有数"，这个阶段的每一分钱都值。

但从80分到95分，需要的投入可能是前面的好几倍。你需要全链路追踪、自定义指标、智能告警、根因分析——系统复杂度急剧上升，维护成本也跟着涨。而换来的，可能只是故障发现时间缩短了那么几分钟。

从95分到99分，那又是一个量级的投入。很多团队走到这一步，会发现一个尴尬的事实：你的监控系统本身的可用性，可能还没有被监控的系统高。监控系统挂了，你连"系统正常"这个信息都拿不到。

我自己有过类似的经历。有一次监控系统本身出了故障，Prometheus的存储满了，数据写入中断了两个小时。那两个小时里，我们完全是在"盲飞"——不是系统出了问题发现不了，而是根本不知道系统还在不在。后来恢复之后补数据，发现那两个小时其实一切正常，但那种"睁眼瞎"的恐慌感，我到现在还记得。

所以后来我在团队里定了一个规矩：每个月花半天时间，专门做"监控系统的健康检查"。看看哪些告警规则已经过时了，哪些Dashboard已经没人看了，哪些采集器的配置需要更新。这件事不产生任何业务价值，但能防止你在最关键的时刻发现——你的安全网早就破了个洞。

该花多少，取决于你现在在哪

5%到20%这个区间，我觉得可以参考，但不能照搬。早期业务，5%就够了——基本的指标监控、错误日志、几条核心告警，足够应对大部分情况。业务规模上来了，往10%走。复杂分布式系统、金融级可用性要求，可能要到15%甚至更高。

关键是，这个数字应该跟你的业务复杂度同步增长，而不是跟行业标杆对齐。我见过一些团队，系统还没几个用户，可观测性的配置已经对标大厂了。结果就是，系统还没出过问题，维护监控的人先扛不住了。

还有一个容易忽略的点：可观测性的投入应该跟"故障恢复能力"挂钩，而不是跟"故障预防能力"挂钩。很多团队花大量预算在"如何更快发现问题"上，但真正影响用户体验的是"发现问题之后多久能恢复"。前者是监控，后者是预案、是演练、是组织架构。后者往往更便宜，但也更难做好。

说到底，监控不是目的，恢复才是。

写到这里，我想起那天吃饭时朋友说的最后一句话："最好的可观测性，是你几乎忘了它的存在，但需要的时候它就在那。" 我觉得这个标准挺好的——不是看你的Dashboard有多炫，而是看你的团队在排查问题时，第一反应是打开监控，还是打开代码。如果大部分人选择打开代码，说明你的可观测性还有改进空间。不是因为监控不够多，恰恰可能是因为太多了。