Flink History Server 集群停了也能看已完成作业的 Web UI 与 REST 数据

1. History Server 能解决什么问题

典型痛点

• 集群关闭后，Web UI 上的作业页面消失，无法回看 DAG、算子指标、异常栈、配置
• 需要统一的“历史作业”入口做复盘对比（上线前后、参数变更前后）
• 需要对接外部系统（监控、运维平台、审计平台）通过 API 拉取作业归档数据

History Server 提供能力

• 展示 JobManager 归档下来的已完成作业状态与统计信息
• 提供 REST API（返回 JSON）便于系统集成
• 支持跳转到你们已有的日志平台（Log Integration）

2. 工作机制：JM 负责“归档”，History Server 负责“展示”

整体链路很清晰：

1）JobManager 在作业结束时，把“作业归档信息”写到一个文件系统目录
2）History Server 定期轮询这个目录，发现新归档就下载到本地缓存
3）History Server 对外提供 Web UI 与 REST API 查询这些已归档作业

这里的关键点是：归档目录是“文件系统目录”，可以是 HDFS，也可以是对象存储（前提是你已安装对应的 Flink filesystem 插件，比如 S3/OSS/GCS/Azure 等）。

3. 启停方式与默认端口

History Server 是独立进程（目前只能 standalone 方式运行），用脚本管理：

# Start or stop the HistoryServer bin/historyserver.sh (start|start-foreground|stop)

默认绑定 localhost，端口 8082。

4. 核心配置：两端都要配

4.1 JobManager 侧：把归档写到哪里

在 Flink 配置文件里指定归档目录：

# Directory to upload completed job informationjobmanager.archive.fs.dir: hdfs:///completed-jobs 

这一步只发生在 JobManager：作业结束后把归档信息上传到该目录。

4.2 History Server 侧：监控哪些目录、多久刷新一次、缓存放哪

# Monitor the following directories for completed jobshistoryserver.archive.fs.dir: hdfs:///completed-jobs # Refresh every 10 secondshistoryserver.archive.fs.refresh-interval:10000# Local cache directory for downloaded archiveshistoryserver.web.tmpdir: /path/to/local/tmpdir 

要点

• historyserver.archive.fs.dir 支持逗号分隔多个目录：适合多集群、多环境汇总
• refresh-interval 太小会增加 FS 压力，太大则“历史作业出现得慢”，一般 10s~60s 根据规模调整
• web.tmpdir 是本地缓存目录，注意磁盘空间与清理策略（归档多时容易膨胀）

5. 日志集成：把“历史作业页”连到你们的日志平台

Flink 不负责归档日志，但 History Server 可以把日志 URL 模板拼出来，点击就跳到你们已有的日志系统：

# HistoryServer will replace <jobid> with the relevant job idhistoryserver.log.jobmanager.url-pattern: http://my.log-browsing.url/<jobid># HistoryServer will replace <jobid> and <tmid> with the relevant job id and taskmanager idhistoryserver.log.taskmanager.url-pattern: http://my.log-browsing.url/<jobid>/<tmid>

建议把这里对接到你们的日志检索入口（例如按 jobId/tmId 作为查询条件或路径变量），形成“指标页 → 日志页”的闭环排障体验。

6. REST API：用 JSON 把历史作业数据接入平台

所有请求形如：

http://hostname:8082/<path>

常用接口清单（节选）

• /config
• /jobs/overview
• /jobs/<jobid>
• /jobs/<jobid>/exceptions
• /jobs/<jobid>/config
• /jobs/<jobid>/vertices
• /jobs/<jobid>/vertices/<vertexid>
• /jobs/<jobid>/vertices/<vertexid>/subtasktimes
• /jobs/<jobid>/plan
• /jobs/<jobid>/jobmanager/log-url
• /jobs/<jobid>/taskmanagers/<taskmanagerid>/log-url

几个常见 curl 例子：

# 查看历史作业总览curl http://historyserver:8082/jobs/overview # 查看某个作业异常curl http://historyserver:8082/jobs/<jobid>/exceptions # 查看某个作业的执行计划（DAG/plan）curl http://historyserver:8082/jobs/<jobid>/plan # 查看某个算子的 subtask 执行耗时curl http://historyserver:8082/jobs/<jobid>/vertices/<vertexid>/subtasktimes 

7. 生产最佳实践与常见坑

1）归档目录要“稳定、共享、权限正确”

• 多 JM/TM 节点都要能访问（尤其是 HDFS/对象存储）
• 权限问题是最常见的“归档写不进去/HistoryServer 读不到”

2）对象存储要记得装 filesystem 插件

• jobmanager.archive.fs.dir/historyserver.archive.fs.dir 如果用 s3://、oss://、gs://、wasb:// 等路径，必须确保对应插件 jar 在 plugins 中并正确配置凭证

3）本地缓存目录要规划容量

• History Server 会把归档下载到本地缓存，如果长期运行且归档非常多，需要磁盘容量与清理策略
• 如果你们归档目录按天分区，也可以通过目录规划降低单目录压力

4）轮询间隔要按规模调

• 作业量大时过于频繁会对存储造成额外压力
• 作业量小但需要快速可见性（例如发布验证），可以缩短 interval

5）日志跳转模板要与日志平台“真的能定位到”

• 最好在日志平台侧做 jobId/tmId 维度的索引或查询预置，否则跳过去仍然找不到日志