Flink与Prometheus集成实战：从指标原理到告警配置全解析

otter_ai·2026-08-29·阅读 23 GEO检测（免费）

Flink监控PrometheusGrafana

|难度：普通|阅读约 52 分钟

Prometheus 和 Flink 集成：把这套监控链路吃透，比看 10 篇复制粘贴教程有用

Flink 跑起来不难，难的是跑起来之后你两眼一抹黑。某个作业凌晨三点重启了、checkpoint 一直失败、消费延迟飙到几十万条，你都是最后一个知道的，这种经历做过实时数仓的人大概率都体会过。所以把 Prometheus 和 Flink 集成起来，不是锦上添花，而是刚需。这套东西本质上是让 Flink 自己把心跳和状态报告出来，再由 Prometheus 定时拉走，最后通过 Grafana 画成图、通过 Alertmanager 喊人。这篇文章是我把 Flink 1.13 到 1.17 的多个版本都接进 Prometheus 之后整理的实操笔记，适合正在搞 Flink 监控或者被各种采坑问题折磨的人。我会把 Flink 指标是怎么产生的、Reporter 怎么配置、Prometheus 怎么抓、面板怎么看、告警怎么设、以及我实际踩过的坑全部讲完，尽量做到不只给结论，还把原因说透。

1. Flink 的监控指标是怎么跑出来的：先理解 Reporter 机制再上手配置

直接改配置之前，先花十分钟搞懂 Flink 的指标系统，否则你配置完了看到的只是空荡荡的指标列表，出了问题也不知道去哪里查。

1.1 Flink 指标的两大基础：MetricGroup 和 MetricType

Flink 自己内置了一套指标注册体系，每一类指标都挂在某个 MetricGroup 下面。你可以把它想象成文件系统目录，MetricGroup 就是文件夹，Metric 就是文件夹里的文件。Flink 的 JobManager、TaskManager、Job、Task 这些运行实体，都会自动创建对应的 MetricGroup，然后把 CPU、内存、吞吐量、延迟这类指标挂进去。你自己写的业务代码里也可以用 getRuntimeContext().getMetricGroup().gauge("my_custom_count", ...) 这种形式注册自定义指标，这就是为什么后面积分很容易的原因。

常见的 MetricType 有四种，Gauge 是一个瞬时值，比如当前 JVM 堆内存；Counter 是单调递增计数，比如累加器；Meter 是速率，比如每秒处理多少条；Histogram 是分布统计，比如延迟的 p95。Prometheus 自己也有 Counter、Gauge、Histogram、Summary 这套模型，两边一对照，基本能无痛翻译过去。需要注意的是 Flink 默认提供的很多指标是以 Gauge 形式暴露的，比如 numRestarts 其实是一个 Gauge，不是 Counter，这个细节到后面写告警规则的时候会坑到你。

1.2 Reporter 的作用：把 MetricGroup 里的数据公布出去

Flink 的指标是在内存里动态变化的，外部监控系统不可能直接读它的内存，所以需要一个"公布"机制，这就是 MetricReporter。Reporter 在 Flink 进程启动时会被加载，周期性地把 Flink 内部指标发送到外部系统。Flink 官方自带了多种 Reporter，比如 JMX、Graphite、Prometheus、PrometheusPushGateway、InfluxDB 等。我们这里只关心两个：PrometheusReporter 和 PrometheusPushGatewayReporter。

Flink 的 Reporter 配置总体上遵循同一个套路。你要在 flink-conf.yaml 里指定 metrics.reporter.<name>.<config>，其中 <name> 是自己给 reporter 起的别名，可以叫 prom、prome、my-prom 都可以。系统会在运行时通过反射加载对应类。如果你多配几个不同名字的 reporter，比如一个本地抓取、一个推送到 PushGateway，也可以同时生效。

1.3 PrometheusReporter 和 PushGatewayReporter，到底该选哪个

这是新人最容易困惑的地方。PrometheusReporter 是让 Flink 启动一个 HTTP 端口，把指标暴露成 /metrics 格式，Prometheus 服务端通过 pull 模式来拉取。PrometheusPushGatewayReporter 则相反，它是 Flink 主动把指标推送到一个名为 PushGateway 的独立组件，Prometheus 再去 PushGateway 拉取。

