2. Flink作业核心指标监控：Checkpoint、背压、延迟、吞吐量、资源利用率
说实话，Flink 作业跑起来容易，但想让它稳定跑半年不出事，那就得靠监控了。我见过太多团队，作业上线后只看个「运行中」就以为万事大吉，结果凌晨三点被报警叫醒——Checkpoint 超时、数据延迟爆炸、背压把整个集群拖垮。
这一章，咱们就聊聊 Flink 作业最核心的五个指标。我个人习惯把这五个指标称为「Flink 五件套」：Checkpoint、背压、延迟、吞吐量、资源利用率。你只要盯住这五个，作业的健康状况基本就心里有数了。
核心观点： 这五个指标不是孤立的。背压高了，延迟必然涨；Checkpoint 失败，吞吐量就会掉；资源利用率异常，往往预示着背压或数据倾斜。你得学会把它们串起来看。
2.1 Checkpoint：作业的「后悔药」
Checkpoint 是 Flink 的容错基石。说白了，它就是定期给作业状态拍一张快照。一旦作业挂了，可以从最近的快照恢复，不至于从头开始算。
我个人习惯把 Checkpoint 指标分成三块来看：
- 完成时间： 正常应该在几秒到几十秒内完成。如果超过 5 分钟还没完，那就有问题了。
- 失败次数： 连续失败 3 次以上，必须马上介入。
- 对齐耗时： 这是最容易忽略的。对齐时间过长，说明背压已经起来了。
我的经验： 曾经有个实时数仓作业，Checkpoint 偶尔失败一次，大家都没在意。结果一个月后，作业状态膨胀到几十 GB，每次恢复都要半小时。后来我加了个规则：Checkpoint 连续失败 2 次就自动报警，别等第三次。
Checkpoint 的关键配置，我整理了一张表：
| 参数 | 推荐值 | 说明 |
|---|---|---|
execution.checkpointing.interval |
30s ~ 5min | 间隔太短会频繁触发，影响性能；太长则恢复时间变长 |
execution.checkpointing.timeout |
10min | 超过这个时间还没完成，直接标记失败 |
execution.checkpointing.min-pause |
500ms | 两次 Checkpoint 之间的最小间隔，防止频繁触发 |
execution.checkpointing.tolerable-failure-number |
2 | 连续失败多少次后作业才失败，我一般设 2 |
注意： Checkpoint 不是越多越好。我见过有人把间隔设成 5 秒，结果状态后端（RocksDB）的写入压力直接拉满，背压飙升。你想想看，每 5 秒拍一次快照，磁盘 IO 能受得了吗？
2.2 背压：数据流的「堵车」信号
背压，就是下游处理不过来，上游还在拼命发数据。在 Flink Web UI 上，你能看到每个 Task 的背压状态：OK、LOW、HIGH。
怎么判断背压严重程度？我一般看这几个指标：
- 背压比例： 超过 50% 的 Task 处于 HIGH 状态，说明问题已经扩散了。
- 背压持续时间： 偶尔波动正常，但持续 5 分钟以上就要查原因。
- 背压来源： 是 Source 端还是 Sink 端？Source 端背压通常是下游处理慢，Sink 端背压通常是外部系统（比如 Kafka、HBase）响应慢。
我曾经遇到过一个案例：Kafka Sink 的批次大小设得太小，导致频繁网络请求，背压直接拉满。后来把 batch.size 从 1KB 调到 16KB，背压瞬间降下来了。
排查背压的步骤：
- 打开 Flink Web UI，看哪个 Operator 的背压是 HIGH。
- 点进去看「Back Pressure」Tab，确认是哪个 Subtask 卡住了。
- 查看该 Subtask 的 CPU 和内存使用率，判断是计算瓶颈还是 IO 瓶颈。
- 如果是 IO 瓶颈，检查下游系统（Kafka、HDFS、数据库）的响应时间。
2.3 延迟：数据新鲜度的「体温计」
延迟指标，说白了就是数据从进入 Flink 到处理完成，花了多长时间。对于实时数仓来说，延迟就是生命线。
Flink 提供了两种延迟指标：
- 端到端延迟： 从 Source 收到数据到 Sink 输出，整个链路的时间。
- 算子间延迟： 数据在两个连续 Operator 之间传递的时间。
我个人习惯重点监控端到端延迟。如果延迟突然从 5 秒涨到 30 秒，那肯定出事了。
我的建议： 在 Source 端给每条数据打上时间戳，在 Sink 端计算差值。这样能精确知道延迟到底出在哪个环节。我曾经用这个办法，发现是某个 UDF 里调了个慢 SQL，每次查询要 2 秒，直接把延迟拉高了。
延迟的监控方式：
| 指标 | 获取方式 | 告警阈值 |
|---|---|---|
| 端到端延迟 | 自定义 Metrics + 时间戳 | 超过业务 SLA 的 1.5 倍 |
| 算子间延迟 | latencyTrackingInterval 配置 |
超过 10 秒 |
| Watermark 延迟 | Flink Web UI 的 Watermark 线 | Watermark 停滞超过 30 秒 |
2.4 吞吐量：作业的「马力」
吞吐量，就是单位时间内处理了多少条数据。这个指标直接反映了作业的处理能力。
Flink Web UI 上能看到每个 Operator 的 numRecordsInPerSecond 和 numRecordsOutPerSecond。我一般关注两个点：
- 吞吐量是否稳定： 如果忽高忽低，说明作业在处理上存在波动，可能是数据倾斜或资源争抢。
- 吞吐量是否达到预期： 比如你期望每秒处理 10 万条，结果只有 2 万条，那就要查原因了。
吞吐量下降的常见原因：
- 数据倾斜： 某个 Key 的数据量特别大，导致单个 Subtask 成为瓶颈。
- 背压： 下游处理不过来，上游自然就慢了。
- GC 频繁： JVM 的 Full GC 会导致作业暂停，吞吐量瞬间掉到 0。
- 外部系统抖动： Kafka 分区 leader 切换、HBase region 分裂，都会导致吞吐量波动。
避坑指南： 我曾经遇到一个作业，吞吐量从 8 万/s 掉到 1 万/s，查了半天发现是 Kafka 消费组的 rebalance 导致的。因为某个消费者挂了，触发 rebalance，整个消费组暂停了 30 秒。从那以后，我每次上线都会检查消费者组的稳定性。
2.5 资源利用率：集群的「体检报告」
资源利用率包括 CPU、内存、网络、磁盘 IO。这四个指标，任何一个出问题，都会影响作业的稳定性。
我一般这样看：
- CPU 利用率： 正常在 60% ~ 80%。超过 90% 说明计算压力大，低于 20% 说明资源浪费。
- 内存利用率： 注意区分堆内和堆外内存。堆外内存泄漏是 Flink 的常见问题。
- 网络 IO： 如果网络带宽打满，说明数据 shuffle 量太大，或者数据倾斜严重。
- 磁盘 IO： RocksDB 的状态后端对磁盘 IO 很敏感。IO 等待时间超过 50ms，就要考虑优化了。
资源利用率异常排查清单：
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| CPU 100% | 计算密集型 UDF、数据倾斜 | 检查算子链、优化 UDF、调整并行度 |
| 内存 OOM | 状态膨胀、堆外内存泄漏 | 检查状态大小、调整 taskmanager.memory 配置 |
| 网络打满 | 数据 shuffle 量大、广播变量过大 | 优化分区策略、减少广播数据 |
| 磁盘 IO 高 | RocksDB 写入频繁、Checkpoint 太密集 | 调整 Checkpoint 间隔、优化 RocksDB 配置 |
嗯，这五个指标讲完了。你可能会问：这么多指标，我该先看哪个？
我的习惯是：先看背压，再看 Checkpoint，然后看延迟和吞吐量，最后看资源利用率。背压是「症状」，Checkpoint 是「底线」，延迟和吞吐量是「效果」，资源利用率是「根因」。按这个顺序排查，基本不会漏。
一个小技巧： 把五个指标做成一个 Dashboard，放在大屏上。我团队里就有一块屏幕专门显示这些指标，颜色变了就有人去看。说白了，监控不是为了事后复盘，而是为了在出事前发现问题。