📚 课程目录第2章核心指标采集

2. 核心指标采集：数据流水线延迟、吞吐量、错误率、数据质量与资源利用率

监控系统建好了，接下来就是往里面填东西——采集哪些指标？

说实话，我见过不少团队一上来就铺几百个指标，结果告警风暴天天炸，真正出问题时反而被淹没了。我个人习惯是：先抓五个核心维度，把这五个看住了，流水线基本不会翻车。

五个核心维度速览

延迟 —— 数据从源头到目标花了多久
吞吐量 —— 单位时间处理了多少数据
错误率 —— 失败任务/记录的比例
数据质量 —— 空值率、异常值等
资源利用率 —— CPU、内存、IO

2.1 延迟：数据到底卡在哪了？

延迟是流水线最直观的健康指标。说白了，就是数据从源头到目标花了多久。

我一般把延迟拆成三个层次来采集：

端到端延迟：从数据产生到写入目标存储的总耗时。比如 Kafka 生产时间戳到 Hive 分区写入时间戳的差值。
阶段延迟：每个处理环节的耗时。比如 Extract 阶段、Transform 阶段、Load 阶段各花了多少秒。
队列等待时间：数据在缓冲区或消息队列里排队的时间。这个指标特别容易被忽略。

我的经验：有一次流水线延迟从 5 分钟飙到 30 分钟，端到端告警响了。我一看阶段延迟，发现 Extract 只慢了 2 秒，但队列等待时间从 10 秒变成了 25 分钟——原来是下游消费能力跟不上。如果只看端到端，你根本不知道问题出在哪。

采集方式很简单，在关键节点埋时间戳：

# 伪代码示例：在数据记录中埋入时间戳
def process_record(record):
    record['_ingest_ts'] = int(time.time() * 1000)  # 入口时间
    # ... 处理逻辑 ...
    record['_output_ts'] = int(time.time() * 1000)  # 出口时间
    record['latency_ms'] = record['_output_ts'] - record['_ingest_ts']
    return record

2.2 吞吐量：流水线到底能扛多少？

吞吐量衡量的是单位时间内处理的数据量。我常用两个口径：

记录数/秒：适合行式数据，比如 MySQL CDC 的变更事件数。
字节数/秒：适合批量或流式场景，比如 Kafka Topic 的字节流入速率。

为什么要两个都看？举个例子：

有一次我发现记录数/秒没变，但字节数/秒翻了一倍。排查后发现上游某个表新增了一个大文本字段，单条记录从 200 字节变成了 2KB。记录数没涨，但网络和磁盘 IO 压力已经上来了。如果只看记录数，你根本意识不到问题。

注意：吞吐量采集要区分“瞬时值”和“平均值”。瞬时值用于发现毛刺，平均值用于容量规划。我个人习惯两个都采，但告警阈值只设瞬时值。

2.3 错误率：别等数据丢了才发现

错误率是流水线的“疼痛指数”。我把它分成两类：

错误类型	示例	采集方式
任务级错误	Spark Job 失败、SQL 执行超时	任务调度系统 API + 日志解析
记录级错误	数据格式不匹配、字段截断	处理逻辑中 try-catch 计数

任务级错误通常直接触发告警，记录级错误则容易被忽略。我曾经遇到过一个场景：每天有 0.1% 的记录因为日期格式问题被丢弃，任务本身是成功的，但业务方发现数据对不上了。从那以后，我坚持在每条流水线里加一个“脏数据计数器”。

# 记录级错误采集示例
error_count = 0
total_count = 0
for record in batch:
    total_count += 1
    try:
        process(record)
    except Exception as e:
        error_count += 1
        log_error(record, e)

# 上报指标
emit_gauge('pipeline.error_rate', error_count / total_count)

2.4 数据质量：空值率和异常值

数据质量是流水线监控里最容易被忽视的维度。系统跑得再稳，数据是脏的，一切白搭。

我主要关注两个指标：

空值率：关键字段（比如订单 ID、用户 ID）的空值比例。突然升高通常意味着上游 schema 变更或数据源异常。
异常值：数值字段的分布异常。比如金额字段出现负数，或者年龄字段出现 200 岁。

采集方式：在 Transform 阶段增加数据质量检查算子，对每个字段做规则校验。规则可以简单到“非空检查”，也可以复杂到“均值 ± 3σ 范围检查”。

举个例子，我曾经维护过一个用户画像流水线。某天年龄字段的空值率从 2% 突然跳到 15%。排查后发现上游数据源新增了一个渠道，该渠道不采集年龄信息。如果没有空值率监控，这个问题可能要等到业务方反馈才会被发现——那时候已经影响了好几天的模型训练。

2.5 资源利用率：别让基础设施拖后腿

最后一个是基础设施层面的指标。CPU、内存、IO 这三个是标配。

资源	关键子指标	常见问题
CPU	使用率、平均负载、iowait	CPU 打满导致任务排队
内存	使用率、Swap 使用量、GC 频率	OOM 导致任务被 kill
IO	磁盘读写速率、IOPS、延迟	磁盘瓶颈导致吞吐量下降

这里我想强调一点：资源利用率要和流水线指标联动看。比如 CPU 使用率 90% 不一定有问题，但如果同时吞吐量下降、延迟上升，那说明资源已经成了瓶颈。

避坑指南：我曾经在监控系统里只采集了 CPU 使用率，没采集 iowait。有一次磁盘坏了，iowait 飙到 80%，但 CPU 使用率只有 30%。我盯着 CPU 看了一下午，愣是没发现问题。后来加了 iowait 指标，这种坑再也没踩过。

2.6 指标采集的落地建议

说了这么多，最后给几个落地建议：

先少后多：刚开始只采上面五个维度的核心子指标，跑通后再逐步细化。
统一采集代理：用 Telegraf、Prometheus Node Exporter 或自研 Agent 统一采集，避免每个组件各自为政。
打标签：每个指标带上流水线名称、阶段、主机等标签，方便后续聚合和过滤。
设置基线：运行一周后自动计算基线，用基线代替固定阈值做告警。

嗯，核心指标采集就这些。把这五个维度看住了，你的流水线监控就有了骨架。剩下的就是根据业务场景往里填肉了。