两条路背后其实是两种监控哲学：pull 和 push。pull 的好处是监控服务端决定什么时候抓，目标挂了就很明显地暴露出来；push 的好处是如果目标处于短生命周期任务或者网络环境不允许服务端主动访问，Flink 可以自己往外推。Flink 的 JobManager 和 TaskManager 都是常驻进程，生产上我首选 PrometheusReporter，它少一个 PushGateway 中间组件，少一个故障点。只有在你用 Kubernetes 且整组 TaskManager 动态起停、或者某些段网络被安全策略限制导致 Prometheus 访问不到 Flink 节点时，才考虑用 PushGateway。

1.4 指标名的拼接逻辑与标签从哪来

理解 Flink 指标名是怎么拼出来的，对后续写 PromQL 特别重要。Flink 指标被导出到 Prometheus 后，指标名和标签并不是直接复制 MetricGroup 目录名。默认情况下，PrometheusReporter 会把 MetricGroup 的层级信息放进指标名，而把变量部分放到标签里。比如 Job 的 numRestarts 指标会导成：

code复制flink_jobmanager_job_numRestarts{job_id="...", job_name="...", namespace="...", ...}

但你实际看的时候会发现，job_name 这个标签里如果包含空格、点号或者中划线，Prometheus 的标签值虽然能保留，但查询时要注意转义，尤其是模板中 job_name="my top job" 这种空格很容易被坑。还有，Flink 自己的指标名如果包含点号，Prometheus 会把它转换成下划线，因为 Prometheus 指标名规范不允许点号。例如 taskManagerId 相关的 group 路径里有点号，最后你会看到类似 flink_taskmanager_status_jvm_garbage_collector_PS_MarkSweep_count 这种很长的名字。

看明白这个映射关系，你才知道想要查"某个作业从外部读取了多少条数据"，应该去搜 flink_taskmanager_job_task_operator_numRecordsIn 而不是凭印象瞎查。后面第三节我会专门对着实际抓到的指标做映射演示。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 接入前必须做的两件事：版本核对与依赖放置

我见过太多人把配置写完，重启 Flink，结果 curl localhost:9249/metrics 返回 404。八成原因是 jar 包没放，或者放的 jar 版本跟 Flink 版本对不上。

2.1 版本矩阵与 jar 包位置

Flink 没有把 Prometheus reporter 直接编进发行包，你需要自己把 flink-metrics-prometheus 这个 jar 放到 Flink 的 lib 目录下。这个 jar 的版本必须和 Flink 主版本严格一致，比如 Flink 1.17.2 你就要找对应的 flink-metrics-prometheus-1.17.2.jar。大致可以去 Maven Central 的 org.apache.flink:flink-metrics-prometheus 目录下翻，或者看你安装目录里的 opt 目录，Flink 发行包有时会带有 flink-metrics-prometheus-xxx.jar，你把它拷到 lib 下就行。

如果把 flink-metrics-prometheus 和 flink-metrics-prometheus-pushgateway 两个 jar 都放进去了，也没问题，但配置里你又多配了一个 PushGateway reporter 的话，Flink 每次会启动两个端口并向 PushGateway 推送，容易造成指标源混乱。我的做法是只留一个：裸 pull 模式就只放 flink-metrics-prometheus，push 模式就只放 flink-metrics-prometheus-pushgateway。

注意，Flink 1.15 之后对 flink-metrics-* 的发行策略有一些变化，某些版本里 jar 包不再出现在 opt 目录，而是需要你自己去 Maven 拉。别慌，把 jar 丢到 lib 后重启 Flink 进程，日志里如果出现 ReporterConfiguration 相关 INFO，就说明加载成功了。

2.2 flink-conf.yaml 里到底填哪些参数

我给你的配置模板是基于生产环境常用的 pull 模式。假设你集群里 JobManager 和 TaskManager 都用同一套 flink-conf.yaml，那么只需要加这几行：

yaml复制metrics.reporter.prom.factory.class: org.apache.flink.metrics.prometheus.PrometheusReporterFactory
metrics.reporter.prom.port: 9249

注意 name 我用的是 prom，所以前面的 key 是 metrics.reporter.prom。如果 name 你叫 prometheus，那就都是 metrics.reporter.prometheus.xxx。新手最容易把 factory.class 写错，记一下这个类的完整路径是 org.apache.flink.metrics.prometheus.PrometheusReporterFactory，不要只写类名。

