Flink线上故障排查手册：Checkpoint超时、数据倾斜与Kafka积压实战

做Flink实时计算的，线上肯定碰到过这几件事：任务刚上线跑得好好的，半夜突然发现Checkpoint超时报警；或者某个作业隔几个小时就自动重启一次；再或者Kafka消费Lag一直涨，下游报表越差越远；还有一个最经典的，明明并行度调到了32，某个TaskManager累死累活，其他全在摸鱼。

这四个问题几乎占了Flink线上故障的八成以上。Day19-20这两天，我把过去几年在真实环境里踩过的坑、排查过的故障、调优过的参数，系统梳理成一套可以直接照着操作的排查手册。这篇内容适合正在维护Flink生产作业的开发者、刚接手实时数仓的运维同学，也适合那些在本地能跑通、一上集群就各种毛病的自学者。我会把这些故障背后的原理讲清楚，更重要的是告诉你每一步该点哪里、看哪个指标、改哪个参数。

1. 线上故障排查的总体思路：先别急着重启，先定位问题

1.1 故障排查的正确打开方式

遇到线上告警，新人最容易犯的错误是盯着日志看半天，然后冲动地把作业停掉重启。这在大促或者核心数据链路里往往会把小问题变成大事故。我个人的习惯是先在监控面板上花两分钟看一圈，弄清楚这个故障属于哪一类，再动手。

Flink线上故障虽然表现五花八门，但本质可以归为四类：

• 作业无法正常推进，典型症状是Checkpoint超时、任务长时间处于RUNNING但数据不往下走。
• 作业反复重启，表现为Restart次数飙升、TaskManager反复拉起、作业周期性失败。
• 数据处理延迟，最直观的是Kafka消费组Lag持续上涨，实时链路越跑越慢。
• 资源分配失衡，单个TaskManager负载极高、其他节点空闲，数据倾斜后的必然结果。

实际排查时，很多故障是互相纠缠的。比如数据倾斜会导致某个Subtask处理不过来，形成反压，反压传导到Source端，Kafka消费就停滞，Lag上涨，又会影响Checkpoint对齐时间，最终触发CK超时。所以我会先看监控大盘里的三个核心指标：反压状态、Checkpoint耗时、Kafka消费Lag。通过这三个指标的组合，基本能判断出问题的大方向。

1.2 事故现场保留与信息收集

很多线上问题难查，是因为现场已经被破坏了。比如作业自动重启之后，内存里的状态丢了，一些临时性的异常堆栈被冲掉。我强烈建议在排查之前先做好现场信息收集：

• 开启JobManager和TaskManager的日志持久化，别只打到容器标准输出里，一定要落盘，并且按天滚动保留至少7天。
• 监控面板把Checkpoint历史、反压比例、GC耗时、Kafka消费位点这几个指标全部截图存下来，时间范围至少覆盖故障发生前后各30分钟。
• 如果故障和某个数据变更有关，比如上游改了Topic格式、新增了枚举值、下游数据库连接爆了，把这些变更记录也整理出来。

有了这些信息，即使一时半会儿找不到根因，也能在问题复现后快速对比。我自己就被坑过很多次：作业重启后日志被冲掉，结果只能靠模糊记忆排查，效率极低。

1.3 一套好用的排查路径

我总结了一套固定的排查顺序，按照这个顺序走，绝大多数故障能在半小时内找到方向：

1. 先看Flink Web UI的Overview和Job Graph，确定哪些Task处于异常或反压状态。
2. 点进异常的Task，看BackPressure状态和忙闲百分比。
3. 打开对应TaskManager的日志，搜索ERROR、Exception、OutOfMemory、Checkpoint timeout关键字。
4. 去监控大盘看该作业的Checkpoint耗时曲线、重启次数曲线、Kafka消费Lag曲线，对比它们的变动时间点。
5. 结合上游数据量和资源水位，判断是临时抖动还是持续性问题。

