# 成本与取舍 · 算清这笔账
> 可观测性的账单常常失控，因为没人算过它。这一章给一套可执行的成本模型（指标/日志/追踪各自怎么算）、四个降本杠杆的性价比排序，以及那个必须有人回答的问题——这份数据值它的价钱吗？
- 作者：David（道雾轩）
- 专栏：指标采集与观测（https://daiw.org/manual/observability.md）
- 最后更新：2026-07-15
- 原文：https://daiw.org/manual/observability/cost-control
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）
# 成本与取舍 · 算清这笔账
[基数控制住了](https://daiw.org/manual/observability/cardinality)，但账单还是会涨。这一章讲**怎么算这笔账、怎么降**。
先说个不舒服的事实：**很多团队的可观测性账单比业务服务器还贵**，而且**没人能说清钱花在哪**。
## 先算清楚：三支柱各自的成本模型
**[第 0 部分讲过三者的成本曲线](https://daiw.org/manual/observability/three-pillars)。现在给可计算的公式：**
**① 指标**
```
存储 ≈ series 数 × (86400 / 抓取间隔) × 天数 × 每点字节数
内存 ≈ 活跃 series 数 × 1~3 KB
例:100 万 series,15s 间隔,保留 15 天
存储 = 1e6 × 5760 × 15 × 2B ≈ 173 GB
内存 = 1e6 × 2KB ≈ 2 GB(仅 series 索引,不含查询)
```
**关键变量是 [series 数](https://daiw.org/manual/observability/cardinality)**——[它是乘法的结果](https://daiw.org/manual/observability/defining-metrics)，也是唯一值得攻的。**[每点约 1.3~2 字节](https://daiw.org/manual/observability/chunk-encoding)是 [Gorilla 压缩](https://daiw.org/manual/observability/chunk-encoding)的功劳。**
**② 日志**
```
存储 ≈ QPS × 每请求日志条数 × 每条字节数 × 86400 × 天数 × 压缩率
例:1 万 QPS,每请求 3 条日志,每条 500B,存 7 天,压缩 10 倍
= 1e4 × 3 × 500 × 86400 × 7 / 10 ≈ 907 GB
```
**注意它和流量成正比**——[这就是“线性增长”的具体含义](https://daiw.org/manual/observability/three-pillars)。**“每请求 3 条日志”这个系数是你最容易砍的地方。**
**③ 追踪**
```
存储 ≈ QPS × 采样率 × 每 trace 的 span 数 × 每 span 字节数 × 86400 × 天数
例:1 万 QPS,1% 采样,每 trace 20 个 span,每 span 500B,存 7 天
= 1e4 × 0.01 × 20 × 500 × 86400 × 7 ≈ 604 GB
```
**采样率是唯一的大杠杆**——[但它决定了你能看到什么](https://daiw.org/manual/observability/sampling)。
**别忘了那些**隐性成本**——它们常常比存储还贵：**
- **查询的算力** —— [一个烂看板每 30 秒跑一次昂贵查询](https://daiw.org/manual/observability/promql-performance)，常年累月。**很多托管服务按查询量收费。**
- **网络传输** —— 跨可用区/跨云传数据，**流量费可能吓到你**。[尾采样“所有 span 都要先发出来”](https://daiw.org/manual/observability/sampling)在这里代价很实。
- **[Collector](https://daiw.org/manual/observability/collector-architecture) 自己的资源** —— agent 模式下 **× 节点数**。
- **人的时间** —— 维护看板、调告警、救火。**这个最贵，也最少被算进去。**
## 四个降本杠杆（按性价比排序）
**① 降基数（性价比最高，应该先做）**
[上一章讲透了](https://daiw.org/manual/observability/cardinality)。为什么排第一？**因为它同时降存储、降内存、降查询成本，而且[几乎不损失信息](https://daiw.org/manual/observability/defining-metrics)**——那些高基数标签本来也没人按它查。
**典型收益：删掉几个没用的标签，series 数降一个数量级。这是白捡的。**
**② 删没人看的数据（第二便宜）**
```text
# 哪些指标从来没被任何查询/告警/看板用过?
# 思路:导出所有指标名,和"看板 JSON + 告警规则"里出现的名字做差集
```
**大多数团队有 30~50% 的指标从没被查过。** 常见来源：某个 exporter 默认吐出几百个指标，你只用其中 5 个。
**`metric_relabel_configs` 的 `keep` 白名单**（而非 `drop` 黑名单）是更彻底的做法：
```yaml
metric_relabel_configs:
- source_labels: [__name__]
regex: "(http_requests_total|http_request_duration_seconds_.*|up)"
action: keep # ← 只留这些,其余全丢
```
⚠️ **白名单的风险**：出事时才发现“那个指标我们没采”。**只对你非常熟悉的 exporter 用它。**
**③ 缩短保留期（简单但有损）**
**问一句：你上次查 30 天前的数据是什么时候？**
多数排障只看**最近几小时**。而长期数据的用途是**趋势和容量规划**——那**不需要原始精度**。
```
原始数据保留 15 天(排障用)
+ [recording rule](https://daiw.org/manual/observability/recording-rules) 预聚合的低精度数据保留 1 年(趋势用)
```
**这是[分层保留](https://daiw.org/manual/observability/recording-rules)**，比“一刀切保留 90 天”省得多、也更实用。
**④ 采样（最后才动，因为最有损）**
[追踪必须采样](https://daiw.org/manual/observability/sampling)。**但指标不该采样**——[它本来就是聚合的，已经很便宜了](https://daiw.org/manual/observability/three-pillars)；对指标“采样”（比如拉长抓取间隔到 5 分钟）会[破坏 `rate()`](https://daiw.org/manual/observability/promql-rate)、[让 lookback 失效](https://daiw.org/manual/observability/promql-model)，**得不偿失**。
## 那个必须有人回答的问题
**“这份数据值它的价钱吗？”——大多数组织从没问过。**
**一个能让讨论落地的做法：给可观测性也定个“预算”**，并**把成本归因到团队**：
```text
# 每个 team 的 series 数(前提:指标上有 team 标签)
count by (team) ({__name__=~".+"})
```
**当一个团队看到“我们的监控每月花 8000 块”时，他们会自己去删没用的指标。** 而当成本是“公司的、没人的”，它就只会涨。
**这和[错误预算的思路一模一样](https://daiw.org/manual/observability/slo-burn-rate)**：**把一个模糊的争论，变成一个有数字的决策**。
**但也要防止走向另一个极端：** 为了省钱把监控砍到瞎——**然后一次事故的损失，超过你省下的全年账单**。
**判断的锚点：**
- **[SLO 相关的指标](https://daiw.org/manual/observability/slo-burn-rate)** —— **不能省**。它们是你判断“系统是否健康”的唯一依据。
- **[RED/USE 骨架](https://daiw.org/manual/observability/metrics-methodology)** —— **不能省**。这是排障的地基。
- **某个 exporter 吐的 300 个内部指标** —— **大胆砍**。你用不到，出事了再临时开。
- **[追踪的采样率](https://daiw.org/manual/observability/sampling)** —— **可以调**，但[别用头部采样把慢请求全丢了](https://daiw.org/manual/observability/sampling)。
**一句话：砍“覆盖面”，别砍“[骨架](https://daiw.org/manual/observability/metrics-methodology)”。**
## 小结与下一章
**可观测性账单常常失控，因为没人算过它。** 三支柱的成本可计算：[**指标** = series 数 × 采样频率 × 天数 × ~2 字节（关键变量是 series 数，唯一值得攻的）；**日志** = QPS × 每请求条数 × 大小（与流量成正比，“每请求几条”是最容易砍的系数）；**追踪** = QPS × 采样率 × span 数](https://daiw.org/manual/observability/three-pillars)。别忘**隐性成本**：[查询算力、跨区流量（尾采样在这里很贵）、Collector 自身 × 节点数，以及**人的时间**（最贵、最少被算）](https://daiw.org/manual/observability/sampling)。**四个杠杆按性价比**：①**[降基数](https://daiw.org/manual/observability/cardinality)**（同时降存储/内存/查询，**且几乎不损失信息**——白捡）；②**删没人看的数据**（[多数团队 30~50% 的指标从没被查过](https://daiw.org/manual/observability/promql-performance)；`keep` 白名单更彻底但有“出事才发现没采”的风险）；③**[分层保留](https://daiw.org/manual/observability/recording-rules)**（原始 15 天排障 + 预聚合 1 年看趋势，胜过一刀切）；④**采样**（最有损，最后动；**指标不该采样**——[拉长间隔会破坏 `rate()` 和 lookback](https://daiw.org/manual/observability/promql-rate)）。**必须有人回答“这份数据值它的价钱吗”**——[把成本归因到团队，让模糊的争论变成有数字的决策（和错误预算一个思路）](https://daiw.org/manual/observability/slo-burn-rate)；但别走极端：**砍覆盖面，别砍[骨架](https://daiw.org/manual/observability/metrics-methodology)**（[SLO 指标和 RED/USE 不能省](https://daiw.org/manual/observability/slo-burn-rate)）。
钱算清了。最后一章回到人：**怎么把这套东西落地，以及这个专栏的收尾。** 👉 [落地与收尾](https://daiw.org/manual/observability/observability-recap)。
## 参考资料
- [1] 关联[基数](https://daiw.org/manual/observability/cardinality)、[Gorilla 压缩率](https://daiw.org/manual/observability/chunk-encoding)、[采样](https://daiw.org/manual/observability/sampling)、[recording rules 分层保留](https://daiw.org/manual/observability/recording-rules)。
- [2] Prometheus 官方文档：Storage（容量规划公式）。
- [3] Google《SRE Workbook》第 5 章（错误预算作为决策工具的思路）。