端口 9249 是 PrometheusReporter 的默认端口。你不需要手工指定每个 TaskManager 的端口不同，Flink 会在端口冲突时自动加上偏移量继续尝试，比如一个 TaskManager 占用了 9249，另一个就会尝试 9250。但如果你用固定端口映射上 Kubernetes Pod，那要小心这偏移量，最好配置里给足端口范围。

2.3 完整的可复用配置片段

下面这段是我在 Flink 1.16 集群上实际跑过的配置，直接抄差不多能跑：

yaml复制metrics.reporter.prom.factory.class: org.apache.flink.metrics.prometheus.PrometheusReporterFactory
metrics.reporter.prom.port: 9249

# 如果不想把一些细节指标全部暴露，可以启用
metrics.reporter.prom.scope.variables.excludes: task_id;operator_id

# 注意 Flink 1.15+ 还可以设置 reporter 的 interval
metrics.reporter.prom.interval: 10 SECONDS

scope.variables.excludes 的作用是排除一些高基数的标签变量，比如 operator_id 和 task_id，因为每并行度实例不同会带来很多组合标签，让 Prometheus 存储压力增大. 我个人的建议是：如果你只是看作业层面的指标，把 task_id;operator_id 排除掉；如果你要定位到具体某个子任务，那要保留它们，二者各有利弊。

interval 参数在某些 Flink 版本中生效，它控制 reporter 将内存中的指标刷到 HTTP 端点的频率。Prometheus 拉取也有自己的 scrape_interval，理论上 reporter 的 interval 应该小于或等于 Prometheus 的抓取频率，否则一个抓取周期内数据可能重复或滞后。我一般把 Flink 的 interval 设成 10 秒，Prometheus 的 scrape_interval 设成 15 秒。

2.4 PushGateway 模式的配置关键点

如果你确实需要 push 模式，配置大概是这样的：

yaml复制metrics.reporter.promgw.factory.class: org.apache.flink.metrics.prometheus.PrometheusPushGatewayReporterFactory
metrics.reporter.promgw.host: pushgateway-host
metrics.reporter.promgw.port: 9091
metrics.reporter.promgw.jobName: my-flink-cluster
metrics.reporter.promgw.randomJobNameSuffix: true
metrics.reporter.promgw.deleteOnShutdown: false
metrics.reporter.promgw.interval: 30 SECONDS

有两个参数值得多说两句。randomJobNameSuffix 是给每个 TaskManager 的 jobName 加一个随机后缀，避免多个 TaskManager 推送到同一个 PushGateway group 时互相覆盖；deleteOnShutdown 设置为 false 是因为如果你把它设成 true，TaskManager 正常退出时会把 PushGateway 上对应的指标删掉，这在某些场景下你以为节点挂掉的原因就没了，但我个人认为 false 更稳妥，因为指标过期由 PushGateway 的时间戳机制来处理，而不是靠删除。如果你图省心，生产上还是建议别用 push 模式，真出问题排查链路太长。

3. Prometheus 服务端抓取与指标映射：从 JobManager 到 TaskManager 的全链路

Flink 配置好了，现在要让 Prometheus 能发现这些端点。这里有个常见的思维误区：不要想着在每个 Flink 节点上都装一个 node-exporter 再在 Prometheus 里单独加 target，而是要让 Prometheus 根据 Service 或者 DNS 动态发现所有节点的 9249 端口。

3.1 Prometheus 抓取目标怎么配置

最简单的方式，如果你所有 Flink 节点 IP 固定且量不大，直接在 prometheus.yml 里写静态 target：

yaml复制scrape_configs:
  - job_name: 'flink'
    static_configs:
      - targets:
        - '10.0.0.11:9249'
        - '10.0.0.12:9249'
        - '10.0.0.13:9249'

如果你用的是 Kubernetes，建议用 kubernetes_sd_configs，按 Pod 或 Service 的 label 自动发现。不管哪种方式，你最后都需要验证 Prometheus 确实抓到了每个 target。打开 Prometheus 的 Status -> Targets 页面，如果看到 UP 状态，说明抓取成功；看到 DOWN 就去检查网络和端口。

3.2 Flink 端口偏移问题与 Prometheus 多实例抓取

前面提过，Flink 在同一个机器上如果有多个 TaskManager 进程（比如本地跑 Standalone 集群），9249 不够用时会自动递增。这时你在 Prometheus 静态配置里只写 9249 就漏掉了其他进程。我常用的解法是：为 Flink 只分配独立节点，或者用机器上固定进程 + 端口映射。更标准的是用 Consul 或 Prometheus 的 file_sd_configs，让运维脚本把每个 TaskManager 的 ip:port 生成到 JSON 文件里，Prometheus 就能动态加载。

