任务上线与运维：跑起来只是开始

# Step 1: 打Savepoint并停止
flink stop --savepointPath hdfs:///flink/savepoints <jobId>
# 这个命令会先触发Savepoint，成功后再停任务

# Step 2: 部署新版本JAR

# Step 3: 从Savepoint恢复
flink run -s hdfs:///flink/savepoints/savepoint-xxx \
    -c com.example.MyJob new-version.jar

# 如果新版有问题：
flink run -s hdfs:///flink/savepoints/savepoint-xxx \
    -c com.example.MyJob old-version.jar  # 用旧JAR从同一个Savepoint恢复

# 常用监控方案
Flink Metrics → Prometheus → Grafana看板

# 关键Grafana面板：
- Checkpoint Duration & Success Rate
- Kafka Consumer Lag (per partition)
- Task Back Pressure Level
- Throughput (records/s)
- JVM Heap Usage / GC Time

我们用Prometheus + Grafana监控，钉钉/飞书机器人发告警。Checkpoint连续失败3次或消费延迟超过10万条直接告警到手机。

故障处理手册

故障	排查步骤	常见原因
任务重启	看TaskManager日志	OOM / NullPointer / 网络
Checkpoint超时	看State大小和反压	State太大 / 反压导致Barrier卡住
消费延迟增大	看反压和吞吐量	数据量突增 / 下游慢 / 倾斜
数据不一致	对比上下游数据量	迟到数据 / Sink幂等没做好

实战：Checkpoint连续失败

排查流程：
1. 看Checkpoint日志 → 是超时还是异常
2. 超时 → State太大（加增量Checkpoint/设TTL）
        → 反压导致Barrier对齐慢（排查反压源）
3. 异常 → HDFS不可用（检查存储集群）
        → 序列化报错（检查State的类变更是否兼容）

经历过一次Checkpoint连续失败12小时没人发现（当时没配告警）。最后TaskManager磁盘满了任务挂了，从2小时前的最后一个成功Checkpoint恢复，中间有数据重复。从此Checkpoint失败必须秒级告警。

面试加分提示

💡 展示完整的运维意识：

「上线前先打Savepoint，从Savepoint恢复新版。有问题回滚到旧版也从同一个Savepoint恢复。

日常监控四个核心指标：Checkpoint耗时和成功率、Kafka消费延迟、反压、吞吐量。用Prometheus+Grafana看板，连续失败秒级告警。

踩过一次Checkpoint失败12小时没发现的坑，从此告警配置是上线SOP的必检项。」

📌 总结

记忆点	内容
上线SOP	打Savepoint → 停旧版 → 部署新版 → 从Savepoint恢复
stop vs cancel	stop先Savepoint再停（推荐），cancel直接杀
四大指标	CP耗时/CP失败/消费延迟/反压
监控方案	Flink Metrics → Prometheus → Grafana
故障第一步	看TaskManager日志

▶ 下一篇预告：DAY 19 Flink vs Spark Streaming

---

Wood聊大数据 | 9年大数据老兵，聊技术、聊职场、聊成长

---

小红书正文

Flink任务跑起来只是开始。上线运维才是真功夫。

上线SOP：打Savepoint→停旧版→部署新版→从Savepoint恢复。回滚也从同一个Savepoint恢复。千万别直接cancel再上新版。

监控四大指标：Checkpoint耗时和成功率、Kafka消费延迟、反压、吞吐量。用Prometheus+Grafana看板。

我踩过的坑：Checkpoint连续失败12小时没人发现，最后磁盘满了任务挂了，丢了2小时数据。从此Checkpoint失败秒级告警。

另一次坑：忘了打Savepoint直接kill，新版有Bug回滚时没有恢复点。从此SOP第一步就是Savepoint。