一、Flink REST API 到底是什么Flink 自带了一套监控与控制 API本质上是一个RESTful HTTP JSON的接口服务。你可以通过它查询正在运行的作业状态最近完成的作业信息JobManager / TaskManager 信息指标、线程栈、日志Checkpoint / Savepoint 状态Watermark、Backpressure、Flame Graph也可以通过它执行一些操作上传 JAR运行 JAR停止 / 取消任务触发 Checkpoint触发 Savepoint触发 Stop-with-SavepointJob Rescale调整并行度删除集群数据集清理 Savepoint一句话总结Flink REST API Flink Web UI 的“可编程版本”你在页面上点的很多按钮背后其实就是这些接口。二、REST API 服务跑在哪默认端口多少Flink 的 REST API 由 JobManager 内置的 Web Server 提供默认监听8081可以通过配置项修改rest.port: 8081这里有个非常容易忽略的点REST API 服务Flink Web Dashboard 服务实际上目前是同一个 Web Server只是 URL 不同。也就是说你访问浏览器看的 Dashboard你用 curl/脚本打的 API本质上都是同一套服务只是一个返回 HTML 页面一个返回 JSON。三、高可用HA模式下REST API 有什么变化如果你启用了 HA比如ZooKeeper HAKubernetes HA那么每个 JobManager 都会启动自己的 REST API 实例。但是注意只有当前被选举为 leader 的 JobManager才是你最应该访问的那个每个 JobManager 暴露的信息和它担任 leader 期间管理过的作业有关这意味着在 HA 模式下做平台接入时你最好通过 HA 入口或服务发现拿到当前 leader不要把 REST 地址写死成某个单节点地址否则你可能会遇到接口偶尔查不到最新任务某次 failover 后你的平台“失明”四、Flink REST API 的一个大特点它是“版本化”的Flink 的 REST API 是支持版本号前缀的比如/v1/foo/bar如果你不写版本号Flink 默认会使用支持该请求的最老版本如果你请求了一个不存在或不支持的版本就会返回404这点对二次开发非常重要因为它意味着你的平台如果长期维护最好显式带版本这样在集群升级后接口行为更可控五、Flink REST API 最关键的“异步操作”机制必须先看懂很多人第一次用 Flink REST API最容易懵的地方就是为什么我 POST 触发了 Savepoint结果返回的不是 Savepoint 路径而是一个triggerid答案很简单因为 Flink 很多操作是异步的。典型异步操作包括触发 SavepointStop-with-SavepointRescale Job触发 Checkpoint删除数据集清理 Savepoint这类操作通常分两步第一步触发操作你发送一个 POST / PATCH 请求Flink 返回一个triggerid这个 ID 就是这次异步任务的“凭证”。第二步轮询状态你再用这个triggerid去查询对应状态接口看看这次操作是还在进行中已经成功还是失败了这套机制你一定要记住因为实际生产平台开发里这就是最常见的调用模式。一个很实用的点Stop-with-Savepoint 支持你自定义 triggerId对于 savepoint / stop-with-savepoint 类操作你可以在触发请求体里自己传入triggerId。这有什么好处如果你的平台因为网络抖动重试了请求你不会重复触发多个 Savepoint这在自动化运维里非常重要不然重试一次磁盘上多一个 Savepoint运维同学能当场血压拉满。但要注意这种“安全重试”不是永久安全的只在异步操作存储的保留时间内有效六、Flink REST API 最常用的接口分类一次给你捋清楚官方接口很多直接全背没有意义。真正有价值的是按“用途”分组理解。下面我按实际生产使用频率给你分成几大类。七、第一类集群级接口Cluster / Overview这类接口适合你做集群总览、巡检、运维平台首页。1. 获取集群概览GET /overview用途查看整个 Flink 集群的总体状态适合做平台首页总览2. 获取所有 Job 概览GET /jobs GET /jobs/overview用途查看当前有哪些任务每个任务当前状态如何RUNNING / FAILED / FINISHED 等这两个接口是你做“任务列表页”的基础。3. 获取集群配置GET /config GET /jobmanager/config用途看 WebUI 配置看 JobManager 配置排查线上参数是否真的生效4. 获取 JobManager 环境信息GET /jobmanager/environment用途看 JobManager 运行环境排查环境差异、JVM 参数、生效配置等5. 关闭整个集群DELETE /cluster这个接口很猛作用是直接关闭集群生产环境请谨慎别手滑。八、第二类JAR 管理接口平台化提交作业的核心如果你想做一个“像 Flink Web UI 一样”的作业平台这一组接口是必学的。1. 查看已上传的 JARGET /jars作用返回所有之前通过/jars/upload上传过的 JAR 列表2. 上传 JARPOST /jars/upload这是最常用的入口之一。上传时要注意使用 multi-part form dataJAR 的 Content-Type 要注意官方示例 curlcurl-XPOST-HExpect:-Fjarfilepath/to/flink-job.jarhttp://hostname:8081/jars/upload3. 删除 JARDELETE /jars/:jarid适合你做平台里的“清理历史包”。4. 查看 JAR 中作业计划PlanPOST /jars/:jarid/plan这个接口特别实用在真正提交运行前先看生成的数据流执行计划可用于平台预检查任务可视化提交前参数验证5. 运行 JARPOST /jars/:jarid/run这是通过 REST 提交作业的核心接口。它支持很多常用参数entry-classparallelismprogramArgsavepointPathallowNonRestoredState也就是说你完全可以通过一个平台页面把这些参数都拼到 REST 请求里然后做到“无 CLI 提交”。九、第三类作业生命周期接口查状态、停任务、取消任务这是你日常运维最常用的一类。1. 获取作业详情GET /jobs/:jobid能看到作业基本信息状态拓扑顶点信息等2. 获取作业当前状态GET /jobs/:jobid/status如果你只想快速判断任务是不是还活着这个接口最直接。3. 终止作业取消PATCH /jobs/:jobid?modecancel当前支持的 termination mode 主要是cancel也就是说这相当于平台里的“取消任务”。4. 获取作业执行结果GET /jobs/:jobid/execution-result适合批任务或已完成任务使用可以看到执行耗时accumulators 等结果信息十、第四类Checkpoint / Savepoint 接口生产运维高频操作这类接口绝对是线上最常用、也最容易写成自动化的部分。十一、Checkpoint 接口1. 查看 Checkpoint 统计GET /jobs/:jobid/checkpoints你能看到最近 checkpoint 情况成功 / 失败统计历史 checkpoint 列表2. 查看 Checkpoint 配置GET /jobs/:jobid/checkpoints/config排查“这个任务到底有没有开 checkpoint”“间隔是多少”时很有用。3. 触发 CheckpointPOST /jobs/:jobid/checkpoints这是异步操作会返回triggerid然后你要继续查GET /jobs/:jobid/checkpoints/:triggerid4. 查看指定 Checkpoint 详情GET /jobs/:jobid/checkpoints/details/:checkpointid可以深挖某一次 checkpoint 为什么慢某次 checkpoint 哪个阶段耗时高5. 查看指定 Vertex 的 Checkpoint 详情GET /jobs/:jobid/checkpoints/details/:checkpointid/subtasks/:vertexid这个就更适合做“细粒度性能排查”了。十二、Savepoint 接口1. 触发 SavepointPOST /jobs/:jobid/savepoints用途手动打 Savepoint为升级、迁移、回滚做准备这是异步接口返回triggerid然后用GET /jobs/:jobid/savepoints/:triggerid查询结果。2. Stop-with-SavepointPOST /jobs/:jobid/stop这个接口的价值非常高先做 Savepoint再优雅停止作业适合正式发版有状态任务升级平滑下线而且它还支持在 Savepoint 前先发一个MAX_WATERMARK这对有 event time / timer 的任务非常关键因为它可以先尽量把窗口和定时器刷干净。3. 清理 SavepointPOST /savepoint-disposal GET /savepoint-disposal/:triggerid如果你的平台支持 Savepoint 生命周期管理这组接口就能派上用场。十三、第五类异常排查接口线上救命接口这部分接口非常适合做“问题定位面板”。1. 获取最近异常GET /jobs/:jobid/exceptions这个接口特别有用因为它会返回最近的异常历史是否被截断failure labels可过滤还能通过参数控制maxExceptionsfailureLabelFilter如果你做告警平台可以把它当作第一手异常来源。2. 获取 JobManager 线程栈GET /jobmanager/thread-dump3. 获取 TaskManager 线程栈GET /taskmanagers/:taskmanagerid/thread-dump这两个接口在线上排查“卡住”“假死”“线程阻塞”时非常有用。很多时候 SSH 上去跑 jstack 很麻烦这时候 REST API 就很香。4. 获取日志列表GET /jobmanager/logs GET /taskmanagers/:taskmanagerid/logs这类接口适合你做“平台日志入口”。5. 获取日志 URLGET /jobs/:jobid/jobmanager/log-url GET /jobs/:jobid/taskmanagers/:taskmanagerid/log-url如果你在做运维平台这些接口能让你把“查看日志”做成跳转链接。十四、第六类指标接口Metrics监控平台最爱Flink REST API 提供了很多 metrics 入口几乎可以作为轻量监控拉取来源。1. JobManager 指标GET /jobmanager/metrics可以通过get参数指定具体指标。2. TaskManager 指标GET /taskmanagers/:taskmanagerid/metrics GET /taskmanagers/metrics支持拉单个 TM 指标拉聚合后的 TM 指标还可以做聚合模式minmaxsumavgskew3. Job 指标GET /jobs/:jobid/metrics GET /jobs/metrics适合你做任务级指标面板。4. Vertex / Subtask 指标GET /jobs/:jobid/vertices/:vertexid/metrics GET /jobs/:jobid/vertices/:vertexid/subtasks/:subtaskindex/metrics GET /jobs/:jobid/vertices/:vertexid/subtasks/metrics这组接口是做“算子级监控”的核心。如果你想实现某个算子吞吐某个 subtask 忙碌度某个并行实例是否异常这就是入口。十五、第七类作业诊断接口Backpressure / Watermark / Flame Graph这一组接口是 Flink REST API 里最“有技术含量”的部分也是排查性能问题时最值钱的。1. 查 BackpressureGET /jobs/:jobid/vertices/:vertexid/backpressure这个接口会返回当前顶点的背压情况必要时还会触发一次背压采样如果你做自动化诊断平台这个接口非常适合做“背压热力图”。2. 查 WatermarksGET /jobs/:jobid/vertices/:vertexid/watermarks这个接口非常适合排查为什么窗口迟迟不触发为什么 Event Time 卡住了哪个 subtask watermark 最低对事件时间任务来说这绝对是高频接口。3. 查 Flame GraphGET /jobs/:jobid/vertices/:vertexid/flamegraph支持参数typeFULLtypeON_CPUtypeOFF_CPU可选subtaskindex这个接口就是你做“线上 CPU 火焰图诊断”的入口。很多人只会在 UI 里点其实你完全可以通过 REST 调出来做成自定义诊断按钮自动采样分析平台上的性能巡检工具十六、第八类作业扩缩容接口RescaleFlink 也支持通过 REST 对作业做 rescale。1. 触发 RescalePATCH /jobs/:jobid/rescaling?parallelism8这是异步操作会返回triggerid。2. 查询 Rescale 状态GET /jobs/:jobid/rescaling/:triggerid这意味着你可以做出一个真正的平台功能用户在页面上改并行度平台调用 REST 发起 rescale前端轮询状态直到完成是不是瞬间就有“自研调度平台”的味道了十七、第九类TaskManager 相关接口机器维度排查必备如果你排查问题的维度不是“作业”而是“机器”那就看这一组。1. 获取所有 TaskManagerGET /taskmanagers2. 获取单个 TaskManager 详情GET /taskmanagers/:taskmanagerid3. 获取 TaskManager 指标GET /taskmanagers/:taskmanagerid/metrics4. 获取 TaskManager 日志列表GET /taskmanagers/:taskmanagerid/logs5. 获取 TaskManager 线程栈GET /taskmanagers/:taskmanagerid/thread-dump如果你想快速判断某台 TM 是否抖动某台 TM 是否线程卡死某台 TM 是否是异常热点机器这些接口就很关键。十八、一个最常用的 REST API 调用链建议你直接记住如果你要做一个最基础的“Flink 平台化作业管理”最常见的链路就是下面这套1. 上传 JARPOST /jars/upload2. 查看 JAR 列表拿到jaridGET /jars3. 查看执行计划可选POST /jars/:jarid/plan4. 运行作业POST /jars/:jarid/run5. 查询所有作业拿到jobidGET /jobs6. 轮询状态GET /jobs/:jobid/status7. 查异常 / Metrics / Backpressure / WatermarkGET /jobs/:jobid/exceptions GET /jobs/:jobid/metrics GET /jobs/:jobid/vertices/:vertexid/backpressure GET /jobs/:jobid/vertices/:vertexid/watermarks8. 发版时打 Savepoint 或 Stop-with-SavepointPOST /jobs/:jobid/savepoints POST /jobs/:jobid/stop这一整套就是很多企业自研 Flink 管控平台的最小闭环。十九、生产环境里最值得重点接入的 REST API 接口如果你不想一口气全接只想先做最有价值的一批我建议你优先接入这些平台首页/overview/jobs/taskmanagers作业详情页/jobs/:jobid/jobs/:jobid/status/jobs/:jobid/plan/jobs/:jobid/exceptions性能诊断页/jobs/:jobid/vertices/:vertexid/backpressure/jobs/:jobid/vertices/:vertexid/watermarks/jobs/:jobid/vertices/:vertexid/flamegraph/taskmanagers/:taskmanagerid/thread-dump运维动作/jobs/:jobid/savepoints/jobs/:jobid/stop/jobs/:jobid/checkpoints/jobs/:jobid/rescaling包管理/jars/jars/upload/jars/:jarid/run这套已经足够支撑一个很像样的内部管理平台了。二十、使用 REST API 时最容易踩的几个坑1. 忘了处理异步triggerid这是最常见的问题。很多人以为 POST 一下就完成了结果接口只返回了 triggerId你却没继续查状态。2. HA 模式下写死 JobManager 地址Leader 切换后你的监控平台可能直接“假死”。3. 只看 Job 级信息不看 Vertex / Subtask 级接口很多问题真正的根因都在某个并行实例某个算子某个 TaskManager如果你只看/jobs/:jobid/status能看到的太少。4. 直接把高危接口开放给所有人比如DELETE /clusterPATCH /jobs/:jobid?modecancel这类接口如果权限不收好后果你懂的。5. 忽略版本前缀集群升级后兼容性可能出问题。长期维护的平台建议明确使用版本化路径。二十一、Flink REST API 为什么这么适合做企业平台化因为它本身就具备天然的平台接口特征HTTP 协议接入简单JSON 返回前后端都好处理能查也能控支持异步长操作能覆盖大部分常见运维动作和 Web UI 是同一底座功能天然一致你完全可以基于它做出这些能力自研作业提交平台自动巡检系统Savepoint 运维平台作业异常诊断页面指标聚合大盘一键扩缩容工具Flink 任务自动化托管平台说白了Flink REST API 不是“给你查着玩”的它本来就是你做平台能力的官方入口。二十二、最后总结别再只会点 Web UI 了很多团队用 Flink用了很久还是停留在出问题了人工点 UI发版了人工打 Savepoint想看状态人工刷新页面想扩容手工操作这在小规模时还能忍一旦任务多了、团队大了、生产要求高了就会变得非常低效。真正成熟的做法应该是用 REST API 做自动化用 REST API 做平台化用 REST API 把“人工操作”变成“系统能力”一句话送给所有做 Flink 的同学会用 Web UI只是入门会用 REST API才是真正开始走向平台化。