这部分不需要多么高深，关键是排查时能看到一个全量的 endpoint 列表。我建议你写一个简单的 shell 循环，把每个 TaskManager 节点的 /metrics 抓下来数一下指标行数，比如：

bash复制for host in tm001 tm002 tm003; do
  echo "$host: $(curl -s http://$host:9249/metrics | wc -l) metrics"
done

指标行数如果只有几十行，说明可能只是 JVM 指标，Job 级指标没出现，这种情况通常是还没有提交作业或者 reporter 没加载全。一个正常的 TaskManager 在运行作业时应该能输出几百行指标。

3.3 Flink 指标名在 Prometheus 下的实际映射案例

直接看一个真实例子。我用 Flink 跑了一个 Kafka -> Flink -> MySQL 的作业，从 /metrics 里抓到了这样的内容：

code复制# HELP flink_taskmanager_job_task_operator_numRecordsIn Total number of records.
# TYPE flink_taskmanager_job_task_operator_numRecordsIn counter
flink_taskmanager_job_task_operator_numRecordsIn{job_id="c8a3d1...",job_name="etl_kafka_to_mysql",numRecordsIn="calculate",operator_id="x",operator_name="KafkaConsumer",task_attempt_num="0",task_attempt_id="...",task_id="...",task_name="Source: KafkaSource",tm_id="..."} 10293847

这个指标的意思是某个 TaskManager 上的某个任务从 Kafka Source 收到了 10293847 条记录。标签太多，导致每个人的 PromQL 都会因为漏标签而查不到数据。我推荐写查询时使用正则或向量匹配，比如：

promql复制sum by (job_name, task_name, tm_id) (flink_taskmanager_job_task_operator_numRecordsIn)

这样能按作业、算子、TaskManager 维度聚合，忽略掉不需要的 operator_id 细节。

3.4 指标抓取延迟与时间戳问题

Prometheus 抓 Flink 指标时，Flink 返回的指标没有显式的时间戳，Prometheus 会用自己的抓取时间作为时间戳。这本身没问题，但如果 Flink 侧的 metrics.reporter.prom.interval 设置得很长，比如 60 秒，而 Prometheus 15 秒抓一次，那 4 个抓取样本里可能有 3 个是同一份底层数据，图像看起来就是阶梯状。如果你想做精细的延迟监控，把 Flink 侧 interval 调到 5~10 秒。

还有一点，Flink 的 Counter 指标在导出时会先取当前计数值，prometheus 抓走后这个值不会清零，这是对的，Counter 本来就是累计值。但是有些 Flink 指标叫 numRecordsInPerSecond、numRecordsOutPerSecond，本身已经是每秒速率，Prometheus 里直接画就得到速率曲线，不要再套 rate() 函数，否则会有二次差分导致曲线抖动。

4. 最该盯着的指标和 Grafana 面板设计

指标抓进来了，Prometheus 也显示 UP 了，这时候最怕的就是打开 Grafana 一脸懵，不知道该建哪些面板。我按监控层次把核心指标分成四组：作业状态、资源、checkpoint、反压，然后分别给你对应的 PromQL。

4.1 作业存活与资源配置面板

作业存活是 7x24 值班第一关心的。Flink 暴露了 flink_jobmanager_job_numRestarts，但注意它是 Gauge，重启一次值就加一，重启后不会归零。你查"最近 5 分钟是否重启"要用 increase(flink_jobmanager_job_numRestarts[5m]) > 0，不能直接 rate()，也不能一看到值大于 0 就告警，因为只要作业历史上重启过，这个值永远大于 0。

资源面板主要看 TaskManager 的 JVM 和网络。推荐这几个指标：

promql复制# TaskManager 堆内存使用率
sum(flink_taskmanager_status_jvm_memory_heap_used) / sum(flink_taskmanager_status_jvm_memory_heap_max)

# 处理器负载
rate(flink_taskmanager_status_cpu_load[1m])

把这三个图放一行，基本能判断是资源瓶颈还是数据倾斜。

4.2 Checkpoint 与延迟指标面板

Flink 的 checkpoint 相关指标在 Job 级别非常有用。最核心的两个：

promql复制# 最近一次 checkpoint 耗时
flink_jobmanager_job_lastCheckpointDuration