这里有一个很重要的原则：永远不要只凭单个指标下结论。比如Checkpoint超时，可能是因为磁盘慢，也可能是因为反压，还可能是状态太大。必须结合反压状态和GC曲线综合判断。

2. Checkpoint超时排查：状态、反压、磁盘必须一起看

2.1 Checkpoint超时的内在逻辑

Flink的Checkpoint机制，简单理解就是定期给整个作业的状态拍一张快照，保存到外部存储里。Coordinator发起一轮Checkpoint后，会向所有Source注入Barrier，Barrier在算子间流动，每个算子看到Barrier就对自己的状态进行快照。只有所有算子都完成快照并确认给Coordinator，这一轮Checkpoint才算完成。

Checkpoint超时就是整个快照流程没在限定时间内结束。导致超时的环节可以是Barrier传播被阻塞、某个算子状态快照太慢、或者快照数据写外部存储太慢。每种原因对应的症状和排查方法都不一样，必须拆开来看。

2.2 反压导致Barrier无法推进

这是我在线上遇到最多的CK超时原因。Barrier是按数据流传播的，如果某个算子背上了反压，数据在缓冲区里排队，Barrier就会跟着堵在那里，后面的算子迟迟收不到Barrier，整个Checkpoint就一直处于进行中，直到超时。

判断方法很直接：在Web UI里看该作业的BackPressure列，如果某个Task显示HIGH，再点进去看该Task下各Subtask的忙闲百分比。忙闲百分比表示这个Subtask有数据可处理的时间占比，如果长时间接近100%而吞吐上不去，说明算子处理能力到顶了。

反压的根因又分几类：一是上游数据量突增，比如大促、活动、上游漏跑任务导致积压数据集中下发；二是算子本身计算复杂度高，比如自定义函数里做了大量的正则解析或循环计算；三是下游写入慢，典型场景是写入关系型数据库时连接池耗尽或批量写超时。

处理反压的思路不是盲目调大并行度，而是找到瓶颈算子。我的做法是在Web UI上看各算子每秒处理记录数和延迟曲线，处理量上不去且延迟持续增加的算子就是瓶颈。然后针对瓶颈做三件事：优化算子内部计算逻辑，把重计算拆成异步或预计算；调整并行度，并考虑上游Source分区数是否匹配；下游写入改成批量异步模式，减少同步等待时间。

2.3 状态快照或外部存储太慢

如果反压指标正常，但Checkpoint依然超时，问题很可能出在状态后端和存储上。当前常用的状态后端有RocksDB和Heap状态后端。RocksDB存在本地磁盘，Checkpoint时需要把增量或全量数据写到远程存储，比如分布式文件系统或对象存储。

磁盘慢是最容易被忽视的罪魁祸首。很多人把状态存储目录放在系统盘，或者本地磁盘本身是普通的机械盘，状态一多写盘速度直接崩掉。排查时用iostat看一眼TaskManager节点的磁盘IO使用率，如果长时间打满，就得考虑换SSD，或者把state.backend.rocksdb.localdir指定到性能更好的盘符上。

远程存储的稳定性同样关键。分布式文件系统或对象存储如果出现性能抖动，也会让Checkpoint写入超时。我遇到过集群中某个节点网络异常导致写块超时，连带多个作业的Checkpoint集体失败。这种问题需要和运维配合，看存储服务端的监控指标，客户端侧能做的有限，但可以调整这些参数来缓解：

• checkpoint.start-delay：控制两次Checkpoint之间的最小间隔，避免存储抖动时重复密集提交。
• checkpoint.timeout：根据历史耗时合理设置，不要把超时时间设得太短，一般建议是正常Checkpoint耗时的3到5倍。
• checkpoint.max-concurrent-checkpoints：生产环境建议保持为1，并发Checkpoint取快照时对资源的抢占非常严重。

再补充一个容易被忽略的点：Checkpoint超时后，如果开启了checkpoint.retention策略，旧的Checkpoint会不断堆积，存储空间不够时又会引发新一轮失败。建议运维定期清理历史Checkpoint，同时把state.checkpoints.num-retained设置为合适的值。

