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 方式运行），用脚本管理：
bash
# Start or stop the HistoryServer
bin/historyserver.sh (start|start-foreground|stop)默认绑定 localhost，端口 8082。
4. 核心配置：两端都要配
4.1 JobManager 侧：把归档写到哪里
在 Flink 配置文件里指定归档目录：
yaml
# Directory to upload completed job information
jobmanager.archive.fs.dir: hdfs:///completed-jobs这一步只发生在 JobManager：作业结束后把归档信息上传到该目录。
4.2 History Server 侧：监控哪些目录、多久刷新一次、缓存放哪
yaml
# Monitor the following directories for completed jobs
historyserver.archive.fs.dir: hdfs:///completed-jobs
# Refresh every 10 seconds
historyserver.archive.fs.refresh-interval: 10000
# Local cache directory for downloaded archives
historyserver.web.tmpdir: /path/to/local/tmpdir要点
historyserver.archive.fs.dir支持逗号分隔多个目录：适合多集群、多环境汇总refresh-interval太小会增加 FS 压力，太大则"历史作业出现得慢"，一般 10s~60s 根据规模调整web.tmpdir是本地缓存目录，注意磁盘空间与清理策略（归档多时容易膨胀）
5. 日志集成：把"历史作业页"连到你们的日志平台
Flink 不负责归档日志，但 History Server 可以把日志 URL 模板拼出来，点击就跳到你们已有的日志系统：
yaml
# HistoryServer will replace <jobid> with the relevant job id
historyserver.log.jobmanager.url-pattern: http://my.log-browsing.url/<jobid>
# HistoryServer will replace <jobid> and <tmid> with the relevant job id and taskmanager id
historyserver.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 例子：
bash
# 查看历史作业总览
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>/subtasktimes7. 生产最佳实践与常见坑
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 维度的索引或查询预置，否则跳过去仍然找不到日志