# 最近一次 checkpoint 大小
flink_jobmanager_job_lastCheckpointSize

如果你配置了增量 checkpoint，flink_jobmanager_job_lastCheckpointSize 是这次增量的大小，不是累计大小，画图时要注意趋势。还有一个特别容易忽略的指标是 flink_jobmanager_job_checkpointAlignmentTime，它反映的是 barrier 对齐时间，如果这个值一直很高，说明算子处理速度跟不上上游，数据在 checkpoint 对齐环节积压。

我通常建一个 "Checkpoint 健康度" 面板，把 lastCheckpointDuration 和 checkpointAlignmentTime 放在同一张图上，纵轴统一为毫秒，两个曲线就能直观对比。如果对齐时间长期占 checkpoint 总耗时的 80% 以上，就需要考虑增加并行度或者优化核心算子逻辑。

4.3 反压和繁忙程度：看这条曲线就能定位瓶颈

Flink 1.13+ 提供了比较直观的反压指标，比如 flink_taskmanager_job_task_isBackPressured 和 flink_taskmanager_job_task_isBusy。它们都是 0 或 1 的布尔值，但并算子维度会按照子任务粒度暴露。一个比较实用的方式是：

promql复制avg by (job_name, task_name) (flink_taskmanager_job_task_isBackPressured)
avg by (job_name, task_name) (flink_taskmanager_job_task_isBusy)

分别画出背压和繁忙程度，就能看到哪个算子是"红绿灯"。如果 Source 的繁忙度很高而背压不高，那说明 Source 在拼命拉数据但下游处理不过来；如果某个 Transform 算子的背压为 1，那瓶颈大概率就在这个算子，比如 join 状态太大、外部 IO 太慢。

我建议面板里别放太多指标，四五个核心图即可，否则值班时间根本盯不过来。重点图依次是：作业重启次数、Checkpoint 耗时、输入输出速率、反压/繁忙曲线、JVM 堆内存。这五张图组成一屏，日常巡检扫一眼就够了。

4.4 常见聚合与格式化技巧

Grafana 里写 PromQL 有两个特别常见的坑。第一个是标签匹配，如果你在查询里直接写 flink_jobmanager_job_numRestarts，因为作业名不同，会得到多个时间序列，图例一团糟。要习惯性地加上聚合，比如 sum(flink_jobmanager_job_numRestarts) by (job_name) 或 max(...) by (job_name)。第二个是单位换算，flink_taskmanager_status_jvm_memory_heap_used 的单位是字节，Grafana 里要把 unit 设置成 bytes，否则数字大得离谱。lastCheckpointDuration 单位是毫秒，unit 选 milliseconds；如果不对齐，画出来的曲线数值差着数量级，完全没法看。

还有一点，如果你给 Flink 作业设置了自定义标签，比如通过 metrics.reporter.prom.scope.variables.additional 配置全局标签，或者你直接在指标上报路径里加了 flink_hostname 之类的标签，那么在 Grafana 变量里做 label_values(flink_jobmanager_job_numRestarts, job_name) 这类下拉框很容易漏掉标签值。这里我给个小技巧：用 label_values(flink_jobmanager_job_numRestarts, job_name) 能拿到作业名列表，但如果你同时跑了很多历史作业，还要在查询里加上 job_name=~"$job_name" 这样的过滤，才不会把已删除作业的指标也翻出来。

5. 告警规则：让告警在问题发生时就响起来

只画图不做告警等于白搭。Prometheus 的告警链路是：Prometheus 对规则文件的告警表达式周期求值，命中后发给 Alertmanager，再由 Alertmanager 路由到钉钉、企业微信、邮件等渠道。Flink 监控的告警规则，我的心得是先做生存类和 checkpoint 类，再做业务数据延迟类。

5.1 最基本的告警规则示例

下面是我经常使用的告警规则文件，直接放在 Prometheus 的 rules 目录里：

yaml复制groups:
  - name: flink_alerts
    rules:
      - alert: FlinkJobRestarted
        expr: increase(flink_jobmanager_job_numRestarts[10m]) > 0
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "Flink 作业 {{ $labels.job_name }} 在 10 分钟内发生重启"
      - alert: FlinkLastCheckpointTooOld
        expr: time() - flink_jobmanager_job_lastCheckpointTimestamp > 300
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "作业 {{ $labels.job_name }} 最近 checkpoint 时间超过 5 分钟"
      - alert: FlinkTaskManagerDown
        expr: up{job="flink"} == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Flink 目标 {{ $labels.instance }} 无法抓取"

