你的监控账单正在蚕食基础设施预算——原因在这里，以及真正管用的解决办法

大多数云原生架构里都藏着一个悄无声息的预算杀手。它不会发邮件或者 Slack 消息来提醒你。它只会……不停地涨。一个月接一个月。直到某天 CTO 打开云账单，问出谁都不想回答的那句话："为什么我们的监控工具比运行实际产品的服务器还贵？"

只要你干工程 leadership 够久，要么你问过这个问题，要么听过别人问。如果你现在正在创业，那几乎肯定会碰上。

那个隐形的乘法器：为什么监控费用看起来根本没法预测

关于现代监控定价，有个让人不太舒服的真相：它压根就没打算让你能预测。它是跟着你的成功一起扩张的。

市面上主流的监控供应商——Datadog、New Relic、Splunk、Grafana Cloud——定价模式本质上都是乘法模型。你不是在买一个产品，你是在买一组互相相乘的维度。主机数乘以 GB 数乘以事件数乘以指标数乘以用户数。新增一个微服务？那就新增了主机和事件量。服务开始承受更多流量？那就产生了更多事件和更多指标。开发者在日志里加了一个 user_id 标签来方便调试？光是这一个标签，在高基数的情况下就能生成数百万个独立的时间序列。

这个数学不是线性的，是指数级的。

我跟好几个创始人聊过，他们最初监控账单才 300 块一个月，十八个月内就飙到一万五了——不是因为收入同比增长，而是架构变得越来越复杂。新服务、新环境、新开发者做着当时看起来完全合理的决定，但背后却藏着账单炸弹。

拆解定价架构

搞懂监控成本为什么会失控，得先明白供应商到底是怎么收你钱的。大多数定价页面看着都清清楚楚。现实却是一层叠一层的费用，之间的相互影响在你已经深陷超额费用之前完全看不出来。

按主机收费这一层：大多数供应商按主机或节点收费来做基础设施监控。听起来很简单。30 台主机的时候确实简单。等你融资后扩张到 300 台，这就成了一个不小的基准线——就算你把其他所有东西都优化了，这部分也不会减少。

按摄入量收费这一层：日志、指标、链路追踪都会按摄入量计费。大多数供应商压缩后的日志还是按原始摄入量计费。一个中等吞吐量的应用产生结构化日志，轻松就能达到每天 50-100GB 的摄入量——这个数字跟流量直接挂钩。

基数陷阱：这里开始变得真正危险了。现代分布式系统鼓励打丰富的标签——给遥测数据加上 customer_id、request_id、region 或者 tenant_id 这样的元数据。表面上，这是非常优秀的可观测性实践。实际上，每一个独特的标签值都可能生成一整条全新的时间序列。单个指标带上高基数的标签，可以在不知不觉中生成数百万个序列，每个都单独计费。

我见过好几家公司因为开发者在调试时给一个计数器指标加了个 user_id 维度，收到了五位数的账单调整。那个指标本身完全合理。账单影响却从来没在任何文档里出现过。

真实成本对比：你实际在为什么付钱

咱们来聊聊数字，空谈没法帮你做预算。

拿一个真实的中等规模场景来说——比如 15 个微服务跑在 30 个 Kubernetes 节点上，中等强度的日志和链路追踪——每个月的监控费用大概在 1500 块到 4000 块以上不等，具体看选哪家。这个差距可不是什么舍入误差。到了规模级别，最便宜和最贵的选项之间差的不只是百分比，是数量级。

这里有点让人难堪的部分：最贵的选项不一定是差产品。Datadog 的工具和集成深度确实很出色。但当你的监控账单超过你的计算账单时，你得问问自己——你到底是在买监控，还是在买运行产品的基础设施。

对于小团队来说，计算方式不太一样。种子轮阶段，自建方案的运维成本通常超过托管服务的溢价。你没有专职 SRE 来调优 ClickHouse 集群或者排查 Loki 扩容问题。托管服务的溢价通常值——直到它开始不值。

自建这条路：省钱但有条件

开源这条路——通常是 LGTM 那一套（Loki 做日志，Grafana 做可视化， Tempo 做链路追踪，Mimir 或类似方案做指标）——能把软件授权费用彻底砍掉。供应商没法跟你收自己运行的东西的钱。

但这种说法漏掉了一点：软件免费，但基础设施不免费，工程师的时间更是绝对不免费。

规模化运行监控基础设施需要专人盯着。ClickHouse 和 Grafana Mimir 需要调优。Loki 的基数控制不好也会跟商业方案一样失控。查询性能随着数据量增长会下降。这些问题你不能忽视，还指望它在出事故的时候正常工作。

社区估算，中等规模下自建监控每个月需要 10-20 小时的专职工程时间。按 SRE 全成本时薪 75-150 块算，这还没花一分钱在基础设施上，就已经产生了 900-3000 块的机会成本。对某些组织来说，这绝对是正确的选择。对另一些组织来说，这是在分散注意力，偏离了他们真正应该做的——做产品。

真正管用的办法：不同阶段的实操建议

看了这么多团队在这个领域的摸索，几个模式浮现出来，能帮你控制监控成本，同时不牺牲真正需要的可见性。

从激进地限制数据保留期开始。大多数团队默认保留 30 天或 90 天，因为这样感觉比较全面。但实际调试用不了那么久。7 天覆盖绝大多数事故调查。14 天处理大多数安全取证。保留期就是纯存储成本——狠狠砍。

每季度审计一次指标基数。这是隐形的账单推手。简单建个 dashboard 显示序列数量最多的指标。任何生成超过 1 万个序列的都值得仔细看看。开发时看起来合理的高基数标签，到了规模级别就变成预算灾难。

考虑能减少遥测量的架构模式。链路追踪用采样策略，日志在摄入前做激进过滤，指标在边缘做聚合而不是进了数据仓库再处理——这些能把摄入成本降低 70-90%，同时不会明显降低可观测性。

诚实评估你实际需要的可观测性水平。你真的需要全服务分布式追踪精确到毫秒以下吗？每个开发人员都需要访问全部历史数据吗？功能开关、基于角色的访问控制、精心设计的采样——这些能大幅降低成本，同时保留真正对事故响应重要的可见性。

前进的路：不要账单要可见性

监控危机不是技术问题——是财务建模问题。工具从来没这么好过。它们产生的数据从来没这么有价值过。但定价模式创造了一种错位的激励：供应商从你的架构复杂性中获利，而不是从你的运营成功中获利。

聪明的工程团队正在做出回应：把监控当作头等预算项目，而不是事后才想起来的东西。他们设定成本预算，把成本和可用性 SLA 一起监控，评估供应商变化时用跟评估基础设施决策同样的严谨程度。

目标不是不要监控。是用跟实际运行的东西相匹配的成本，拥有恰到好处的监控。你的监控系统应该帮你理解基础设施——而不是变成你花钱去理解的那个基础设施。

那些早点想明白这一点的团队会拥有显著的优势：更低的烧钱速度、更快的迭代节奏，在关键的增长阶段少一件跟工程注意力抢资源的事儿——而这个阶段专注最重要。