4、数据指标监控：延迟、吞吐量、错误率与新鲜度
数据指标监控，说白了就是给数据管道装上仪表盘。你得知道它跑得快不快、运了多少货、有没有翻车、以及数据是不是还热乎着。
我刚开始做数据平台时，觉得只要数据能跑通就行。结果有一次凌晨三点被叫醒——报表跑完了，但用的是昨天的数据。嗯，从那以后，我再也不敢忽视指标监控了。
4.1 延迟指标：数据到底慢在哪？
延迟，就是数据从产生到可被查询的时间差。你想想看，用户下了单，你半小时后才看到订单数据，那还做什么实时推荐？
我个人习惯把延迟拆成三段来看：
- 采集延迟：从业务系统产生日志，到消息队列收到这条记录。常见瓶颈是日志落盘太慢，或者 Kafka 分区数不够。
- 传输延迟：从消息队列到计算引擎（如 Flink、Spark Streaming）。网络抖动、背压（backpressure）是主要元凶。
- 计算延迟：从计算引擎开始处理，到结果写入目标存储。这里最容易出问题的是大状态作业的 checkpoint 耗时。
核心指标：P99 延迟比平均延迟更有价值。平均延迟 200ms 看起来很美好，但 P99 可能已经飙到 5 秒了——那 1% 的慢查询才是真正的用户体验杀手。
我在项目中遇到过这样一个案例：某实时大屏的延迟从 10 秒突然涨到 3 分钟。查了半天，发现是 Kafka 消费者组里有个节点挂了，但 rebalance 机制没触发。最后我们加了一个消费者 lag 监控，延迟超过阈值就自动报警。
4.2 吞吐量指标：管道能扛多少货？
吞吐量，就是单位时间内处理的数据量。常见的单位有：
- 条/秒：适合消息队列、流处理场景
- MB/s：适合文件传输、批量导入场景
- 查询/秒（QPS）：适合数据服务层
吞吐量和延迟是一对冤家。你强行提高吞吐量，延迟往往会跟着涨。为什么会这样？因为资源是有限的，队列排长了，等待时间自然增加。
| 场景 | 推荐吞吐量指标 | 常见阈值 |
|---|---|---|
| Kafka 消费 | MB/s 或 条/秒 | 低于峰值 80% 时预警 |
| Flink 作业 | records/s | 低于基线 30% 时报警 |
| API 查询 | QPS | 接近配额上限时扩容 |
| 批量 ETL | 行/分钟 | 低于 SLA 要求时告警 |
避坑指南：我曾经只监控了平均吞吐量，结果某次促销活动流量暴增，平均吞吐量看起来还行，但实际已经有很多请求被限流了。后来我加上了「最大吞吐量」和「限流次数」两个指标，才算真正看清了管道的真实负载。
4.3 错误率指标：翻车了没？
错误率，就是失败操作占总操作的比例。这个指标最直观，但也最容易误报。
我见过一个团队把错误率阈值设成 0%，结果每天被报警淹死——因为网络抖动导致的偶发重试也算进去了。你想想看，一个 99.9% 可用性的系统，每天可能有几千次重试，但真正影响业务的错误可能只有几次。
我个人建议这样划分错误等级：
- 致命错误：数据丢失、主键冲突、Schema 不匹配。必须立即处理。
- 警告错误：超时重试、连接池耗尽后恢复。可以延迟处理。
- 信息错误：格式不规范、字段截断。记录日志即可。
注意：不要只看错误率百分比，还要看数量。一个每天处理 10 亿条数据的系统，0.01% 的错误率意味着 10 万条数据出问题——这可不是小事。
我曾经踩过一个坑：某次数据管道升级后，错误率从 0.1% 降到了 0.01%，看起来是优化成功了。但仔细一查，是因为新版本把很多错误静默吞掉了，根本没报出来。所以，监控错误率的同时，一定要监控「错误被正确上报」这个元指标。
4.4 数据新鲜度指标：数据还热乎吗？
数据新鲜度，衡量的是数据从产生到可用的时间窗口。不同业务对新鲜度的要求天差地别：
- 实时风控：秒级新鲜度，超过 10 秒的数据就没用了
- 实时大屏：分钟级新鲜度，可以接受 1-5 分钟延迟
- 离线报表：天级新鲜度，T+1 就够用
新鲜度监控的核心是「数据水位」。说白了，就是看当前处理到哪个时间点了。比如你的流处理作业当前处理的是 14:32 的数据，而当前时间是 14:35，那新鲜度就是 3 分钟。
关键做法：在每条数据里带上业务时间戳，然后在目标表里记录「最新业务时间」。监控这个时间与当前时间的差值，就是新鲜度。
我在项目中遇到过最头疼的问题：某个数据源突然停了 2 小时，但我们的监控没发现，因为系统还在处理缓存里的旧数据。后来我们加了一个「数据心跳」机制——如果某个数据源超过 5 分钟没有新数据，就触发报警。这才算真正解决了新鲜度监控的盲区。
4.5 四大指标的关系与联动
这四个指标不是孤立的。你想想看：
- 吞吐量突然下降，往往会导致延迟上升
- 错误率飙升，通常意味着新鲜度会恶化（因为失败的数据需要重试）
- 延迟过高，可能引发下游的吞吐量瓶颈
我个人习惯建一个「指标关联矩阵」，把四个指标的异常组合映射到具体问题：
| 延迟 | 吞吐量 | 错误率 | 新鲜度 | 可能原因 |
|---|---|---|---|---|
| ↑ | ↓ | → | ↓ | 资源不足，需要扩容 |
| ↑ | → | ↑ | ↓ | 数据格式异常，大量重试 |
| → | → | → | ↓ | 数据源中断，心跳丢失 |
| ↓ | ↑ | ↑ | → | 背压导致数据积压后爆发 |
（↑ 上升/恶化，↓ 下降/改善，→ 正常）
下面这张图展示了四个指标在数据管道中的位置和关系：
4.6 监控落地的三个关键动作
光知道指标没用，得落地。我总结了三步走：
- 埋点：在数据管道的每个环节（采集、传输、计算、存储）都埋上时间戳和计数器。别偷懒，少埋一个点，排查问题时就得多花一小时。
- 聚合：把原始指标按分钟/小时聚合，存入时序数据库（如 Prometheus、InfluxDB）。原始数据保留 7 天，聚合数据保留 30 天。
- 告警：设置多级阈值。黄色预警（延迟 > 30 秒）发邮件，红色告警（延迟 > 5 分钟）打电话。我曾经因为告警阈值设得太低，半夜被叫醒三次，结果只是正常的流量波动。
小技巧：告警一定要带「上下文」。比如「Kafka 消费者 lag 超过 10000 条，当前 lag 15000 条，持续 5 分钟，建议检查消费者组 consumer-group-xyz」。没有上下文的告警，跟噪音没区别。
嗯，这四个指标监控到位了，你的数据管道才算真正有了「可观测性」。下一层，我们会聊聊日志和链路追踪——那是另一个维度的故事了。