第一个规则用 increase(...[10m]) > 0 而不是直接查 numRestarts，就是前面说的 Gauge 陷阱。第二个规则用 flink_jobmanager_job_lastCheckpointTimestamp，注意这个指标如果你没有显式暴露，可能在指标列表里看不到。如果没有，可以用 flink_jobmanager_job_lastCheckpointDuration 反推，但最好的方案是让 Flink 指标里包含时间戳字段。如果你发现 /metrics 里确实没有 lastCheckpointTimestamp，可以用 max_over_time 曲线做近似，或者升级 Flink 版本，新版默认暴露的指标更全。

5.2 告警去重与静默：别在升级时被电话吵死

Alertmanager 里要配置好 inhibit 规则，意思是一个大类告警出现时，抑制更小类的告警。比如你因为重启导致的 checkpoint 超时，没必要同时报 FlinkJobRestarted 和 FlinkLastCheckpointTooOld 两条，那样值班人员会被轰炸。我通常把 checkpooint 超时规则挂上依赖重启的抑制规则：

yaml复制inhibit_rules:
  - source_matchers:
      - alertname = FlinkJobRestarted
    target_matchers:
      - alertname = FlinkLastCheckpointTooOld
    equal:
      - job_name

这样作业因为重启导致 checkpoint 断掉时，只报重启告警，等重启解决后 checkpooint 告警自然恢复。还有一个我常用的静默操作：每次 Flink 集群升级前，我会先在 Alertmanager 里配一个静默，静默匹配 job_name=~".*upgrade.*" 或者维护窗口时间，避免升级期间大量告警导致大家麻木。

5.3 告警阈值怎么定才不误报

阈值定得不好，告警规则等于没有。我给出几个经验值参考：

指标	我常用的阈值	说明
numRestarts	10分钟内 > 0	正常作业不应重启，偶发一次也要查
lastCheckpointTimestamp	time() - 指标 > 300s	默认 checkpoint 间隔是 1 分钟，超过 5 分钟说明有问题
消费延迟/积压数量	与业务相关，建议用环比	绝对阈值容易误报，需要历史基线
TaskManager 堆内存使用率	> 90% 持续 15 分钟	配合 GC 曲线判断
反压时间占比	> 0.8 持续 10 分钟	高反压不一定是故障，有时是流量高峰

例如 lastCheckpointTimestamp 的阈值，你作业如果 checkpoint 间隔设成了 5 分钟，那 5 分钟阈值就不合适。建议先通过一段时间的数据确认正常基线，再定阈值。不要拍脑袋。

6. 集成了之后我踩过的坑和排查手段

最后这部分内容，是我最想分享的。因为网上讲配置的很多，讲"为什么你配置对了还看不到数据"的很少。我把亲身踩过的几个主要坑按现象、原因、排查手段的顺序写出来。

6.1 指标明明配好了，Prometheus 却只有 JobManager 的 target

现象就是 Prometheus 的 target 列表里只有 JobManager 的 9249，TaskManager 的 target 始终 DOWN 或者根本没出现。排查要先确认 TaskManager 上 curl http://tm-ip:9249/metrics 是否有响应，如果没有，多半是 Flink 的 reporter 只在 JobManager 加载了。可能原因是你把 flink-metrics-prometheus-*.jar 只放到了 JobManager 的 lib 里，而 TaskManager 的 lib 没放。很多发行版会把 JobManager 和 TaskManager 装在不同目录，需要同步。另一个可能原因是 TaskManager 启动时 flink-conf.yaml 里 reporter 配置没被读到，你需要查看 TaskManager 日志，确认是否有 PrometheusReporter 启动的 INFO。日志里没有，就不要去 Prometheus 层折腾了。

6.2 PushGateway 模式下多个作业指标互相覆盖

如果你用了 PushGateway，会经常发现两个不同作业的指标聚合出来后完全串了。原因在于 Flink 默认会按作业名作为 PushGateway 的 grouping label 的一部分，如果两个作业 jobName 设置了同一个值，或者你显式配置的 jobName 有冲突，后推送的就会覆盖前面的指标。排查时直接看 PushGateway 的 Web UI，http://pushgateway:9091 下能看到当前所有 group 的 label 组合。如果发现两个作业的 grouping key 完全一样，那就该考虑给每个 job 设置独立的 metrics.reporter.promgw.jobName，或者在提交作业时通过 -Dmetrics.reporter.promgw.jobName=my-job-xxx 覆盖。其实这也是我为什么一直提倡用 pull 模式的原因之一，pull 模式下每个 target 天然独立，标签不冲突。

