成本与取舍 · 算清这笔账

第 0 部分讲过三者的成本曲线。现在给可计算的公式：

① 指标

存储 ≈ series 数 × (86400 / 抓取间隔) × 天数 × 每点字节数
内存 ≈ 活跃 series 数 × 1~3 KB

例:100 万 series,15s 间隔,保留 15 天
  存储 = 1e6 × 5760 × 15 × 2B ≈ 173 GB
  内存 = 1e6 × 2KB ≈ 2 GB(仅 series 索引,不含查询)

关键变量是 series 数——它是乘法的结果，也是唯一值得攻的。每点约 1.3~2 字节是 Gorilla 压缩的功劳。

② 日志

存储 ≈ QPS × 每请求日志条数 × 每条字节数 × 86400 × 天数 × 压缩率

例:1 万 QPS,每请求 3 条日志,每条 500B,存 7 天,压缩 10 倍
  = 1e4 × 3 × 500 × 86400 × 7 / 10 ≈ 907 GB

注意它和流量成正比——这就是“线性增长”的具体含义。“每请求 3 条日志”这个系数是你最容易砍的地方。

③ 追踪

存储 ≈ QPS × 采样率 × 每 trace 的 span 数 × 每 span 字节数 × 86400 × 天数

例:1 万 QPS,1% 采样,每 trace 20 个 span,每 span 500B,存 7 天
  = 1e4 × 0.01 × 20 × 500 × 86400 × 7 ≈ 604 GB

采样率是唯一的大杠杆——但它决定了你能看到什么。

别忘了那些隐性成本**——它们常常比存储还贵：**

• 查询的算力 —— 一个烂看板每 30 秒跑一次昂贵查询，常年累月。很多托管服务按查询量收费。
• 网络传输 —— 跨可用区/跨云传数据，流量费可能吓到你。尾采样“所有 span 都要先发出来”在这里代价很实。
• Collector 自己的资源 —— agent 模式下 × 节点数。
• 人的时间 —— 维护看板、调告警、救火。这个最贵，也最少被算进去。

① 降基数（性价比最高，应该先做）

上一章讲透了。为什么排第一？因为它同时降存储、降内存、降查询成本，而且几乎不损失信息——那些高基数标签本来也没人按它查。

典型收益：删掉几个没用的标签，series 数降一个数量级。这是白捡的。

② 删没人看的数据（第二便宜）

# 哪些指标从来没被任何查询/告警/看板用过?
# 思路:导出所有指标名,和"看板 JSON + 告警规则"里出现的名字做差集

大多数团队有 30~50% 的指标从没被查过。 常见来源：某个 exporter 默认吐出几百个指标，你只用其中 5 个。

metric_relabel_configs 的 keep 白名单（而非 drop 黑名单）是更彻底的做法：

metric_relabel_configs:
  - source_labels: [__name__]
    regex: "(http_requests_total|http_request_duration_seconds_.*|up)"
    action: keep      # ← 只留这些,其余全丢

⚠️ 白名单的风险：出事时才发现“那个指标我们没采”。只对你非常熟悉的 exporter 用它。

③ 缩短保留期（简单但有损）

问一句：你上次查 30 天前的数据是什么时候？

多数排障只看最近几小时。而长期数据的用途是趋势和容量规划——那不需要原始精度。

原始数据保留 15 天(排障用)
  + [recording rule](/manual/observability/recording-rules) 预聚合的低精度数据保留 1 年(趋势用)

这是分层保留，比“一刀切保留 90 天”省得多、也更实用。

④ 采样（最后才动，因为最有损）

追踪必须采样。但指标不该采样——它本来就是聚合的，已经很便宜了；对指标“采样”（比如拉长抓取间隔到 5 分钟）会破坏 rate()、让 lookback 失效，得不偿失。

“这份数据值它的价钱吗？”——大多数组织从没问过。

一个能让讨论落地的做法：给可观测性也定个“预算”，并把成本归因到团队：

# 每个 team 的 series 数(前提:指标上有 team 标签)
count by (team) ({__name__=~".+"})

当一个团队看到“我们的监控每月花 8000 块”时，他们会自己去删没用的指标。 而当成本是“公司的、没人的”，它就只会涨。

这和错误预算的思路一模一样：把一个模糊的争论，变成一个有数字的决策。

但也要防止走向另一个极端： 为了省钱把监控砍到瞎——然后一次事故的损失，超过你省下的全年账单。

判断的锚点：

• SLO 相关的指标 —— 不能省。它们是你判断“系统是否健康”的唯一依据。
• RED/USE 骨架 —— 不能省。这是排障的地基。
• 某个 exporter 吐的 300 个内部指标 —— 大胆砍。你用不到，出事了再临时开。
• 追踪的采样率 —— 可以调，但别用头部采样把慢请求全丢了。

一句话：砍“覆盖面”，别砍“骨架”。