2.4 GC耗时和内存分配的影响

JVM GC也会导致Checkpoint超时。如果TaskManager堆内存设置不合理，Full GC频繁且单次耗时很长，算子在STW期间无法处理数据，Barrier自然被卡住。这种情况在Heap状态后端下尤其明显。

排查GC问题看GarbageCollector监控，关注Full GC次数和耗时。如果发现频繁Full GC，优先检查TaskManager内存配置。生产环境建议给JVM预留足够直接内存和元空间，堆内存给到合理水位，避免对象在堆内大量复制和频繁晋升。

如果GC很严重，换RocksDB状态后端能显著缓解。RocksDB把状态存到堆外和本地磁盘，对象不占JVM堆内存，GC压力会小很多。这也是为什么大状态作业我一般都会优先考虑RocksDB。

对于需要频繁更新且状态量很大的场景，还可以调整RocksDB本身的参数，比如block cache大小、write buffer数量。不过这些参数对排查Checkpoint超时属于进阶调优，建议在确认是状态压力导致之后再动，不是第一优先级。

3. 任务频繁重启的常见诱因与止损策略

3.1 任务重启的几类典型原因

任务重启分两种：主动重启和被动重启。主动重启一般是因为运维需要升级代码或调整资源。被动重启才是我们排查的重头，原因主要集中在应用异常、资源限制和外部依赖故障三方面。

应用异常最常见的两类：代码里抛出了未捕获的RuntimeException，导致Task线程退出；另一个是状态结构不兼容，比如修改了ValueState的泛型类型，或者用了RocksDB状态后端时版本升级导致状态无法恢复。这类问题的特征是重启后很快再次失败，反复循环。排查时直接看TaskManager日志里的异常堆栈，十有八九能在前三条日志里找到根因。

资源限制导致的被动重启，典型场景是容器内存超限被Kill。具体来说，TaskManager实际使用的物理内存超过了容器上限，被底层资源调度器强制杀掉，作业整体Failover。这种问题在日志里往往看不到Java堆栈，只看到Container killed by exceeding memory limits之类的提示。处理方法要么调大容器内存，要么检查代码里是否有大对象缓存、大量本地聚合导致堆外内存膨胀。

第三方依赖故障一般体现在重启周期不规律，可能运行几小时甚至几天才失败一次。比如下游HBase连接因为空闲被服务端断开，连接池没有重建机制；或者Redis连接超时没有设置重试逻辑。这类问题要看fault-tolerance的崩溃频率和对应时间的下游系统监控。

3.2 用重启策略和自动恢复兜底

线上作业的风险不可完全消除，但我们可以用重启策略兜底，防止作业在临时故障后一直处于失败状态。

Flink支持三种重启策略：fixed-delay、failure-rate、exponential-delay。我的生产实践是给不同作业配置不同策略。核心数据链路用exponential-delay，重试间隔从几秒逐步拉长，避免故障时集中重试把下游打挂；非核心作业用fixed-delay，给与固定间隔的恢复窗口。