6.3 指标基数爆炸：这个坑最隐蔽

很多团队没注意，Flink 指标加上 task_id、operator_id、task_attempt_id 一类的标签后，指标基数会非常夸张。一个并行度 100 的任务，每个子任务 5 个指标，就是 500 个时间序列，如果 prometheus 还按 15 秒抓取，存储会快速增长。我的解决方式是：在 flink-conf.yaml 里把不需要的变量排除掉，比如只保留 job_name、task_name，不加 operator_id；如果确实需要按算子排查，可以单独再配一个粒度的 target 给 Prometheus，否则全量采集只留必要指标。这个优化很重要，尤其是集群里跑了几十个作业时，Prometheus 内存会首先撑不住，不是磁盘不够。

Grafana 那边也可能因为高基数标签把变量下拉框卡死，比如用 label_values(flink_taskmanager_job_task_operator_numRecordsIn, operator_id) 做筛选，而 operator_id 有几百个取值，每次打开面板都慢得不行。这种变量要尽量用常用作业名维度替换。

6.4 抓取周期与 Flink 内部更新周期不匹配的另类故障

还有一次我遇到一个奇怪的现象：Grafana 里面 flink_jobmanager_job_lastCheckpointDuration 曲线是锯齿状，峰值和谷值比实际波动还大。后来定位发现不是计算问题，而是 Prometheus 抓取间隔 30 秒，而 Flink 侧 reporter interval 也是 30 秒，两个周期错位导致有时候抓到的是上一轮数据，有时候抓到的是最新数据。这种情况下把 Flink 侧 interval 调成 10 秒，Prometheus 保持 30 秒，问题就消失了。这不是数据错了，而是采样耦合导致的错觉。

你可以通过配置 metrics.reporter.prom.interval: 10 SECONDS 并重启 Flink 来验证。如果不想重启，先加长 Prometheus 的 scrape_interval 达到等效效果，但这会影响其他监控，一般不建议。

6.5 排查过程中的最后一个工具：直接看原生指标

如果你实在查不到某个 Flink 指标，最不绕弯的办法是直接在浏览器访问 http://taskmanager:9249/metrics，然后 Ctrl+F 搜关键字。比如你想确认 checkpoint 相关指标有没有暴露，就搜 checkpoint；想确认是否有 lastCheckpointTimestamp，直接搜这个关键词。这个方法看着简单，但比看文档有效得多，因为不同小版本之间指标名会有调整，网上很多文章写的指标名在你版本里根本不存在。看完原生指标后，再回 Prometheus 里验证 flink_ 前缀的转换结果，两分钟就能定位是配置问题还是命名问题。

7. 后续还能怎么扩展这套监控

当 Flink 和 Prometheus 的官方指标链路稳定之后，还会发现很多业务层面指标有缺失，比如 Kafka 消费组 lag、写 MySQL 的结果表成功率、某个核心算子的业务累计值。这些都可以通过在 Flink 自定义指标的方式暴露给 Prometheus。在 RichFunction 的 open() 方法里通过 getRuntimeContext().getMetricGroup().counter("my_business_count") 注册一个 Counter，然后在处理每条数据时调用 inc()，Prometheus 下一次抓取就能看到带作业名和任务名标签的业务指标。这是我强烈建议做的，因为只有业务指标才真正反映作业价值，不然监控再全也只是运维层面的健康。

另外一个扩展方向是告警收敛。Flask 和 Flink 集群如果规模一大，Alertmanager 的路由树会变得很复杂。我一般会按业务线划分 job_name 标签，然后在告警规则里用 job_name=~"kafka.*|rt.*" 分组，不同告警路由给不同值班群，避免全组人都被无关告警轰炸。

跑到现在，这套链路已经稳定陪我过了好几个版本的 Flink 升级。每次大版本升级后我第一件事不是看 SQL 改没改，而是先看 Prometheus target 和指标形态有没有变化。只要指标还在、曲线还是那个形状，我心里就有底。这篇文章写的是我自己的实操过程，希望对你也有参考价值。如果你在集成过程中遇到什么奇怪的现象，也建议先从原生指标和日志两头入手，往往比在配置文档里找答案快得多。