★ FEATURED ARTICLE 在数据开发一线待久了你会发现一个特别扎心的现实Flink作业上线只是万里长征第一步真正让人头秃的是它跑起来之后那几个月。作业是不是还活着、吞吐有没有掉、有没有在疯狂重启、Checkpoint是不是快撑不住了——这些问题如果全靠人肉盯Web UI那夜里的告警电话基本就别想消停了。所以“Flink监控”这件事本质上是给数据作业做一套系统化的“健康检查”机制让我能在问题把业务打垮之前提前看到苗头。这篇东西就是一份实操向的指南不是教科书是我自己在生产环境里折腾Flink监控的经验沉淀适合正在做实时数仓、负责Flink平台运维、或者被分配了“给实时作业搞个监控”但不知从何下手的同学参考。1. 监控体系搭建前的设计思路先搞懂要看什么1.1 健康检查不是“看任务死没死”很多人一提监控第一反应是“作业挂了能告警就行”。但等你真正面对一打Flink作业的时候会发现这个标准低得离谱。作业进程活着不代表它就是健康的——它可能正在背压泥潭里挣扎吞吐已经掉到正常水平的十分之一它可能在无限重启每次起来跑两分钟又崩恢复策略形同虚设它的Kafka消费位点已经落后几个小时数据延迟大到业务方已经开始骂街。所以我理解的Flink作业健康检查至少应该覆盖四个层面存活状态、处理进度、资源水位、稳定性趋势。存活状态解决“挂没挂”处理进度解决“快不快”资源水位解决“够不够”稳定性趋势解决“会不会挂”——这四个层面合在一起才是一份完整的体检报告。只盯其中一个都容易在故障来临的时候被打个措手不及。1.2 监控的三个视角集群、作业、算子搭监控体系之前先分清视角不然很容易眉毛胡子一把抓。集群视角关心的是整体资源情况和JobManager/TaskManager的健康状态比如还有多少TaskManager存活、Slot使用率多高、整个集群有没有频繁Full GC的问题。作业视角关心的是单个作业的运行质量比如Checkpoint是否正常完成、重启次数是否异常、端到端延迟是否在可接受范围。算子视角则下沉到具体算子的尺度比如source的消费速率、某个keyed算子的处理耗时、水印是否在正常推进。这三个视角没有优劣之分它们是层层嵌套的。集群异常会传导到作业作业异常会传导到算子。实操中比较合理的做法是集群视角做成全局大盘作业视角做成重点作业的独立巡检页算子视角留着排查问题时再针对性查。不要一上来就在Grafana里堆几百个面板那只会让你在大屏前迷失。1.3 我最终确定的方案选型为什么不走“重量级全家桶”当时摆在我面前的有几条路一是用Flink自带的Web Dashboard凑合看简单但基本没有告警能力还是被动等人去看二是引入Apache Flink Prometheus Grafana Alertmanager这套主流组合社区资料多、踩坑成本低三是自研Metrics Reporter推送到内部监控系统灵活但开发和维护成本都不小。我选了第二条路。理由很简单这套组合的每一环都有成熟的开源方案支撑Flink官方原生支持Prometheus ReporterGrafana社区里有现成的Flink Dashboard模板Alertmanager的告警路由规则足够灵活。最关键的是我可以把Flink监控和公司其他大数据组件的监控覆盖在同一个Prometheus里运维心智负担小。至于自研方案除非你们监控团队人力富余且有明确的定制需求否则我不建议作为第一选择——你的核心目标是发现作业异常不是造监控轮子。2. 核心指标拆解每个数值背后都有故事2.1 集群级指标一切异常的源头JobManager和TaskManager的JVM状态是集群健康的地基。重点关注这几个指标堆内存使用flink_jobmanager_Status_JVM_Memory_Heap_Used和对应的TaskManager版本、非堆内存使用尤其是Direct MemoryFlink的网络缓冲大量用堆外内存Direct Memory超限会直接爆出OutOfMemoryError、GC次数和耗时Flink任务对GC非常敏感频繁Full GC会导致长达数秒的Stop-The-WorldCheckpoint必挂。另一个容易被忽略的指标是TaskManager的网络缓冲池使用情况。Flink的TaskManager间数据传输依赖Netty的内存池如果inbound/outbound队列积压说明上下游算子之间已经出现速率不匹配这就是反压的早期信号。实操里可以看flink_taskmanager_Status_Network_AvailableMemorySegments这个指标当可用内存段长期处于低位基本就可以判定存在持续的背压或倾斜。集群级还有一类指标是运行作业数和Slot使用率。正常情况下这两个数应该相对稳定如果出现作业数不变但Slot使用率持续上升多半是某个作业在反复重启每次重启都尝试申请新的资源但没有正确释放旧资源。2.2 作业级指标健康检查的主干作业级指标里我最看重三个Checkpoint系列指标、重启次数、延迟水位。Checkpoint可以看作是Flink作业的“心跳体检”。最关键的判断规则是如果Checkpoint连续失败或者完成时间持续接近超时阈值这个作业离挂掉就不远了。具体看这几个指标flink_jobmanager_job_lastCheckpointDuration最近一次Checkpoint耗时、flink_jobmanager_job_numberOfFailedCheckpoints失败次数、flink_jobmanager_job_currentCheckpointRestoreTimestamp恢复时长。我在生产里定的经验阈值是Checkpoint完成耗时如果超过Checkpoint间隔的60%就得引起警惕。打个比方如果你设置10分钟做一次Checkpoint但每次完成耗时已经到6分钟以上说明状态数据量太大或者持久化链路有问题得赶紧排查。重启次数这个指标更好理解但注意不要只看绝对值。一个每周因为发布而正常重启一次的作业和一个每小时重启十次的作业完全不是一个健康等级。比较好的做法是监控单位时间内的重启频次比如一小时内重启超过3次就告警而不是简单设置“重启大于0就报警”。延迟水位体现作业的数据新鲜度。最直观的是Kafka ConsumerLag它反映了source消费速率和上游生产速率的差值。我更建议把Lag的变化速率也一起监控连续上升5分钟以上才说明真的追不上短暂波动不用管。这里有一个简单的计算如果积压了100万条数据每秒消费2000条那清空积压需要500秒你可以用这个公式辅助判断“到底要不要扩容”。2.3 算子级指标定位问题出在哪一段集群级和作业级的指标告诉你“有问题”算子级指标告诉你“问题在哪”。最常用的组合拳是backpressure指标 吞吐指标 水印指标。Flink在1.13之后提供了基于Task的背压指标可以直接通过Web UI或者Metric看到每个Operator的BackPressure百分比。生产环境我一般这样判断某个算子背压持续超过50%说明它的下游处理速度跟不上上游产出如果背压从0直接冲到100%物理指标问题往往不在算子本身的算力而是网络或序列化环节出了异常。吞吐指标主要看numRecordsIn和numRecordsOut。正常作业这两个数值应该比较接近如果某个算子的in远大于out说明数据在这个算子内部堆积。水印指标currentInputWatermark则能帮助你判断事件时间是否在正常推进——水印长时间不动大概率是某个source分区没有数据或者keyBy后的某个key数据倾斜导致。核心提醒算子级指标不要全部酿成Grafana面板长期展示那是排查时候的放大镜不是日常巡检该盯的仪表盘。日常盯集群和作业两级就够了算子级等出问题再下钻。3. 监控系统搭建实操从配置到看板的全过程3.1 开启Flink的Prometheus ReporterFlink官方提供了现成的Prometheus指标上报支持你要做的是在flink-conf.yaml里把Reporter打开。核心配置如下metrics.reporter.promtheus.class: org.apache.flink.metrics.prometheus.PrometheusReporter metrics.reporter.promtheus.port: 9249 metrics.reporter.promtheus.interval: 10 SECONDS注意有两点容易踩坑。第一class那个配置项网上很多老教程写的是PrometheusReporter.class但这在新版本里已经不行了必须写完整限定类名。第二port配置项建议为每个TaskManager设置不同的端口或者使用端口范围。因为如果多个TaskManager跑在同一台机器上YARN模式常见端口冲突会直接导致Metrics上报失败。我一般配置成9249-9255这种范围省去手动分配的烦恼。改完配置后把Flink发行版的opt目录下对应的flink-metrics-prometheus-xxx.jar拷贝到lib目录然后重启集群。如果用的是Flink on YARN这种动态资源模式每次提交作业都要确保这个jar在TaskManager的classpath里——最简单的方法就是把jar放到HDFS上的Flink发行包路径里。3.2 采集链路与Prometheus配置Flink通过HTTP端口暴露MetricsPrometheus只需要配置静态目标或者服务发现去抓取就行。我这里以静态配置示例scrape_configs: - job_name: flink metrics_path: /metrics static_configs: - targets: - flink-jm-01:9249 - flink-tm-01:9249 - flink-tm-02:9249 labels: cluster: production如果你是YARN或者K8s模式部署TaskManager的IP和端口是动态的静态配置就不够用了。YARN环境下我常用PushGateway模式在flink-conf.yaml里改用Pushgateway Reporter让TaskManager主动把指标推到PushGatewayPrometheus再统一从PushGateway抓取。K8s环境则直接走PodMonitor的服务发现让Prometheus Operator自动找到带flink标签的Pod。有一点要特别注意Flink的指标名里带有JobManager和TaskManager这些大写字母Prometheus的指标名规范是不允许大写的。好在Flink Reporter会自动把大写转成小写所以你在Prometheus里最终看到的是flink_jobmanager_job_...这样的指标名。排查问题的时候不要因为大小写对不上而困惑。3.3 Grafana看板别从零开始但也要二次加工Grafana这边我推荐直接在Grafana社区找Flink Dashboard模板搜索框输入flink、dashboard id人气高的模板比如ID为15965的那个Flink Dashboard基本涵盖了JobManager/TaskManager的JVM、CPU、内存、网络等常用视图。导入模板时注意选择对应的Prometheus数据源再把cluster的变量值改成你自己的环境标签如果你在Prometheus配置里加了cluster: production这里就要对应设置。不过直接导入的模板通常只覆盖到集群级和部分作业级指标我会建议自己补几个实用面板。第一个是作业活跃度面板核心表达式是sum(flink_jobmanager_job_uptime{job~$job}) / 1000单位转成秒直观看到作业在线时长。第二个是Checkpoint趋势面板把最近N次Checkpoint的耗时和失败次数画出来一眼看出有没有劣化趋势。第三个是消费延迟面板核心表达式是flink_taskmanager_job_operator_kafka_consumer_current_lag_gauge我还会按job_name做分组做出一个“哪些作业延迟最危险”的降序排行这个我觉得比看单个绝对值有用得多。这样二次加工后的看板才有灵魂集群底层的资源状况一眼看到作业的运行质量有趋势曲线出了问题能在30秒内定位到“是资源不够还是作业本身有毛病”这个大方向再去翻算子级指标。这就是监控该有的效率。4. 告警规则设计把“狼来了”变成“狼真的要来了”4.1 告警不是越多越好而是分级越清晰越好监控搭建最怕的就是告警疲劳——每五分钟响一次的告警最后大家会直接无视真正出事的时候反而没人响应。所以告警规则必须分级、限量。我生产环境里只保留四类告警优先级从高到低第一类是存活类告警优先级最高。判断条件是up{jobflink} 0或者作业长时间运行却无指标上报。这类告警意味着作业已经挂了或者采集链路断了直接打电话给值班人。第二类是Checkpoint连续失败告警连续3次Checkpoint失败就触发因为这意味着状态一致性得不到保障故障恢复后必然丢数据或回放到更早的位点。第三类是消费延迟趋势告警。不盯绝对值盯变化率持续5分钟以上增长才报警。这里有一个巧妙的处理我把告警表达式写成deriv(flink_taskmanager_job_operator_kafka_consumer_current_lag_gauge[5m]) 0代表“延迟在持续增加”而不是“延迟超过某个数字”。绝对值阈值容易在大促等流量变化时误报趋势判断反而不容易误伤。第四类是资源水位告警TaskManager堆内存使用率超过85%持续10分钟才告警。加上持续时间条件是为了过滤掉GC引发的瞬时抖动避免告警轰炸。比如GC之后内存回落到正常水平就不该触发。4.2 Alertmanager配置里的两个细节Alertmanager的详细配置网上很多我这里只提两个我实际踩过坑的细节。分组聚合要开。一个TaskManager出问题往往导致几十个指标同时告警如果不分组告警会直接刷屏。我用的是group_by: [alertname, job_name] group_wait: 30s group_interval: 5m repeat_interval: 4h这样同一个作业的多个告警会合并成一条消息而不是一屏红。静默时间要规划。日常发布窗口期、凌晨低峰期如果连续重启几次作业告警价值是不高的。我在Alertmanager里配置了每周一至周五凌晨2点到4点的静默规则把这些时段内的非存活类告警压掉活着的时候大家真的在睡觉别用噪音吵醒人。但注意存活类告警永远不能静默。作业挂了就是挂了什么时候挂都要有人处理。这是底线。4.3 一个实用的恢复策略告警恢复不等于你什么都不用做告警恢复或者静默之后一定要有一个“认领-处理-复盘”的机制不然告警就成了摆设下次相似问题还是会池子炸开。我自己的习惯是每次触发告警都去Grafana把对应时间段的指标截图存到问题跟踪文档里同时在告警闭环之后复盘一次“这个故障如果提前看到哪个指标可以避免”。坚持做下来你对监控指标的敏感度会提升得飞快你会慢慢懂得“哪些指标变了是小事哪些指标变了必须马上停手”。这对大数据开发来说比多写几个SQL值钱得多。5. 常见故障与排查思路这些坑我替你踩过了5.1 Checkpoint频繁超时先把背压拉出来审一审Checkpoint超时是Flink作业最典型的心跳异常。我第一次遇到的时候第一反应是去调大execution.checkpointing.timeout结果越调越大作业死得越惨。后来经验告诉我Checkpoint超时的根因往往不是“给它的时间不够”而是“给定的时间根本完不成”这就需要往下挖三层。先看完整时间段内的Checkpoint耗时走势是缓慢增长还是一夜之间暴涨。缓慢增长大概率是状态数据在持续膨胀需要对状态进行清理开启TTL或调整状态后端配置。一夜之间暴涨大概率是数据流量突增或者上游某张表数据量暴涨导致状态写入变慢。这时候再看反压指标——如果背压从0飙到50%以上说明某个算子已经处理不过来了这比单纯调大超时时间靠谱得多。最后再看Checkpoint的Checkpointed Data Size和Persisted Data Size两个数值如果数据量本身不大但耗时很长那多半是RocksDB的写入瓶颈或者和外部存储之间的带宽问题。排查链路是耗时趋势 → 背压状态 → 状态大小 → 存储层性能按这个顺序走一般不会跑偏。5.2 监控指标突然消失十有八九是端口或网络问题之前遇到过诡异问题某个TaskManager上报到Prometheus的指标突然全没了但作业本身运行正常日志也没报错。排查了很久才发现TaskManager分配给Prometheus的Metrics端口是9090和同一台机器上部署的某个组件的端口冲突了。Flink的Reporter端口冲突时不会报Flink自己的错误日志它会尝试绑定端口失败后直接禁用这个Reporter表现就是“指标悄然消失”。所以每次Metrics消失我的排查顺序是先看Flink日志里有没有PrometheusReporter相关异常再看端口能不能通用curl http://ip:port/metrics在TaskManager本机验证一下抓取源是否还活着最后看Prometheus的目标页面/targets是显示up还是down。这个链路走完80%的问题都能定位。要多带一个提醒Prometheus抓取器默认有scrape_timeout如果你的reporter设置的是10秒上报间隔但scrape timeout设的5秒就可能出现每次抓取都超时的情况。这类问题从Prometheus端看up状态你会发现一切正常但数据会一直有整块的缺口。5.3 TaskManager频繁重启别只看日志先看JVM内存TaskManager反复重启比JobManager重启更隐蔽因为作业在恢复机制下会不断重试你从作业状态上看不到“挂”只看到“重启次数持续累加”。日志里能看到的异常五花八门但高频的全是这两类堆内存OutOfMemoryError和直接内存OutOfMemoryError。堆内存爆了看-Xmx是不是真的够用再配合GC日志看是不是存在大量无法释放的长期存活对象。直接内存爆了看taskmanager.memory.task.off-heap.size和taskmanager.memory.network.memory.max配置是否合理。经验值是网络缓冲内存一般分配为总内存的10%左右就够了堆外任务内存则要根据你作业里使用堆外状态的数量多少来灵活调整。多看一个Flink UI上的“Memory”标签页上面有每个TaskManager的堆内存使用曲线。如果看到堆内存持续增长且GC后也不回落多半是代码层面有内存泄漏——这是最麻烦的情况只能靠HeapDump逐类分析了。5.4 告警风暴作业重启的一个连环噩梦作业重启后最容易出现告警风暴。原因很简单重启瞬间作业从零开始消费消费延迟打满、Checkpoint失败计数器瞬间升高、背压指标全是100%……所有指标全红。但这时候告警几乎没有参考价值因为作业本来就是启动初始化阶段。我处理这个问题的办法有三个可以搭配使用。第一告警规则里加持续时间条件比如“持续10分钟才触发”这样启动期的瞬时异常能在时间维度上被过滤掉。第二在Alertmanager里针对“作业刚刚恢复”的窗口期设置临时静默用脚本在检测到作业重启后自动拉一条静默规则静默时间设为恢复后的20分钟。第三告警表达式尽量用变化率而不是绝对值例如消费延迟用“持续增长”来判断而不是“超过某个阈值”——启动天然就有延迟但只要在快速追平就不算故障。这三个招下来告警洪水的概率能下降八成以上。5.5 背压不是越早处理越好留一部分背压反而更健康这点算是多次踩坑后的心得很多人看到背压超过0就紧张但我现在反而不这么看。Flink的设计里背压是一种天然的流量调节机制数据速率不匹配时让背压来缓冲是正常的。真正危险的是背压持续高位不回落这意味着系统长期处于接近崩溃的边缘。如果是偶发的、短周期的背压峰值我反而认为是系统在自我调节不用干预。一个经验判断背压在20%-40%之间波动且没有伴随着Checkpoint超时或吞吐下降可以放着不管背压稳定超过60%且吞吐同步下降就要开始排查了背压封顶100%长时间不降并且满队列这时候鲸落大潮就不会远了。这个阈值各家产品不同你可以通过对比正常时段和异常时段的背压曲线找到属于自己集群的“基线水位”。6. 写在最后这类监控体系还能怎么长、怎么变我在实际使用中有一个很深的体会监控的建设永远不会“结束”它是一个跟着业务和集群规模不断生长的系统。刚开始你可能只需要一个Grafana看板应付“作业别挂”的诉求等到作业多了你会发现需要分组管理、告警分级再往后你会希望监控体系能自动做一些预判比如根据状态增长趋势预测Checkpoint什么时候会超时根据消费速率和生产速率的差值预测延迟什么时候会超过业务SLA。这些都能基于现在这套指标体系和数据积累往上游延伸。最后再分享一个小技巧给所有作业统一打上team、service、env这几个标签你后续做告警路由、成本分析、按团队隔离视图的时候会发现这几个标签的价值巨大。它不花一分钱监控成本但能让整个监控体系的扩展性立刻上一个台阶。监控的核心思路一直都是不是把数据堆出来让人看而是在正确的时间把正确的信息送到正确的人手里。这个方向走对了工具用哪个反而是次要的事。
阅读完成 · 觉得有帮助？
