Flink Web UI 实战：从作业监控到反压与 Checkpoint 排查

我见过不少搞 Flink 的同学集群跑了半年Flink Web UI 基本只用来判断作业是绿还是红绿色万事大吉红色就去翻日志。这其实挺浪费的。Flink Web UI 里的每个菜单包括那些平时不常点的入口都是围绕排障设计的——作业是否健康、反压到底压在哪、Checkpoint 为什么失败、CPU 热点在哪个算子上都能在页面上一步步下钻定位。这篇文章我按实际使用顺序把 Flink Web UI 的几个核心功能拆开讲同时把生产环境里踩过的坑和验证过的排查路线一起放进去。内容默认以 Flink 1.14 之后的新版 UI 为主。旧版1.13 及以前菜单名和样式略有差异但背后的信息逻辑没变对照着看也能用。1. 从提交作业开始理解 Web UI 的信息组织逻辑先说一个容易忽略的点Flink Web UI 不是个简单的“作业红绿灯”它的信息组织是分层的。理解不了层级就会觉得菜单又多又乱。1.1 Web UI 的信息层级从集群到作业再到算子默认情况下打开http://jobmanager-host:8081就能访问 Web UI。如果配了 HA要访问的是当前 Active 的 JobManager生产环境一般会在前面挂负载均衡直接配置域名访问。新版的侧边栏有这些入口Jobs Overview、Job Manager、Task Managers、Submit Job、Configuration。Dashboard 首页会显示集群级别的信息比如 Available Task Managers、可用 Slots 数量、当前各状态作业的数量。从排查角度看UI 信息可以分成三层集群层Dashboard 和 Task Managers 页面回答“资源够不够”的问题。作业提交后一直卡在 SCHEDULED大概率要回到这层查资源。作业层Jobs Overview以及单个作业的 Overview、Exceptions、Time Line 页面回答“作业整体是否健康”的问题。算子层Job Graph、Subtasks、Backpressure、Checkpoints、火焰图回答“瓶颈在哪、为什么失败”的问题。实际排查时你经常是反着走的先看到作业层报警再进算子层定位最后回到集群层看资源和日志。这个大脑里的地图先建立起来后面每个菜单就不会是孤立的功能。还有一个版本相关的重要提醒Web UI 默认只展示当前 JobManager 内存里保留的作业信息。如果 JobManager 重启了又没有单独跑 HistoryServer历史作业的列表和详情都会消失。生产上只要作业量大建议把 HistoryServer 配置上否则线上出问题后想回看几天前的作业状态会发现什么都查不到。1.2 提交作业的三种姿势以及 UI 提交的那些坑提交作业常用的有三种方式Web UI 上传 JAR、命令行flink run、通过代码调用RestClusterClient提交。Web UI 的 Submit Job 页面很直观选择 JAR 文件填 Main Class、程序参数、并行度点提交就行。但我实际用下来UI 提交更适合临时调试。JAR 体积大或者依赖多的时候容易碰到 HTTP 上传超时或者后端提示 413 Request Entity Too Large。这些错误往往不会在作业列表里留下明显痕迹你只看到提交动作失败。命令行提交是生产环境的主流方式flink run -d -m yarn-cluster -p 4 \ -c com.example.MainJob \ /path/your-job.jar \ --checkpoint-interval 60000用-m指定集群模式-d表示 detach 模式提交后不会在前台挂住。K8s 模式下的-m参数会有所不同但思路一致。第三种方式是在自己的平台代码里封装RestClusterClient本质上也是调用 REST API。适合要做可视化提交平台的公司自由度最高但要自己处理 JAR 管理、参数序列化等一堆细节。关于 UI 提交有两个值得注意的坑第一个是参数编码。我在某些版本上遇到过程序参数里带中文或空格时经过 UI 表单提交后可能出现转义异常导致作业启动时参数被截断。命令行方式反而没这个问题。第二个是提交成功不代表作业初始化成功。UI 显示提交完成后如果作业在 TaskManager 上初始化失败比如依赖类找不到、反序列化失败作业列表里确实能看到它但状态会快速变成 FAILED。这时候要到作业详情和 TaskManager 日志里查而不是停留在提交页面反复试。2. 作业列表页与作业详情页一屏看懂作业健康状况作业提交上去之后日常工作基本就围绕 Jobs Overview 和单个作业的详情页展开了。2.1 列表页的状态、时间与 Task 列Jobs Overview 列表页展示的是所有作业的概要信息重点看这几列Job ID24 位十六进制字符串。这个 ID 在日志、REST API、命令行里都会用到排查问题时要能快速复制。Name作业名称。这里务必注意作业名称默认是 JAR 包名如果你不显式设置生产环境几十个作业全叫flink-starter根本分不清谁是谁。推荐在代码里用env.execute(订单实时标签-1.2.0)这样带业务含义和版本号的名称。Status作业当前状态。RUNNING 绿色、FAILED 红色、CANCELED 灰色、FINISHED 蓝色或灰色不同版本颜色有差异这些颜色只是结果关键要看状态持续了多久。Duration运行时长。我曾见过一个作业 Duration 显示 7 天但实际在反复重启原因在于用户配了无限重启策略每次失败后快速恢复Duration 一直在累计。只看颜色会误判它是健康的。Tasks显示作业的 Task 总数和当前状态数类似1/2 running。如果长时间停在0/2 running说明有子任务卡在 SCHEDULED集群资源可能不够或者 TM 注册存在问题。列表页有个实用小技巧按 Start Time 排序看同一时间段内是否有多个作业集体失败。如果一批作业在同一分钟挂了多半不是代码逻辑问题而是集群资源、上游 Kafka、HDFS 或某台 TM 节点故障这类全局因素。2.2 Overview 详情页作业健康度的第一视线点进任意作业默认落在 Overview 页。这里的信息密度很高我先说几个最值得关注的。状态区域会展示作业的当前状态和状态持续时长还有 JobManager 地址、提交时间、开始时间、结束时间。JobManager 地址在定位“这个作业到底跑在哪个节点上”时很有用。如果作业配置了自动重启Overview 上会显示 Restart 次数。Restart 次数不断增长说明作业在“隐性故障循环”里比如外部连接不稳定、内存不足触发反复失败。这个时候即使作业状态是 RUNNING也不能放心。Overview 上还有 Restart、Stop、Cancel 三个操作按钮。这里要特别提醒Stop 和 Cancel 不是一回事。Cancel 是立刻取消作业不会做优雅处理Stop 会尝试走 stop-with-savepoint 流程但能否成功依赖作业是否实现了相应接口、是否配置了 savepoint 路径。生产环境如果要保留状态建议用命令行flink stop或flink cancel -s savepointPath而不是在 UI 上点按钮。UI 上点错的成本极高一次误操作可能导致状态丢失需要从源头重置。Overview 页面底部通常还会显示 Checkpointing 相关的统计摘要比如最近一次 Checkpoint 是否成功、耗时多久、State 大小是多少。2.3 Exceptions 菜单异常不等于失败Exceptions 菜单展示作业运行过程中记录的异常信息按时间倒序排列每条都可以展开看堆栈。这个页面最大的价值是让你不登录 JobManager 和 TaskManager 就能快速扫一眼异常类型。但要注意Exceptions 里出现的异常并不代表作业已经失败。比如某个 Subtask 在尝试阶段连接外部系统超时会记录一条异常但后续重试成功了作业状态仍然是 RUNNING。所以你看到异常列表有内容时要先结合时间线看异常发生的时间点是否和作业的 Restarting、延迟增长、Checkpoint 失败对齐。另外UI 上的异常堆栈有时会被截断。分布式环境下完整的堆栈往往分散在对应 TaskManager 的日志里。我的习惯是先在 Exceptions 页面确定异常类型和发生算子然后去 TaskManager 的 Logs 页面捞完整堆栈确认 Caused by。还有一点作业一旦结束或重启异常列表会清空。线上遇到问题第一件事是截图和记录不要指望页面一直帮你保留现场。3. 调度时间线与 Job Graph定位瓶颈的第一步看完作业整体状态下一步就是定位瓶颈在哪个算子。Time Line 和 Job Graph 就是干这个的。3.1 用 Time Line 看调度延迟与资源竞争Time Line 以时间为横轴展示每个并行子任务的完整生命周期。每个子任务的状态会用不同颜色的色条标识比如 CREATED、SCHEDULED、RUNNING、FINISHED。这个页面的核心用法是看时间分布某个算子的所有子任务在 SCHEDULED 状态停留很久才进入 RUNNING说明 Slot 获取慢集群有空闲资源但分配不到。常见原因是 Slot 碎片化或者该作业的 slotSharingGroup 配置导致只能使用特定 TM 上的资源。并行子任务中大部分很快 FINISHED个别子任务的 RUNNING 时间特别长说明数据倾斜或者这个子任务在处理某些数据时卡住了比如外部 IO 阻塞、死循环。多个子任务同时启动但结束时间跨度很大常见于 Sink 写外部系统速度不均。新版 UI 的 Time Line 支持聚合视图在并行度很高时密密麻麻的色条没法看可以先聚合看整体趋势再用 Subtasks 页面定位具体子任务。3.2 Job Graph颜色、吞吐与节点操作的入口Job Graph 就是作业的 DAG 可视化。每个节点代表一个算子节点颜色对应运行状态。这里我不会让你记具体色值因为不同版本有差异但语义是通用的绿色表示运行中红色表示失败或异常灰色/蓝色表示已结束。Job Graph 真正的价值在于交互。点击某个节点右侧会弹出该算子的详情包括并行度、进出记录数、吞吐、当前反压状态等。生产排查时我习惯从 Source 节点往 Sink 节点逐个点过去重点看两个东西上下游吞吐是否匹配。比如 Source 每秒接收 10 万条而中间某个算子每秒只处理 2 万条瓶颈就在这里。节点上是否出现反压标记。如果 Sink 节点显示 HIGH backpressure但 Source 节点正常说明反压是下游外部系统写入慢引起的不是数据量本身的问题。要注意的是Job Graph 里的一个节点可能是多个算子 Chain 在一起的 Task。比如Source Map Filter合成了一个节点反压定位只能说定位到了这个 Task具体是哪个算子慢还要靠火焰图和日志进一步确认。Job Graph 也是进入 Subtasks 和其他菜单的入口从点节点开始逐步下钻这是最自然的排查路径。4. Subtasks 与 Backpressure反压排查的实战链路如果说 Job Graph 是宏观地图那 Subtasks 和 Backpressure 就是放大镜和听诊器。4.1 Subtasks并行度视角下的数据分布Subtasks 菜单展示每个算子的每个并行子任务明细表格列包括子任务 ID、状态、起止时间、Duration、接收/发送的字节数和记录数。这个菜单最直接的用途是判断数据倾斜。正常情况下一个算子各个子任务的 Records Received 是接近的。如果 20 个并行度里2 个子任务各收了 100 万条另外 18 个只收了 10 万条那基本可以断定是 keyBy 设计问题业务上的热点 key 全压到了少数子任务上。这里我要提醒一个反直觉的点即使 Records 相近也不代表没有瓶颈。有些算子会做重分区比如rebalance()会强制轮询分发数据量看起来均匀了但每个子任务的计算复杂度可能不一样——比如某个子任务拿到的数据全是需要查询外部系统的复杂记录处理时间自然更长。所以 Subtasks 要和 Duration 一起看Duration 差异大而 Records 差异小通常是单个子任务的计算路径有问题而不是数据分布问题。点击每个子任务进去还能看到这个子任务的 Attempts 列表。Attempt 次数多说明这个子任务经历过反复失败和重试即使当前是 RUNNING也要查一下历史失败原因。4.2 Backpressure 菜单从手动采样到状态判定Backpressure 菜单可能是整个 Web UI 里最有排查价值也最容易误用的页面。它的原理是Flink 对 TaskManager 上作业相关线程做短时间采样统计线程有多少次处于等待 Buffer 的状态从而算出每个子任务的反压比例。页面上一般有触发采样的按钮点击后等几秒会展示每个子任务的结果。结果通常用三档状态表示OK、LOW、HIGH。具体阈值在不同版本间略有差异但思路一致比例越低越健康越高说明线程越长时间被堵住。采样本身有开销生产环境的大作业上不要频繁点击否则可能对运行中的任务造成抖动。关于反压我想先说一句可能让新手困惑的话反压不一定是病。如果 Kafka Source 生产速率是 1 万条/秒而下游 MySQL Sink 只能写 5000 条/秒那反压是必然的也是系统在自保护。如果业务上允许暂时堆积反压是健康的状态。真正要警惕的是持续长时间、全链路传导的反压。快速定位方法在 Job Graph 上从最下游的 Sink 节点开始逐个往上游看反压状态。第一个出现 HIGH 的节点基本就是瓶颈所在。因为反压总是从最慢的节点向上游传导Sink 慢会把下游所有节点都压住。4.3 反压排查的常规路线与几个防呆提醒实践下来我总结了一条固定路线每次遇到反压都按这个走Job Graph 里从下游往上游找第一个 HIGH 节点。进入该节点的 Subtasks对比各子任务 Records 和 Duration判断是倾斜还是整体慢。打开对应 TaskManager 的 Metrics看 CPU 和 GC。GC 高先查 State 大小和堆配置CPU 高再看火焰图。检查 Checkpoints 历史。如果最近都在超时说明 Barrier 被反压拖住Checkpoint 失败会进一步放大问题。用火焰图或 Thread Dump 定位热点方法。如果是 Sink 慢查外部系统的连接池、批量大小、事务配置如果是算子慢考虑加并行度、调整内存、优化 Key 设计。有几个防呆提醒Chain 起来的节点内部有多个算子反压显示在 Task 级别。定位到节点后要结合火焰图看热点函数别急着给整个 Task 加并行度。Source 显示反压时别先怀疑 Source 消费慢。90% 的情况是下游堵住了反压一路传导到 Source所以要往下游找。反压消失不代表问题解决。有些作业在窗口触发瞬间产生数据洪峰Sink 扛不住导致反压窗口过了又恢复。这种周期性反压要看时间和窗口是否对齐。5. Task Managers 与 Job Manager 页面的监控价值前面几个页面解决“瓶颈在哪”TM 和 JM 页面解决“节点运行得怎么样”。5.1 Task Managers 列表页从集群资源到单 TM 内存侧边栏的 Task Managers 页面展示集群里所有 TaskManager 的信息地址、CPU 核数、内存、剩余内存、Slot 数量、空闲 Slot、当前运行的 Task 数。这个页面最典型的场景是查资源碎片。曾经有个作业总是卡在 SCHEDULED集群明明有 10 个空闲 Slot但作业就是起不来。到 TM 列表一看空闲 Slot 全部分散在不同 TM 上每个 TM 只空出 1-2 个 Slot而作业的并行度比较高单个 Slot 装不下。之后调整了 slotSharingGroup 的策略才恢复正常。内存相关我多说一句Flink 进程内存分为堆内和堆外Web UI 上显示的内存是 TaskManager 总内存Free Memory 代表的是 JVM 维度可用的内存。如果 Free Memory 持续走低且伴随频繁 Full GC先去看 TM 详情的 Metrics再决定要不要调堆内存比例不要直接在容器层加内存很多时候是 Managed Memory 和堆外内存配置不合理。5.2 TM 详情的 Metrics、Logs、Stdout、Thread Dump点击任意 TM 进入详情里面有四个标签页Metrics展示 CPU Load、内存使用、线程数、网络吞吐等曲线。排查 TM 负载高、GC 频繁时主要看这里。LogsTaskManager 的完整日志。分布式排查时知道异常发生在哪个 TM 上直接来这里搜关键词比登录服务器 grep 日志还方便。StdoutTaskManager 的标准输出。如果代码里写了System.out会在这里看到。它和 Logs 分开专门用来捞打印信息。Thread Dump当前 JVM 线程快照。在作业卡住的时候点一次能看到线程状态。如果在RUNNABLE状态的线程反复出现在某个业务方法上说明 CPU 密集热点在那里如果大量线程WAITING在锁上说明存在锁竞争或外部调用阻塞。Thread Dump 是快照火焰图则是时间线维度的采样统计两者互补。Flink 新版 UI 的火焰图入口一般在作业详情页或算子详情里它通过类似 Async Profiler 的方式给目标 Task 的线程做 CPU 采样生成火焰图。看火焰图时顶部宽条就是要重点优化的热点函数。我之前定位过一个诡异问题窗口计算算子 CPU 高但业务逻辑看起来很简单火焰图一出来才发现是序列化器在反复创建对象。这种问题靠看代码一时半会儿找不到火焰图几秒就暴露了。5.3 Job Manager 页面和 Configuration 校验Job Manager 页面同样有 Metrics、Logs、Stdout、Thread Dump。JobManager 出问题通常影响所有作业比如提交任务卡住、Checkpoint Coordinator 异常、作业恢复迟迟不启动。这些场景下去 JM 的 Logs 和 Thread Dump 里看比逐个作业页面翻高效得多。Configuration 这个菜单在侧边栏里容易被忽略但它有个很实用的功能展示当前 JobManager 实际生效的配置。我遇到过不止一次同事说改了flink-conf.yaml里的参数但作业行为完全没有变化。到 Configuration 页面一搜发现 key 根本不存在或者值还是老样子——要么改错了文件要么改了没重启要么拼写错误。这个页面是验证配置是否生效的最快方式没有之一。6. Checkpoints 页面状态一致性看得见实时作业的状态一致性最终都要落到 Checkpoint 上。Web UI 的 Checkpoints 菜单是把状态管理从黑盒变成白盒的关键。6.1 Overview、History、Summary、Configuration 四个 Tab作业详情页的 Checkpoints 菜单下一般有四个 TabOverview展示最近一次 Checkpoint 整体情况包括触发的 Checkpoint ID、状态大小、耗时、完成时间。如果这里显示最近一次成功是很久以前说明 Checkpoint 已经处于持续失败状态。History列出每次 Checkpoint 的记录包括触发时间、完成时间、端到端耗时、State 大小、确认的 Subtask 数。这里是最重要的排障入口可以看耗时趋势是不是在逐渐恶化。Summary对全部 Checkpoint 做统计展示 End to End Duration、State Size 等指标的 Min、Avg、Max。调优时可以拿 Avg 作为基线。Configuration展示 Checkpoint 相关的生效配置比如 interval、timeout、min pause between checkpoints、externalized cleanup 策略。如果这里看不到你想要的参数去全局 Configuration 页面查因为部分参数可能在作业级别的配置里。默认情况下 Flink 是不开启 Checkpoint 的。如果你只配置了 state backend没配 intervalUI 上 Checkpointing 会显示 Disabled。很多新手在这里困惑以为自己配置没生效其实是根本没开启。6.2 从 Checkpoint 失败反推状态与 Barrier 问题我在生产环境见到最多的 Checkpoint 问题就是超时。默认的 Checkpoint Timeout 通常是 10 分钟。如果 State 很大、网络抖动、或者 Barrier 在算子间传输被反压拖住就可能超时。UI 里表现为 History 中大量 FAILED 记录失败原因往往写着 Barrier 相关或超时。这里有一条核验链Checkpoint 耗时拉高 - 查看 Backpressure 页面 - 如果下游大规模 HIGH说明 Barrier 被反压卡住优先解决反压如果反压不大可能 State 本身就大或者 RocksDB 写盘慢考虑开启增量 Checkpoint并调整存储后端参数。还有一点生产必配置Externalized Checkpoint 的清理策略。默认策略下作业 Cancel 后外部 Checkpoint 会被清理状态就没了。生产环境应该配置为保留RETAIN_ON_CANCELLATION才能支持“先停作业、后恢复状态”的操作。这个策略在 Checkpoints 菜单的 Configuration Tab 里不一定能改但能看到配合日志确认即可。如果 Checkpoint 持续失败但作业本身还在运行要小心状态会停留在最后一次成功的版本数据延迟和堆积会慢慢扩大最终把作业拖垮。这个场景比作业直接挂掉更危险因为表面看作业是 RUNNING 的。7. 实战案例从 Web UI 上发现并定位一次作业异常前面的菜单逐个讲完了最后用一个真实案例把整套链路串起来。这个案例我调整过一些细节但排查路径和结论都是实际验证过的。7.1 现象Sink 吞吐下降、作业延迟拉高某实时风控标签作业链路是 Kafka - keyBy - 10 分钟窗口聚合 - 写入 MySQL。某个版本上线运行 3 小时后业务反馈标签更新延迟接近 15 分钟但作业没有失败也不重启。我打开 Flink Web UI第一眼看到 Jobs Overview 列表里作业状态是 RUNNINGDuration 已经 3 个多小时Tasks 列显示正常没有子任务失败。如果只看状态颜色会以为作业没问题。但业务反馈延迟是实实在在的。7.2 按照 Web UI 菜单逐层下钻点进作业详情Overview 页面发现一个关键线索Checkpoint 区域最近一次成功的时间已经是很久之前而最近的 Checkpoint 都是失败状态。这基本说明作业内部已经出问题了。切换到 Checkpoints 菜单History 里最近的 Checkpoint 记录显示端到端耗时从正常的几秒飙升到接近 20 分钟然后超时失败。检查点失败又触发重试进一步占用资源。接着看 Job Graph从 Sink 节点开始往上游逐个检查。Source 节点正常窗口节点显示 HIGH backpressureSink 节点显示 HIGH backpressure。反压传导路径很清晰瓶颈在窗口到 Sink 这一段。进入窗口节点的 Subtasks 页面对比各子任务的数据量20 个并行度里有 2 个子任务接收记录数是其他子任务的 5 倍典型的数据倾斜症状。再进 Sink 节点的 Subtasks发现两个并行子任务的 Records 远小于其他子任务——它们在严重等待窗口数据。到这里初步链路已经出现了热点 key 导致窗口算子个别子任务负载过高窗口触发瞬间大量结果集中写入 MySQLSink 并发不足写入变慢产生反压。反压传导回窗口节点窗口处理变慢Checkpoint Barrier 被卡住最终 Checkpoint 失败。为了排除 Sink 本身的问题我又看了 TaskManager 详情页的 Metrics 和 Thread Dump。对应 TM 的 CPU 不算高但 Sink 相关线程有大量WAITING状态堆栈指向 JDBC 连接获取。同时火焰图显示热点集中在连接池获取和 SQL 批处理上。到这里可以确认MySQL 写入侧确实存在资源瓶颈。7.3 定位、调整与验证修复方案做了三件事在窗口聚合后增加一层打散逻辑把热点 key 在二次聚合前先随机分桶避免所有结果同时打到一个 Sink 子任务。调大 JDBC 连接池Sink 并行度从 2 提上来同时开启批量提交。给作业单独配置了 Checkpoint 的 min pause between checkpoints避免失败后立即重试造成叠加压力。上线后观察Web UI 上 Backpressure 状态从 HIGH 降到 OKCheckpoint History 里的端到端耗时回到秒级业务延迟恢复正常。复盘这次排查整个过程没有登录一台服务器全部信息都来自 Flink Web UI 的逐级下钻Overview 发现 Checkpoint 异常Checkpoints 确认失败趋势Job Graph 定位反压范围Subtasks 发现数据倾斜TM Metrics 和 Thread Dump 排除节点问题。每个菜单单独看都只是碎片信息串成链路才完整。最后再分享两个小技巧一是给作业起名字一定要带业务语义和版本号。没有这个习惯Jobs Overview 里全是乱码一样的默认名线上二三十个作业想找到目标作业都得一个个点开确认排查效率会低很多。二是每次改完参数养成到 Configuration 页面搜一下确认生效的习惯。我在这个页面上抓到过太多“改了配置但没生效”的乌龙。Flink Web UI 能看的东西很多但从这些不起眼的操作开始你才会真正觉得它是个顺手的排障工具而不是一个红绿灯面板。