📚 课程目录第4章成本可视化与监控

4. 成本可视化与监控：搭建成本仪表盘

数据契约落地之后，最怕什么？

怕成本失控。

你定好了存储格式，约好了压缩比，设好了生命周期。但线上跑起来，到底花了多少钱？哪个环节超了？没人知道。等月底账单出来，才发现某个表的分区数翻了三倍，存储费用直接爆了。

这种事，我在项目中遇到过不止一次。所以后来我养成了一个习惯：成本必须可视化，必须实时监控。看不见的成本，就是定时炸弹。

4.1 成本仪表盘：你得先知道钱花在哪

搭建成本仪表盘，核心就三个问题：

谁在花钱？——按团队、项目、数据域拆分
花在哪了？——存储、计算、网络、API 调用
趋势如何？——环比、同比、异常波动

我个人习惯把仪表盘分成三层：

层级	目标用户	核心指标
L1 总览层	CTO / 技术负责人	总成本、月度趋势、预算消耗率
L2 域视图层	数据域负责人	各域成本占比、Top-N 高消耗表
L3 明细层	数据工程师	单表存储量、单任务计算耗时、成本明细

你想想看，如果没有分层，所有人看到的都是同一张大表。CTO 嫌太细，工程师嫌太粗。分层之后，各取所需。

核心原则：成本数据必须与数据契约中的标签（team、domain、tier）对齐。否则你根本不知道钱是谁花的。

4.2 设置成本告警阈值：别等爆了才后悔

仪表盘是给人看的。但人不可能 24 小时盯着屏幕。所以告警才是真正的守护者。

设置告警阈值，我建议分三步走：

基线采集：先跑两周，收集正常情况下的成本数据。比如每天存储增长量、每小时计算消耗。
阈值设定：基于基线，设定三个等级：
- 警告（Warn）：超出基线 20%，发通知到钉钉/企微
- 严重（Critical）：超出基线 50%，发短信 + 电话
- 紧急（Emergency）：超出预算 80%，自动触发降级策略（如关闭非核心任务）
动态调整：业务有波峰波谷，阈值不能一成不变。我习惯每周 review 一次告警命中率，把误报率压到 5% 以下。

避坑指南：我曾经把告警阈值设得太死，结果半夜三点被电话吵醒，一看只是某个临时任务多跑了 10 分钟。从那以后，我学会了加「静默期」——比如凌晨 2-6 点只记录不告警，白天再复盘。

4.3 实战：Grafana + Prometheus 搭建成本监控

好了，理论说完了。咱们直接上手。

这套组合拳，说白了就是：Prometheus 负责采集和存储指标，Grafana 负责展示和告警。

4.3.1 数据契约指标暴露

首先，你得让数据契约相关的成本指标能被 Prometheus 抓到。我一般会在数据平台的核心服务里埋一个 /metrics 端点，暴露以下指标：

# HELP data_contract_storage_bytes 数据契约存储大小
# TYPE data_contract_storage_bytes gauge
data_contract_storage_bytes{domain="user",team="profile",tier="gold"} 1.2e+12
data_contract_storage_bytes{domain="order",team="payment",tier="silver"} 4.5e+11

# HELP data_contract_compute_cost_total 数据契约计算总消耗（单位：CU）
# TYPE data_contract_compute_cost_total counter
data_contract_compute_cost_total{domain="user",task="etl_daily"} 3500
data_contract_compute_cost_total{domain="order",task="realtime_agg"} 1200

# HELP data_contract_budget_ratio 预算消耗比例（0~1）
# TYPE data_contract_budget_ratio gauge
data_contract_budget_ratio{domain="user"} 0.65
data_contract_budget_ratio{domain="order"} 0.82

嗯，这里要注意：标签（labels）一定要跟数据契约里的元数据一致。否则后面做聚合分析时，你会发现 team 对不上、domain 拼写错了，数据全乱套。

4.3.2 Prometheus 配置

在 prometheus.yml 里加上抓取任务：

scrape_configs:
  - job_name: 'data_contract_cost'
    scrape_interval: 60s
    static_configs:
      - targets: ['data-platform:8080']
        labels:
          service: 'data-contract-cost-exporter'

为什么间隔设 60 秒？成本指标不像 CPU 那样需要秒级监控。一分钟一次，足够发现异常，又不会给 Prometheus 太大压力。

4.3.3 Grafana 仪表盘配置

接下来是重头戏——搭仪表盘。我一般会建三个面板：

总成本趋势图：时间序列折线图，展示每日总成本变化。叠加预算线，一眼就能看出是否超支。
成本分布饼图：按 domain 或 team 拆分，看看哪个域是「吞金兽」。
Top-N 高消耗表：列出存储或计算消耗最高的前 10 个数据契约，方便快速定位问题。

Grafana 的查询语句大概长这样：

# 总成本趋势（按天聚合）
sum by (domain) (
  rate(data_contract_compute_cost_total[1d])
)

# 存储占比
topk(10, 
  sum by (domain) (data_contract_storage_bytes)
)

4.3.4 告警规则配置

在 Grafana 里配置告警，我习惯用「基于阈值的告警」：

# 告警规则示例
- alert: 存储成本异常增长
  expr: |
    sum by (domain) (
      data_contract_storage_bytes
    ) > 1e12
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "{{ $labels.domain }} 域存储超过 1TB"
    description: "当前值: {{ $value | humanizeBytes }}"

告警通知渠道，我推荐用 Webhook 转发到企业或钉钉。Grafana 原生支持，配置起来很简单。

小技巧：告警消息里一定要带上「数据契约 ID」或「domain」标签。这样收到告警的人，不用查半天就知道是哪个域出了问题。

4.4 知识体系总览

下面这张图，是我对本章核心逻辑的总结。你可以把它当作搭建成本监控的路线图：

从数据契约指标出发，经过 Prometheus 采集，拆分成存储、计算、预算三个维度，最终在 Grafana 上呈现并触发告警。整个链路闭环，缺一不可。

4.5 写在最后

成本可视化这件事，说白了就是「先看见，再管住」。没有仪表盘，你就是在黑箱里做优化。有了它，每一次成本变动都清清楚楚。

我见过太多团队，花了几百万做数据平台，却舍不得花两天时间搭个成本监控。结果月底一看账单，傻眼了。

别让你的团队成为下一个。