配置方法可以在代码里指定：

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); env.setRestartStrategy( RestartStrategies.exponentialDelayRestart( Time.seconds(1), // 初始等待 Time.minutes(5), // 最大等待 2.0, // 指数系数 Time.hours(1) // 重置时间 ) );

如果作业完全不支持自动重启，比如状态恢复需要人工确认的，也可以把重启次数设为0，保证失败后直接进入FAILED状态，方便人工介入。不过这种策略只建议用在状态极其重要或需要精确一次语义的作业上，日常作业还是要有自动恢复能力。

3.3 从日志和指标里锁定崩溃根因

排查任务重启，第一现场永远是JobManager和TaskManager日志。我的排查顺序是：

1. 打开JobManager日志，找到最后一次全局Failover的时间和触发点。
2. 点开对应的TaskManager日志，搜索ERROR和Exception，尤其是堆栈的第一行。
3. 如果是进程被Kill，查看对应的容器状态和退出码。JVM主动OOM抛出的异常退出码通常是非零的，而容器资源限制杀掉的线程退出码会有特定标识。
4. 结合监控面板看进程启动时间线和内存曲线。如果内存在重启前一路爬升，大概率是内存泄漏或内存配置不足。

内存泄漏这块要特别说一句。实时作业里最常见的泄漏源有两个：一个是自定义函数里创建了未关闭的客户端，比如每来一条数据就new一个连接；另一个是使用外部缓存或静态Map，只放不放导致无限增长。这类问题在本地测试时量小不明显，线上跑到一定量级就会触发OOM或频繁Full GC。排查时用jmap或Arthas这类工具导一下堆转储，重点看哪些对象占用内存大、持有者是谁。

还有一个经常踩的坑：两个作业依赖了不同版本的同一第三方库，比如一个作业代码里用A库的1.8版本，另一个作业的依赖把A库升级到2.0，冲突后导致NoSuchMethodError。这种问题报错很直接，看日志就能定位。但要注意，别只看报错信息，还要看依赖树，找到底层冲突的包。

3.4 状态恢复失败导致的一类假重启

有一种任务重启不是真的因为处理逻辑挂了，而是状态恢复失败。常见场景是升级代码以后，状态结构变了，旧的快照无法映射到新的算子状态。比如原来用一个MapState存配置，后来改成了ValueState，重启后状态恢复直接报类型不兼容。

这类问题的排查关键是搞清楚状态在哪个算子、状态名是什么、序列化器是什么。Flink的状态恢复失败日志里通常有明确提示，指向具体算子和状态名。生产上建议对状态结构的变更提前规划兼容性，能不改变状态结构就不改，非要改的就换新状态名，配合状态TTL做平滑迁移。

状态恢复失败的另一个隐患是Checkpoint文件损坏或存储路径变更。比如运维迁移了分布式文件系统，但新目录没有给作业配置访问权限，恢复时直接报FileSystem错误。排查这类问题时，我还见过因为存储上有定期清理策略，把还很新的Checkpoint文件清掉了，导致恢复失败。建议检查存储侧的保留策略和作业侧checkpoint保留设置，保持一致。

4. Kafka积压排查：Lag上涨要看消费端和分配策略

4.1 积压的定义和监控方式

所谓Kafka积压，直观表现就是Topic分区的最新增量位点和Flink消费组提交位点之间的差值持续扩大。在实时数仓里，这个指标通常用消费组Lag来表示。Lag长期不下降，说明消费速度跟不上生产速度，数据延迟无法收敛。

监控方式有两种：一种是通过Kafka自带工具查看消费组位点，另一种是在Flink作业的监控面板里看Kafka Consumer的指标。第一种方法适合排查消费组到底慢在哪，第二种方法适合和Flink作业内部状态关联分析。我建议两边都看，Flink侧指标能看到每个并行实例各自的消费情况，Kafka侧指标能看到整条链路位的整体滞后。

Kafka Lag上涨不代表一定是Flink消费慢。上游生产突发、Topic分区数过少、消费端反压、Flink检查点卡住，都可能导致Lag爬升。所以排查的第一个动作是确定Lag上涨的时间点，和上游生产速率曲线对比。如果上游速率没涨，那问题一定在消费链路内部。

4.2 消费能力不足和并行度不匹配

消费能力不足最直接的原因是并行度设置不合理。FlinkKafkaConsumer的并行实例数最多不能超过Topic分区数，如果并行度大于分区数，一部分实例会空闲。反过来，并行度远小于分区数，每个实例要消费多个分区，吞吐自然受限。

我在确定并行度时一般遵循一个经验公式：先看单分区在测试环境能达到的最大消费速率，然后用生产环境目标吞吐量去除，得出理论分区数或并行度需求，再留30%-50%的冗余。比如单分区能消费2000条每秒，生产目标是一分钟300万条，大约需要25个分区，并行度我给到32。

除了并行度，还有拉取参数。默认的fetch.max.bytes和小批量poll策略在数据量大时会有明显性能开销。可以适当调大：

Properties props = new Properties(); props.setProperty("fetch.max.bytes", "104857600"); // 单次拉取最大100MB props.setProperty("fetch.max.wait.ms", "500"); props.setProperty("max.partition.fetch.bytes", "20971520");

但要注意，盲目调大拉取字节数可能导致单次处理时间变长，Checkpoint间隔内的数据量变大，反而影响状态对齐时间。参数调整后必须观察两个指标：单条Record处理耗时和Checkpoint耗时，找到一个均衡点。

4.3 反压造成消费停滞

FlinkKafkaConsumer消费数据是单线程事件驱动的。Source拉取到数据后，会在内部管道向下游发送，这个发送过程是异步的。如果下游算子处理不过来，数据会在Source的发送缓冲区积压，KafkaConsumer的下一次拉取自然被阻塞。这种现象在Web UI上表现为Kafka Source节点出现反压。

反压造成的消费停滞，本质上还是下游算子或写入端的问题。排查路径就是前面聊过的：看哪个算子反压最高、忙闲百分比最接近100%，从那里入手。但有一个东西特别值得检查，就是下游Sink的写入性能。实时链路里最常见的情况就是Flink处理很快，结果写入下游数据库的时候卡住，批量写超时、连接池耗尽、表锁竞争，每一种都够RPA层和Sink层之间卡半天。

Sink写入慢的解决办法我常用的有三种：第一，开启批量写入模式，积累一定条数或一定时间后再批量下发；第二，把同步写入改成异步写入，用异步I/O算子包裹Sink逻辑，让多个写入请求并发执行；第三，优化Sink端的目标存储，比如建表加索引、调整批量提交大小、增加写入实例数。其中第一和第二个方案实施成本低，效果立竿见影。

4.4 脏数据和异常处理阻塞消费

Kafka积压还有一个非常隐蔽的原因：脏数据。比如上游Topic里出现了前所未有的异常字段格式，下游解析函数直接报错，如果不捕获异常，任务会挂在某一条数据上反复处理。更麻烦的是那些不抛异常但在逻辑上处理极慢的数据，比如一条消息里包含一个几十MB的超大字段，反序列化阶段耗时暴涨。

我的习惯是给所有数据解析和Transform阶段设置保护逻辑：

• 反序列化时捕获异常，格式化字符串校验，非法数据输出到侧输出流或单独的死信Topic，不让它阻塞主链路。
• 对超大字段做截断或剥离，只保留需要的部分。
• 对可能存在慢处理逻辑的字段值设计白名单或黑名单机制，比如某枚举值导致外部服务调用卡住，直接短路。

脏数据处理完后，积压问题往往自然恢复。但这里有一个循环依赖：数据已经积压很多了，消费端恢复后要处理的历史数据里可能还有大量脏数据，处理速度会比平时慢。我的做法是先定位脏数据的源头特征，比如某个字段的特定取值，在代码里临时过滤掉，让Lag尽快追平，之后再由专门脚本去补处理这些数据。

5. 数据倾斜排查与实战解法

5.1 倾斜的表现形式和定位方法

数据倾斜在Flink作业里的表现很直白：某个Task的多个Subtask中，有一个或几个节点的忙闲百分比长期打满，处理记录数远高于同Task的其他节点。但下游或状态数据延迟增长时，第一个该怀疑的就是倾斜。

定位倾斜最方便的方式是Web UI。进入某个算子的详情页，看每个Subtask的Bytes Received、Records Sent、忙闲百分比这几个字段。如果数值差异超过好几倍，比如某个Subtask每秒处理10万条，其他Subtask只有1万条，倾斜实锤。

另一种定位方式是通过反压趋势。倾斜的Subtask往往会持续反压，而且反压不会跟着整体负载变化而变化，而是稳定地出现在固定的Subtask上。这种特征非常明显。

5.2 keyBy热点和加盐方案

最常见的倾斜场景是keyBy操作。比如订单数据按订单ID做keyBy理论上分布均匀，但如果业务实现里不小心把某些字段值设成了固定默认值，等于所有数据全部打到同一个Key上，对应的Subtask直接被打爆。这种问题在SQL作业里尤其隐蔽，因为SQL层看不到真实的Key分布。

解决办法是加盐。简单说就是对Key进行二次改造，让它分布到更多分区上。以订单数据为例，如果按用户ID聚合，可以把用户ID加上一个随机数后缀，比如0到N之间的随机值，这样每个用户的数据会被分散到N个分组里。但这会破坏同一个用户的完整聚合语义，所以加盐后必须做两阶段聚合：

• 第一阶段，对加盐后的Key做局部聚合，得到局部的中间结果。
• 第二阶段，去掉盐值，对原始Key再做一次合并聚合，输出最终结果。

Flink SQL里面可以这么写：

-- 第一阶段：加盐局部聚合 CREATE VIEW tmp AS SELECT user_id, COUNT(*) AS cnt, (RANDOM(10) + user_id) AS salted_key FROM source_table GROUP BY user_id, salted_key; -- 第二阶段：去盐全局聚合 SELECT user_id, SUM(cnt) AS total_cnt FROM tmp GROUP BY user_id;

这里需要注意，加盐之后的聚合结果不是精确的，如果业务上必须精确去重，比如统计UV，两阶段聚合在出现相同元素分散到不同盐值分组时会产生重复计数。这时候就要考虑用HyperLogLog或者布隆过滤器这类近似数据结构，或者把去重字段单独提取出来做精确去重计算。

加盐粒度也不能太随意。盐值N越大，分区越均匀，但第二阶段聚合时产生的中间文件或状态越多。实践中我一般把盐值设置在50到200之间，具体看倾斜严重程度和集群资源情况。

5.3 Join和窗口聚合的倾斜解法

双流Join的倾斜通常出现在右表某个Key的数据量极大，导致关联时左表所有数据都要等这个热门Key处理。这种情况下加盐思路依然适用，但操作上要更小心，因为Join的关联条件改了会影响结果正确性。

我的做法分两种场景：

• 如果其中一个流是维度数据，量级不大但更新频繁，可以直接做成广播流，让所有Subtask都持有完整的维度数据。这样Join时不用做网络Shuffle，每个节点本地处理，天然消除倾斜。
• 如果两个流的数据量都很大，且倾斜Key不多，可以把倾斜Key单独识别出来，走一条特殊处理路径，非倾斜Key走正常Join路径，最后再合并结果。这个方案需要业务上能区分哪些Key是热Key，可以在上游用采样或计数的方式动态获取。

窗口聚合的倾斜也很常见，尤其是事件时间窗口。比如某个热门门店在窗口结束时有大量数据集中触发计算，其他门店数据少。这种倾斜和keyBy倾斜不同的是，窗口内的数据在窗口触发前都攒在状态里，倾斜的Key对应状态更大，窗口触发时计算量也大。

解决窗口倾斜，一个是错峰触发，把窗口的计算尽量分散到多个Subtask；另一个是用增量聚合函数代替全量聚合函数，比如使用AggregateFunction而不是仅仅用ProcessWindowFunction。增量聚合会在每条数据到达时就更新中间状态，窗口触发时只需输出结果，计算压力大幅度降低。如果业务要求窗口结束才看到结果，也可以在窗口触发时直接输出增量聚合后的值，不用在触发时遍历全量数据。

5.4 自定义分区器兜底

如果业务逻辑复杂，加盐和广播都解决不了，最后的方案是实现自定义Partitioner。Flink的DataStream API里可以指定分区器，控制数据在上下游算子之间的分发方式：

dataStream .partitionCustom(new MyPartitioner(), new KeySelector<...>() { // 返回自定义分区字段 }) .process(...);

自定义Partitioner的逻辑一般是先分析Key的历史分布，把高频Key尽量分散到多个并行实例上，低频Key保持正常分配。但要注意，自定义分区器一旦用上，等于放弃了KeyedStream本身的语义，状态和聚合逻辑都要用别的方式维护，复杂度会上升一个级别。所以我只在需求明确且前几种方案无效时才用。

无论用哪个方案，解决倾斜的最后一步都是验证效果。我的验收标准很简单：看原来繁忙的Subtask忙闲百分比有没有降下来，各Subtask的Records Sent是否趋于均衡，然后观察整个作业的端到端延迟有没有回到基线。

6. 故障排查速查表与经验沉淀

6.1 常见问题一页速查

下面这张表是我整理故障排查笔记时留下的核心速查内容。每一条都对应了生产环境里真实遇到过的情况，排查命令和参考配置可以直接拿来用。

6.2 我踩过的几个隐蔽深坑

排查类文章最容易写一堆理论然后实操时发现完全对不上，这里列几个我真实踩过的坑。

第一个坑：Flink Web UI的BackPressure统计只有最近几次采样，偶尔会显示正常，但实际业务已经是强反压了。所以不能只信那个红绿灯，还要看忙闲百分比和延迟指标，多个指标相互印证。

第二个坑：Kafka消费Lag在高吞吐场景下有抖动。Topic分区数很多时，Kafka的Offset查询可能延迟好几十秒，Lag曲线看着一直在涨，过一会儿又跌下来。这种短期波动不要慌，把窗口拉长到5分钟以上看趋势，别被瞬时值吓到。

第三个坑：JobManager日志和TaskManager日志分开存储后，很多人只关注JobManager里的Failover信息，忽略了真正执行任务的是TaskManager。有些异常只在TaskManager侧打印，比如OOM堆栈、连接超时堆栈。我的排查习惯是JobManager负责看全局恢复路径，TaskManager负责看具体根因，两边都必须翻。

第四个坑：RocksDB状态后端有本地磁盘损坏导致状态读写异常的情况。这种故障日志里可能只出现RocksDBException，但实际根因是磁盘坏道或inode耗尽。排查时不能只看Flink自身日志，也要查节点磁盘状态和系统日志。

6.3 一套长期有效的防线

故障排查不能只靠出问题时灵光一现，更重要的是日常建立防线，把故障扼杀在摇篮里。

监控告警层面，我建议至少覆盖这些指标：Checkpoint时长和失败率、TaskManager存活数、每个Task的反压状态、Kafka消费Lag、JVM内存和GC。告警阈值要分级别，两级告警适合，比如Checkpoint超时超过5分钟发严重告警，超过3分钟发警告。告警要带上作业名和具体Task信息，别让值班同学还要手动查是哪个作业在报。

稳定性建设层面，代码里一定要把异常捕获和容错做扎实。自定义函数里对每条数据的处理都要有兜底逻辑，该捕获的异常捕获，该记录侧输出的记录，该跳过的跳过。连接器等资源要使用带重试逻辑的连接池，避免单次网络抖动直接把任务拖垮。

复盘机制也很重要。每次线上故障解决后，我做的第一件事就是更新速查表，把新问题、新排查手段、新配置参数补进去。这套速查表是团队最宝贵的资产，时间越长越全面，排查效率也越高。

回头看这20天，Flink的核心概念、开发API、状态管理、窗口计算这些基本功大家都学得差不多了，但从能写代码到能稳定跑生产，中间隔着的正是这些故障排查的经验。CK超时、任务重启、Kafka积压、数据倾斜，每一项单独拎出来都不算特别难，难的是在一堆表象里快速找到真正的根因。我个人体会是，平时多用沙箱环境和压测工具故意制造故障，把监控面板的各种曲线变化记在心里，真到线上出问题时，你看到监控的第一眼就已经能锁定个大概方向了。