3. 成本度量与监控：建立成本度量指标体系、成本监控工具选型、成本异常告警机制
聊完了成本拆解和模型设计，接下来要面对一个更现实的问题：你怎么知道钱花在哪了？
我见过不少团队，模型设计得漂漂亮亮，一到月底看账单就傻眼——超支了，但不知道是哪个环节超的。说白了，没有度量就没有管理。这一章，我们就来聊聊怎么把成本“看清楚”。
3.1 建立成本度量指标体系
度量指标不是拍脑袋定的。我个人习惯，先分三层：
- 财务层：总成本、环比增长率、预算执行率。这是给老板看的。
- 资源层：CPU 利用率、内存水位、存储吞吐、网络带宽。这是给运维看的。
- 业务层：单条数据加工成本、每查询成本、每报表成本。这是给产品经理看的。
这三层缺一不可。我曾经遇到一个项目，财务层显示成本正常，但业务层单条数据成本已经翻了三倍——因为数据量暴增，但资源没跟上，导致任务重试率飙升。嗯，这就是典型的“指标盲区”。
3.1.1 核心指标定义
我建议你至少盯住这几个指标：
| 指标名称 | 计算公式 | 说明 |
|---|---|---|
| 单位数据成本 | 总成本 / 有效数据量 | 衡量数据“性价比” |
| 资源利用率 | 实际使用量 / 已分配量 | 低于 30% 说明浪费严重 |
| 任务重试率 | 重试次数 / 总执行次数 | 超过 5% 需要排查 |
| 存储压缩比 | 原始数据大小 / 存储大小 | 衡量压缩策略效果 |
3.1.2 指标采集方式
指标怎么来？无非三种方式：
- 埋点采集：在数据管道的关键节点（如 ETL 任务开始/结束、API 调用前后）打点，记录时间戳和资源消耗。
- 日志解析：从系统日志、任务日志中正则匹配出关键字段。比如 Spark 的 event log 里就有 stage 级别的 shuffle 读写量。
- API 拉取：云厂商的账单 API、监控 API，定时拉取。注意频率，别把 API 配额打满了。
我个人更推荐“埋点 + API 拉取”组合。日志解析容易漏，而且解析逻辑一改，历史数据就断了。你想想看，一个指标跑了三个月，突然因为日志格式变更断了，那多可惜。
3.2 成本监控工具选型
工具选型这件事，我踩过不少坑。先说结论：没有银弹。你得根据团队规模和基础设施来选。
3.2.1 开源 vs 商业
| 维度 | 开源方案（如 Prometheus + Grafana） | 商业方案（如 Datadog、CloudHealth） |
|---|---|---|
| 上手成本 | 高，需要自己搭、自己配 | 低，开箱即用 |
| 灵活性 | 极高，想怎么配就怎么配 | 受限于厂商能力 |
| 成本 | 免费（但人力成本高） | 按量付费，规模大了很贵 |
| 告警能力 | 基础，需要二次开发 | 完善，支持多通道 |
我的建议是：小团队用商业方案，大团队用开源方案。小团队没精力维护一套监控系统，直接买服务最划算。大团队有专门的 SRE，开源方案能省下不少 license 费。
3.2.2 我的选型清单
这里列一下我目前在用的组合，供你参考：
- 指标采集：Prometheus + Node Exporter + 自定义 Exporter
- 可视化：Grafana（必选，生态太好了）
- 日志监控：ELK（Elasticsearch + Logstash + Kibana）
- 告警通知：Alertmanager → 企业/钉钉/邮件
- 成本分析：自建成本大盘（基于 ClickHouse 存储指标数据）
3.3 成本异常告警机制
指标有了，工具有了，接下来就是告警。告警不是越多越好。我见过有人配了 200 条告警规则，结果每天告警轰炸，最后大家直接把告警群屏蔽了。这叫什么？这叫告警疲劳。
3.3.1 告警分级
我习惯把告警分成三级：
- P0（致命）：成本超预算 50% 以上、核心任务失败、存储写满。需要立即响应，电话通知。
- P1（严重）：成本超预算 20%、任务重试率超过 10%、资源利用率低于 20%。需要当天处理。
- P2（警告）：成本超预算 10%、任务重试率超过 5%、存储增长异常。需要本周内排查。
为什么要分级？说白了，人的注意力是有限的。P0 告警响了，所有人放下手头工作去处理。P2 告警响了，记下来，有空再看。这样团队才不会疲于奔命。
3.3.2 告警规则设计
告警规则不是写死的。我建议用动态阈值。举个例子：
# 静态阈值（不推荐）
- 如果 单位数据成本 > 0.5 元，则告警
# 动态阈值（推荐）
- 如果 单位数据成本 > 过去7天均值 * 1.5，则告警
为什么动态阈值好？因为业务有波动。双十一期间数据量暴增，单位成本自然会上涨。如果用静态阈值，双十一期间天天告警，反而掩盖了真正的问题。
3.3.3 告警收敛与去重
还有一个常见问题：告警风暴。一个底层任务失败，导致上游 100 个任务都失败，然后收到 100 条告警。这谁受得了？
解决方案是告警收敛：
- 依赖分析：建立任务依赖 DAG，只告警根因任务。
- 聚合规则：相同类型的告警，5 分钟内只发一条。
- 静默期：同一个告警，24 小时内不重复发送。
3.4 成本监控体系架构图
说了这么多，画张图总结一下。这张图展示了我常用的成本监控体系架构：
3.5 落地建议
最后，给几个落地建议：
- 先搭指标，再搭告警。没有指标，告警就是空中楼阁。
- 告警规则从少到多。先配 5 条最核心的，跑一个月再补充。
- 定期复盘。每个月拉一次告警记录，看看哪些告警是有效的，哪些是噪音。
- 成本大盘要公开。我习惯把成本大盘放到团队公共大屏上，谁都能看到。这样大家会有成本意识，做决策时会多想一想。