去年双十一前的某个深夜平台值班群突然炸了。离线数仓的 Spark 任务从晚上八点开始大面积失败等我们发现问题时数据看板已经断了快三个小时。最尴尬的是点开 Spark Web UI单个任务的执行情况都能看到页面上的红叉清清楚楚但整个集群几百个作业没有任何一个汇总视角能提前告诉我们“资源正在恶化、任务正在大面积重试”。那次之后我下定决心给这套 Spark 计算平台做一次真正意义上的实时监控体系升级。这篇文章不聊空泛的大数据平台架构概念只讲我在生产环境里从零搭建 Spark 实时监控系统的完整过程包括工具选型时的取舍、核心指标怎么定、实时采集链路怎么搭、告警规则怎么降噪以及靠这套监控抓到的真实问题。内容适合正在用 Spark 做离线或准实时计算、对作业稳定性有明确考核指标的团队参考也适合刚接触 Spark 运维、想搞清楚“监控到底该看哪些指标”的同学。整套方案踩过的坑我都会如实写出来能帮你少走不少弯路。1. 放弃 Web UI 和现成方案之前我遇到的三个现实问题很多人一听“Spark 监控”第一反应是“Spark 不是自带 Web UI 吗还需要自己搭”确实自带但真到了生产环境你会发现它离“能用”还有相当距离。我把自己在故障现场遇到的三类问题摆出来你大概就明白为什么要自建了。1.1 Spark Web UI 和历史服务在故障现场是缺位的Spark Web UI 的设计目标是“单作业视角”而不是“集群视角”。作业跑挂之后你确实能在页面上看到哪个 stage 失败、哪个 task 报错但这个页面只有作业粒度做不到横向对比。我有十几个流式任务同时在跑它们各自占了多少资源、哪个任务正处于 pending 状态、哪个 executor 的 Direct Memory 已经在濒临爆掉的边缘——Web UI 上是看不出来的。另一个问题是历史服务Spark History Server的数据生命周期有限。默认配置下EventLog 清理策略和 HDFS 目录容量会不断把旧日志删掉故障发生三天后再想去翻当时的完整现场经常发现事件文件已经被回收了。更要命的是如果 Driver 进程直接宕掉Web UI 页面也会一起消失而故障现场恰恰是监控数据最需要保留的时刻。1.2 开源监控方案与 Spark 作业生命周期错位我当时也调研过现成的开源组合Prometheus 加 JMX exporter、Ganglia、还有商业方案。最后得出的结论是它们都解决了一部分问题但都够不到 Spark 真正的故障点。举几个具体例子。JMX exporter 能抓到 JVM 层的内存和 GC 指标但这些指标反映的是“进程活着没有”没法回答“这个作业的 2000 个 task 为什么全部卡在 pending 状态”。Ganglia 的监控重心在操作系统层面——CPU、内存、磁盘 IO它对 Spark 内部的 Stage/Task/Shuffle 模型几乎没有感知。商业 APM 工具的 Spark 适配倒是做得深但成本高、配置重而且团队内部的网络策略不一定允许把作业元数据推到外部服务。1.3 我的结论三路数据源按用途分工而不是押注单一方案踩完一圈之后我定的设计原则是**不押注单一数据源而是让三路监控数据各司其职形成冗余。**第一路用自定义 SparkListener 采集作业生命周期和 Task 级指标这是主力数据源第二路通过解析 EventLog 做兜底保证 Driver 挂了监控链路也不断第三路用 JMX 抓 Executor 进程级内存和 GC补上 Spark 黑盒里的细节。三路数据统一落到 PrometheusGrafana 做可视化Alertmanager 负责告警。这套结构的好处是任何一条链路出问题另外两条还能撑住不会出现“监控系统先于任务挂掉”的讽刺局面。2. 指标体系真正值得监控的信号不超过 20 个监控系统最忌讳的不是指标太少而是指标太多。我见过有人一上来就把 Spark 的所有 Metrics 全量采集Grafana 上拉了几十个面板结果告警来了没人知道看哪里。我的原则很简单**指标必须能回答一个具体的运维决策问题。**如果一个指标上升了你不能确定下一步该干嘛那它就是噪音。2.1 先排除三个“看似有用实则骗人”的指标监控指标设计的第一步其实是做减法。有几个指标在纸面上很合理实际用了就知道容易被误导。第一个是“平均任务耗时”。一个 Stage 有 1000 个 task如果 999 个都在 5 秒内跑完1 个因为数据倾斜跑了 30 分钟平均值可能只到几十秒完全掩盖了长尾问题。这时候应该看 95 分位和 99 分位而不是平均值。第二个是“整体 CPU 使用率”。Spark 是分布式系统某个 Executor 所在节点 CPU 打到 95% 以上而集群整体 CPU 利用率只有 40%这种局部过热在平均值里根本看不出来但恰恰是任务执行不均的早期信号。第三个是“任务成功率”。在很多失败重试机制的保护下成功率长期维持在 99.9%但故障往往体现在同一批任务反复失败重试。相比成功率我更建议大家盯住“单位时间内的失败重试次数”和“任务从提交到真正开始执行的 pending 时间”这两个信号。2.2 长期保留的核心指标清单覆盖作业、Executor、系统三层经过一段时间打磨后我最终保留的指标其实就 20 个左右分成三层。第一层是作业生命周期层包括任务提交时间、启动时间、结束时间、状态、重试次数、pending 任务数和 running 任务数。这一层解决的是“作业本身是否健康”的问题。第二层是 Executor 层包括堆内内存使用峰值、堆外内存和 Direct Memory 使用量、GC 耗时与频率、Shuffle 读写字节数、Task 失败次数。这一层解决的是“作业为什么慢、为什么挂”的问题。第三层是系统资源层包括 Executor 所在节点的 CPU 使用率、磁盘 IO 等待时间、网络吞吐。这一层能帮我们识别集群级别的资源竞争。Mem这 20 个指标不需要全采全报关键在于每个指标都要有明确的观察窗口和阈值逻辑。比如 Direct Memory 使用量如果持续接近 JVM MaxDirectMemorySize 的 80%就应该进入预警而不是等到 OOM 之后才查。2.3 统计口径95 分位和 1 分钟窗口才是实时监控的及格线监控数据的统计口径比指标本身还重要。最开始我偷懒直接取了任务耗时的平均值结果告警要么不响一响就是大故障。后来统一改成百分位统计核心告警全部基于 95 分位OOM 类风险基于 99 分位。窗口大小也有讲究。5 分钟的窗口可以让曲线更平滑但对于实时监控来说太钝了。我最终采用 1 分钟窗口做聚合每 15 秒采集一次原始数据。这样既不会因为瞬时毛刺打爆告警又能保证在故障发生 3 到 5 分钟内被捕捉到。另一个关键经验是**告警规则要盯变化量而不是绝对值。**比如 pending 时间从 30 秒涨到 240 秒比“pending 时间为 240 秒”本身更有意义前者反映的是劣化趋势后者在凌晨批量任务高峰时可能很正常。3. 实时采集链路实现SparkListener、EventLog 与 JMX 三路并行采集层是整个监控系统的心脏。我踩过的坎基本都集中在这一层所以会讲得细一点。3.1 用自定义 SparkListener 拿作业内部的第一手状态Spark 内部自带了一套事件监听机制通过继承 SparkListener 可以拿到 application、stage、task 三个粒度的完整生命周期。这是最贴近故障现场的一路数据源。我在 onTaskEnd 回调里提取每个 task 的执行耗时、GC 时间、Shuffle 读写字节数、内存溢出量等指标在 onStageCompleted 回调里做一次统一聚合然后批量上报。这里特别提醒一个坑不要在 onTaskEnd 里做高延迟的网络 IO。一个作业有几千上万个 task如果每个 task 结束都走一次 HTTP 请求上报采集本身就会拖慢作业执行甚至把 Driver 的资源抢走。我最初就是在这里翻车的后来改成在 stage 完成时统一聚合成一个指标点再批量推给 Prometheus单次上报耗时从秒级降到了几十毫秒。class MetricsSparkListener(reporter: MetricsReporter) extends SparkListener { override def onTaskEnd(taskEnd: SparkListenerTaskEnd): Unit { val metrics taskEnd.taskMetrics // 把单 task 维度的关键指标缓存到本地缓冲区 pendingTaskSnapshot.add( TaskMetricSnapshot( stageId taskEnd.stageId, executorRunTime metrics.executorRunTime, executorDeserializeTime metrics.executorDeserializeTime, jvmGCTime metrics.jvmGCTime, memoryBytesSpilled metrics.memoryBytesSpilled, diskBytesSpilled metrics.diskBytesSpilled, shuffleReadBytes metrics.shuffleReadMetrics.totalBytesRead, shuffleWriteBytes metrics.shuffleWriteMetrics.bytesWritten ) ) } override def onStageCompleted(stageCompleted: SparkListenerStageCompleted): Unit { // stage 结束时聚合成一条指标用批量方式上报避免高频 IO reporter.reportStageSnapshot(buildStageSnapshot(stageCompleted.stageInfo)) } }3.2 EventLog 解析兜底不依赖 Driver 存活的第二条链路自定义 Listener 的致命弱点是跑在 Driver 进程里Driver 一挂这条链路就断了。为了不让“监控系统先于任务挂掉”我搭了第二条链路解析 Spark EventLog。具体做法是开启spark.eventLog.enabledtrue让 Spark 把执行过程写成 JSON 格式的事件日志然后在监控侧写一个消费程序去监听日志目录把 StageCompleted、TaskEnd 等关键事件解析出来推到 Prometheus。因为 EventLog 是落盘文件即使 Driver 崩溃、History Server 还在读旧数据我们也能从日志文件里恢复现场。关于 EventLog 的副作用实测下来性能损耗可接受。开启后每个作业的额外开销大约在千分级别相比故障排查时能节省的工时这点成本非常划算。唯一的注意点是要给 EventLog 单独规划存储目录和清理策略避免日志文件无限制增长占满 HDFS也别让它被清理策略误伤得太急。3.3 Executor 进程级指标拆掉黑盒才能看内存全景作业层面有 Listener 和 EventLog 之后还有一块经常被忽略的盲区Executor 的 JVM 内部状态。Shuffle 数据在内存和磁盘之间流动时到底占了多少内存Direct Memory 是不是快爆了GC 老年代是不是在持续增长这些信息只有 JMX 能给我们。我在每个 Executor 启动时额外开启了 JMX 端口配合 jmx_exporter 把堆内堆外内存、GC 次数和耗时、Direct Buffer 使用量等指标暴露出来。这里有一个非常典型的采坑点YARN 容器动态分配时 Executor 频繁启停固定 JMX 端口很容易冲突。我们后来改为动态端口分配并加入端口探测机制才彻底解决。3.4 采集链路常见坑序列化、丢数据、端口冲突再集中整理几个容易踩的坑。第一回调代码必须包一层 try-catch否则 Listener 里一旦抛异常会影响 Spark 本身的调度流程我自己就遇到过回调里一个空指针导致 task 结束事件处理失败整个 stage 卡住的情况。第二上报要批量化和异步化千万不要为了“实时”而用低效的同步上报。第三Prometheus 本身也可能挂所以采集侧要有本地缓冲我最后是用本地文件加定时重推的方式做了兜底确保 Prometheus 宕机期间数据不丢恢复后可以补传。4. 告警规则与降噪从每天五十条到每周两三条监控的价值最终要通过告警体现。第一版告警规则上线那天我印象特别深刻——一天五十多条告警值班同学被轰炸到直接静音等于所有告警都失效了。降噪做得不好监控系统还不如不搭。第二版我把重点放在了两件事告警分级和动态基线。4.1 告警分三级P0 故障、P1 劣化、P2 浪费我把告警分成三个层级对应不同的响应要求。P0 层是作业中断类事件比如大面积 task 失败、作业反复重试、异常退出这类问题直接导致数据产出延迟需要立刻通知值班走电话或者强提醒。P1 层是性能劣化类信号比如 pending 任务数持续上升超过三倍基线、Executor 堆外内存接近阈值、GC 老年代快速增长这类信号意味着作业正在走向失败但还有处理窗口进 on-call 看板即可。P2 层是资源浪费类观察项比如某作业长期占用资源但任务并发度极低、某个大 broadcast 占用了高比例 Executor 内存这类问题不紧急但值得沉淀到周报里推动优化。三层告警的响应时间要求完全不同这个区分极大降低了值班同学的心理负担也让真正需要干预的问题更容易浮出水面。4.2 动态基线用最近 7 天分布替代拍脑袋阈值静态阈值是降噪的头号敌人。凌晨批量任务和白天实时作业对同一指标的正常范围可能差一个数量级一个固定阈值要么误报要么漏报。我后来把所有 P1 级告警都改成了动态基线方案以最近 7 天同一时间段的指标分布为基准取 p95 值作为对照线当当前值超过基线三倍时触发告警。举例来说某个任务是每小时调度一次过去 7 天每天 14 点整的 pending 时间 p95 是 40 秒那么今天 14 点如果 pending 时间到了 240 秒就说明一定有异常在发生——可能是上游数据没就绪可能是 Executor 资源被抢占。动态基线把“凌晨高峰期不误报、白天低峰期不漏报”这个问题基本解决了。groups: - name: spark-realtime-monitor rules: - alert: SparkTaskPendingSurge expr: | (spark_task_pending_median_seconds / clamp_min(spark_task_pending_baseline_p95_seconds, 1)) 3 for: 10m labels: severity: P1 annotations: summary: Spark 作业 pending 时间超过基线 3 倍 description: 作业 {{ $labels.appName }} 当前 pending 时间 {{ $value }} 秒基线 p95 为 {{ $labels.baseline }} 秒4.3 降噪的三个关键开关计划内窗口、滚动重启、倾斜识别动态基线过滤掉了一大部分误报但还有三个高频噪音源需要单独处理。第一个是计划内维护窗口。集群扩容、缩容、版本升级时大量 Executor 会同时启动或退出触发“任务大面积重试”类 P0 告警。我们在发布和运维体系中增加了维护窗口标记在 Alertmanager 里对这些时段做静默避免运维操作和故障告警混在一起。第二个是滚动重启识别。判断逻辑是如果 Executor 注册速率在短时间内出现陡增同时作业状态是 RUNNING 而非 FAILED那大概率是平台在做滚动重启不是任务故障。我把这个判断做成了一条辅助规则自动对类似场景降级处理。第三个是数据倾斜识别。这类问题比较特殊特征是一个 Stage 里某个 task 的耗时是其他 task 的几十倍同时该 task 的 Shuffle Read 数据量异常大。倾斜不代表作业一定失败但它会拖慢整体进度而且经常在凌晨批量任务里出现。如果按常规 pending 超标逻辑告警会发现每夜都报人员容易疲劳。我把它单独拆成 P2 级警示每周汇总一次交给数据开发去优化 Key 的散列策略。5. 从一次 OOM 报警到参数优化落地完整复盘搭建完监控系统之后真正让我觉得这套体系“值回票价”的是一次线上 Executor OOM 的完整排查过程。整个过程基本就是把监控数据当作破案线索来用最后又反哺了参数优化和规则沉淀。5.1 报警触发后的第一个排查动作那天凌晨一点多P0 告警弹出显示某个核心作业的任务 pending 中位数在 5 分钟内从 40 秒飙升到 400 秒同时有一个 Executor 被标记为 Failed。如果是以前这种故障至少要拉齐三四个人现场翻日志才能定位。现在有了监控我做的第一件事是打开 Grafana 看板对比同一时间窗口下的三路数据。5.2 定位根因监控数据里早已有答案监控面板上的信息非常清晰。Driver 端的堆内内存和 GC 指标很平稳说明问题不在调度端。但被标记为 Failed 的那台 Executor它的堆外内存OffHeap和 Direct Memory 在崩溃前 15 分钟呈现出一条持续攀升的曲线已经冲到了接近 JVM 上限的位置。同时它的 Shuffle Read 字节数也在同步增长。顺着这两个信号回到作业日志定位到真正的元凶这个作业在启动时会从 Hive 表里collectAsMap出一张超过 1GB 的字典表再通过 broadcast 分发到所有 Executor结果 Executor 的内存瞬间被打满。这个问题在集群规模变大、字典表膨胀之后迟早会爆但此前完全属于盲区——如果监控没盯着 Direct Memory光看 CPU 和堆内内存根本发现不了异常。5.3 调优动作与应用效果根因清楚了优化方案也就明确了。第一把启动时一次性 collect 字典表的方案改成按分区维度做 lookup join避免大对象常驻 Executor 内存。第二把spark.memory.fraction从默认的 0.6 调整到 0.5给堆外内存和网络缓冲留出更充足的空间降低 Direct Memory 被挤爆的概率。第三开启 Shuffle 溢写压缩让磁盘溢出数据也进压缩通道减少内存与磁盘交换时对堆外内存的消耗。第四为动态资源分配设置 Executor 数量上限防止某个作业无限扩 Executor 挤压同集群其他作业。改造上线后这个作业的日均运行时长从 16 分钟降到 6 分钟OOM 导致的重试次数直接归零。而且因为监控数据可回溯我们还可以随时观察调优前后同一时段的内存曲线对比验证效果非常直观。5.4 把这次经验固化成监控规则和参数基线案例结束后我没有停在这一单故障上而是做了三件固化的事。第一新增了一条监控规则broadcast 任务注册的 RDD 大小如果超过默认 Executor 内存的 5%就自动触发一次 P2 预警提醒开发者考虑是否改用更轻量的分发方式。第二把本次验证过的参数组合整理成一套 Spark 配置基线进入发布评审流程避免同类作业下次上线继续沿用高风险参数。第三把“先看内存曲线再看 Shuffle 曲线最后看日志”写成了故障排查的标准顺序贴在值班手册里新同学照着这套顺序也能在几分钟内切入问题。这套监控系统上线运行一年多最大的收获并不是“那一堆闪烁的告警”而是所有参与 Spark 作业开发、调度、运维的人有了一种共同语言开发提需求时知道配多少资源是合理的调度排任务时能看到集群资源水位值班同学在收到 P0 时能直接通过看板判断方向而不是像以前那样赌运气。如果让我给准备做类似事情的人一句建议我会说先从一个你最常遇到的故障场景入手把对应的指标、采集、告警闭环建起来再逐步扩大覆盖面。一些细碎的小技巧也有用比如把 EventLog 的清理周期从三天改到七天比如每个季度定期复核一遍告警规则对应的人员是否还在岗这些都是日常看不到、却会影响关键时刻效率的细节。监控系统的价值不在面板漂亮而在它能让你在夜里两点收到告警时还能在五分钟内做出正确的第一个操作。
去年双十一前的某个深夜平台值班群突然炸了。离线数仓的 Spark 任务从晚上八点开始大面积失败等我们发现问题时数据看板已经断了快三个小时。最尴尬的是点开 Spark Web UI单个任务的执行情况都能看到页面上的红叉清清楚楚但整个集群几百个作业没有任何一个汇总视角能提前告诉我们“资源正在恶化、任务正在大面积重试”。那次之后我下定决心给这套 Spark 计算平台做一次真正意义上的实时监控体系升级。这篇文章不聊空泛的大数据平台架构概念只讲我在生产环境里从零搭建 Spark 实时监控系统的完整过程包括工具选型时的取舍、核心指标怎么定、实时采集链路怎么搭、告警规则怎么降噪以及靠这套监控抓到的真实问题。内容适合正在用 Spark 做离线或准实时计算、对作业稳定性有明确考核指标的团队参考也适合刚接触 Spark 运维、想搞清楚“监控到底该看哪些指标”的同学。整套方案踩过的坑我都会如实写出来能帮你少走不少弯路。1. 放弃 Web UI 和现成方案之前我遇到的三个现实问题很多人一听“Spark 监控”第一反应是“Spark 不是自带 Web UI 吗还需要自己搭”确实自带但真到了生产环境你会发现它离“能用”还有相当距离。我把自己在故障现场遇到的三类问题摆出来你大概就明白为什么要自建了。1.1 Spark Web UI 和历史服务在故障现场是缺位的Spark Web UI 的设计目标是“单作业视角”而不是“集群视角”。作业跑挂之后你确实能在页面上看到哪个 stage 失败、哪个 task 报错但这个页面只有作业粒度做不到横向对比。我有十几个流式任务同时在跑它们各自占了多少资源、哪个任务正处于 pending 状态、哪个 executor 的 Direct Memory 已经在濒临爆掉的边缘——Web UI 上是看不出来的。另一个问题是历史服务Spark History Server的数据生命周期有限。默认配置下EventLog 清理策略和 HDFS 目录容量会不断把旧日志删掉故障发生三天后再想去翻当时的完整现场经常发现事件文件已经被回收了。更要命的是如果 Driver 进程直接宕掉Web UI 页面也会一起消失而故障现场恰恰是监控数据最需要保留的时刻。1.2 开源监控方案与 Spark 作业生命周期错位我当时也调研过现成的开源组合Prometheus 加 JMX exporter、Ganglia、还有商业方案。最后得出的结论是它们都解决了一部分问题但都够不到 Spark 真正的故障点。举几个具体例子。JMX exporter 能抓到 JVM 层的内存和 GC 指标但这些指标反映的是“进程活着没有”没法回答“这个作业的 2000 个 task 为什么全部卡在 pending 状态”。Ganglia 的监控重心在操作系统层面——CPU、内存、磁盘 IO它对 Spark 内部的 Stage/Task/Shuffle 模型几乎没有感知。商业 APM 工具的 Spark 适配倒是做得深但成本高、配置重而且团队内部的网络策略不一定允许把作业元数据推到外部服务。1.3 我的结论三路数据源按用途分工而不是押注单一方案踩完一圈之后我定的设计原则是**不押注单一数据源而是让三路监控数据各司其职形成冗余。**第一路用自定义 SparkListener 采集作业生命周期和 Task 级指标这是主力数据源第二路通过解析 EventLog 做兜底保证 Driver 挂了监控链路也不断第三路用 JMX 抓 Executor 进程级内存和 GC补上 Spark 黑盒里的细节。三路数据统一落到 PrometheusGrafana 做可视化Alertmanager 负责告警。这套结构的好处是任何一条链路出问题另外两条还能撑住不会出现“监控系统先于任务挂掉”的讽刺局面。2. 指标体系真正值得监控的信号不超过 20 个监控系统最忌讳的不是指标太少而是指标太多。我见过有人一上来就把 Spark 的所有 Metrics 全量采集Grafana 上拉了几十个面板结果告警来了没人知道看哪里。我的原则很简单**指标必须能回答一个具体的运维决策问题。**如果一个指标上升了你不能确定下一步该干嘛那它就是噪音。2.1 先排除三个“看似有用实则骗人”的指标监控指标设计的第一步其实是做减法。有几个指标在纸面上很合理实际用了就知道容易被误导。第一个是“平均任务耗时”。一个 Stage 有 1000 个 task如果 999 个都在 5 秒内跑完1 个因为数据倾斜跑了 30 分钟平均值可能只到几十秒完全掩盖了长尾问题。这时候应该看 95 分位和 99 分位而不是平均值。第二个是“整体 CPU 使用率”。Spark 是分布式系统某个 Executor 所在节点 CPU 打到 95% 以上而集群整体 CPU 利用率只有 40%这种局部过热在平均值里根本看不出来但恰恰是任务执行不均的早期信号。第三个是“任务成功率”。在很多失败重试机制的保护下成功率长期维持在 99.9%但故障往往体现在同一批任务反复失败重试。相比成功率我更建议大家盯住“单位时间内的失败重试次数”和“任务从提交到真正开始执行的 pending 时间”这两个信号。2.2 长期保留的核心指标清单覆盖作业、Executor、系统三层经过一段时间打磨后我最终保留的指标其实就 20 个左右分成三层。第一层是作业生命周期层包括任务提交时间、启动时间、结束时间、状态、重试次数、pending 任务数和 running 任务数。这一层解决的是“作业本身是否健康”的问题。第二层是 Executor 层包括堆内内存使用峰值、堆外内存和 Direct Memory 使用量、GC 耗时与频率、Shuffle 读写字节数、Task 失败次数。这一层解决的是“作业为什么慢、为什么挂”的问题。第三层是系统资源层包括 Executor 所在节点的 CPU 使用率、磁盘 IO 等待时间、网络吞吐。这一层能帮我们识别集群级别的资源竞争。Mem这 20 个指标不需要全采全报关键在于每个指标都要有明确的观察窗口和阈值逻辑。比如 Direct Memory 使用量如果持续接近 JVM MaxDirectMemorySize 的 80%就应该进入预警而不是等到 OOM 之后才查。2.3 统计口径95 分位和 1 分钟窗口才是实时监控的及格线监控数据的统计口径比指标本身还重要。最开始我偷懒直接取了任务耗时的平均值结果告警要么不响一响就是大故障。后来统一改成百分位统计核心告警全部基于 95 分位OOM 类风险基于 99 分位。窗口大小也有讲究。5 分钟的窗口可以让曲线更平滑但对于实时监控来说太钝了。我最终采用 1 分钟窗口做聚合每 15 秒采集一次原始数据。这样既不会因为瞬时毛刺打爆告警又能保证在故障发生 3 到 5 分钟内被捕捉到。另一个关键经验是**告警规则要盯变化量而不是绝对值。**比如 pending 时间从 30 秒涨到 240 秒比“pending 时间为 240 秒”本身更有意义前者反映的是劣化趋势后者在凌晨批量任务高峰时可能很正常。3. 实时采集链路实现SparkListener、EventLog 与 JMX 三路并行采集层是整个监控系统的心脏。我踩过的坎基本都集中在这一层所以会讲得细一点。3.1 用自定义 SparkListener 拿作业内部的第一手状态Spark 内部自带了一套事件监听机制通过继承 SparkListener 可以拿到 application、stage、task 三个粒度的完整生命周期。这是最贴近故障现场的一路数据源。我在 onTaskEnd 回调里提取每个 task 的执行耗时、GC 时间、Shuffle 读写字节数、内存溢出量等指标在 onStageCompleted 回调里做一次统一聚合然后批量上报。这里特别提醒一个坑不要在 onTaskEnd 里做高延迟的网络 IO。一个作业有几千上万个 task如果每个 task 结束都走一次 HTTP 请求上报采集本身就会拖慢作业执行甚至把 Driver 的资源抢走。我最初就是在这里翻车的后来改成在 stage 完成时统一聚合成一个指标点再批量推给 Prometheus单次上报耗时从秒级降到了几十毫秒。class MetricsSparkListener(reporter: MetricsReporter) extends SparkListener { override def onTaskEnd(taskEnd: SparkListenerTaskEnd): Unit { val metrics taskEnd.taskMetrics // 把单 task 维度的关键指标缓存到本地缓冲区 pendingTaskSnapshot.add( TaskMetricSnapshot( stageId taskEnd.stageId, executorRunTime metrics.executorRunTime, executorDeserializeTime metrics.executorDeserializeTime, jvmGCTime metrics.jvmGCTime, memoryBytesSpilled metrics.memoryBytesSpilled, diskBytesSpilled metrics.diskBytesSpilled, shuffleReadBytes metrics.shuffleReadMetrics.totalBytesRead, shuffleWriteBytes metrics.shuffleWriteMetrics.bytesWritten ) ) } override def onStageCompleted(stageCompleted: SparkListenerStageCompleted): Unit { // stage 结束时聚合成一条指标用批量方式上报避免高频 IO reporter.reportStageSnapshot(buildStageSnapshot(stageCompleted.stageInfo)) } }3.2 EventLog 解析兜底不依赖 Driver 存活的第二条链路自定义 Listener 的致命弱点是跑在 Driver 进程里Driver 一挂这条链路就断了。为了不让“监控系统先于任务挂掉”我搭了第二条链路解析 Spark EventLog。具体做法是开启spark.eventLog.enabledtrue让 Spark 把执行过程写成 JSON 格式的事件日志然后在监控侧写一个消费程序去监听日志目录把 StageCompleted、TaskEnd 等关键事件解析出来推到 Prometheus。因为 EventLog 是落盘文件即使 Driver 崩溃、History Server 还在读旧数据我们也能从日志文件里恢复现场。关于 EventLog 的副作用实测下来性能损耗可接受。开启后每个作业的额外开销大约在千分级别相比故障排查时能节省的工时这点成本非常划算。唯一的注意点是要给 EventLog 单独规划存储目录和清理策略避免日志文件无限制增长占满 HDFS也别让它被清理策略误伤得太急。3.3 Executor 进程级指标拆掉黑盒才能看内存全景作业层面有 Listener 和 EventLog 之后还有一块经常被忽略的盲区Executor 的 JVM 内部状态。Shuffle 数据在内存和磁盘之间流动时到底占了多少内存Direct Memory 是不是快爆了GC 老年代是不是在持续增长这些信息只有 JMX 能给我们。我在每个 Executor 启动时额外开启了 JMX 端口配合 jmx_exporter 把堆内堆外内存、GC 次数和耗时、Direct Buffer 使用量等指标暴露出来。这里有一个非常典型的采坑点YARN 容器动态分配时 Executor 频繁启停固定 JMX 端口很容易冲突。我们后来改为动态端口分配并加入端口探测机制才彻底解决。3.4 采集链路常见坑序列化、丢数据、端口冲突再集中整理几个容易踩的坑。第一回调代码必须包一层 try-catch否则 Listener 里一旦抛异常会影响 Spark 本身的调度流程我自己就遇到过回调里一个空指针导致 task 结束事件处理失败整个 stage 卡住的情况。第二上报要批量化和异步化千万不要为了“实时”而用低效的同步上报。第三Prometheus 本身也可能挂所以采集侧要有本地缓冲我最后是用本地文件加定时重推的方式做了兜底确保 Prometheus 宕机期间数据不丢恢复后可以补传。4. 告警规则与降噪从每天五十条到每周两三条监控的价值最终要通过告警体现。第一版告警规则上线那天我印象特别深刻——一天五十多条告警值班同学被轰炸到直接静音等于所有告警都失效了。降噪做得不好监控系统还不如不搭。第二版我把重点放在了两件事告警分级和动态基线。4.1 告警分三级P0 故障、P1 劣化、P2 浪费我把告警分成三个层级对应不同的响应要求。P0 层是作业中断类事件比如大面积 task 失败、作业反复重试、异常退出这类问题直接导致数据产出延迟需要立刻通知值班走电话或者强提醒。P1 层是性能劣化类信号比如 pending 任务数持续上升超过三倍基线、Executor 堆外内存接近阈值、GC 老年代快速增长这类信号意味着作业正在走向失败但还有处理窗口进 on-call 看板即可。P2 层是资源浪费类观察项比如某作业长期占用资源但任务并发度极低、某个大 broadcast 占用了高比例 Executor 内存这类问题不紧急但值得沉淀到周报里推动优化。三层告警的响应时间要求完全不同这个区分极大降低了值班同学的心理负担也让真正需要干预的问题更容易浮出水面。4.2 动态基线用最近 7 天分布替代拍脑袋阈值静态阈值是降噪的头号敌人。凌晨批量任务和白天实时作业对同一指标的正常范围可能差一个数量级一个固定阈值要么误报要么漏报。我后来把所有 P1 级告警都改成了动态基线方案以最近 7 天同一时间段的指标分布为基准取 p95 值作为对照线当当前值超过基线三倍时触发告警。举例来说某个任务是每小时调度一次过去 7 天每天 14 点整的 pending 时间 p95 是 40 秒那么今天 14 点如果 pending 时间到了 240 秒就说明一定有异常在发生——可能是上游数据没就绪可能是 Executor 资源被抢占。动态基线把“凌晨高峰期不误报、白天低峰期不漏报”这个问题基本解决了。groups: - name: spark-realtime-monitor rules: - alert: SparkTaskPendingSurge expr: | (spark_task_pending_median_seconds / clamp_min(spark_task_pending_baseline_p95_seconds, 1)) 3 for: 10m labels: severity: P1 annotations: summary: Spark 作业 pending 时间超过基线 3 倍 description: 作业 {{ $labels.appName }} 当前 pending 时间 {{ $value }} 秒基线 p95 为 {{ $labels.baseline }} 秒4.3 降噪的三个关键开关计划内窗口、滚动重启、倾斜识别动态基线过滤掉了一大部分误报但还有三个高频噪音源需要单独处理。第一个是计划内维护窗口。集群扩容、缩容、版本升级时大量 Executor 会同时启动或退出触发“任务大面积重试”类 P0 告警。我们在发布和运维体系中增加了维护窗口标记在 Alertmanager 里对这些时段做静默避免运维操作和故障告警混在一起。第二个是滚动重启识别。判断逻辑是如果 Executor 注册速率在短时间内出现陡增同时作业状态是 RUNNING 而非 FAILED那大概率是平台在做滚动重启不是任务故障。我把这个判断做成了一条辅助规则自动对类似场景降级处理。第三个是数据倾斜识别。这类问题比较特殊特征是一个 Stage 里某个 task 的耗时是其他 task 的几十倍同时该 task 的 Shuffle Read 数据量异常大。倾斜不代表作业一定失败但它会拖慢整体进度而且经常在凌晨批量任务里出现。如果按常规 pending 超标逻辑告警会发现每夜都报人员容易疲劳。我把它单独拆成 P2 级警示每周汇总一次交给数据开发去优化 Key 的散列策略。5. 从一次 OOM 报警到参数优化落地完整复盘搭建完监控系统之后真正让我觉得这套体系“值回票价”的是一次线上 Executor OOM 的完整排查过程。整个过程基本就是把监控数据当作破案线索来用最后又反哺了参数优化和规则沉淀。5.1 报警触发后的第一个排查动作那天凌晨一点多P0 告警弹出显示某个核心作业的任务 pending 中位数在 5 分钟内从 40 秒飙升到 400 秒同时有一个 Executor 被标记为 Failed。如果是以前这种故障至少要拉齐三四个人现场翻日志才能定位。现在有了监控我做的第一件事是打开 Grafana 看板对比同一时间窗口下的三路数据。5.2 定位根因监控数据里早已有答案监控面板上的信息非常清晰。Driver 端的堆内内存和 GC 指标很平稳说明问题不在调度端。但被标记为 Failed 的那台 Executor它的堆外内存OffHeap和 Direct Memory 在崩溃前 15 分钟呈现出一条持续攀升的曲线已经冲到了接近 JVM 上限的位置。同时它的 Shuffle Read 字节数也在同步增长。顺着这两个信号回到作业日志定位到真正的元凶这个作业在启动时会从 Hive 表里collectAsMap出一张超过 1GB 的字典表再通过 broadcast 分发到所有 Executor结果 Executor 的内存瞬间被打满。这个问题在集群规模变大、字典表膨胀之后迟早会爆但此前完全属于盲区——如果监控没盯着 Direct Memory光看 CPU 和堆内内存根本发现不了异常。5.3 调优动作与应用效果根因清楚了优化方案也就明确了。第一把启动时一次性 collect 字典表的方案改成按分区维度做 lookup join避免大对象常驻 Executor 内存。第二把spark.memory.fraction从默认的 0.6 调整到 0.5给堆外内存和网络缓冲留出更充足的空间降低 Direct Memory 被挤爆的概率。第三开启 Shuffle 溢写压缩让磁盘溢出数据也进压缩通道减少内存与磁盘交换时对堆外内存的消耗。第四为动态资源分配设置 Executor 数量上限防止某个作业无限扩 Executor 挤压同集群其他作业。改造上线后这个作业的日均运行时长从 16 分钟降到 6 分钟OOM 导致的重试次数直接归零。而且因为监控数据可回溯我们还可以随时观察调优前后同一时段的内存曲线对比验证效果非常直观。5.4 把这次经验固化成监控规则和参数基线案例结束后我没有停在这一单故障上而是做了三件固化的事。第一新增了一条监控规则broadcast 任务注册的 RDD 大小如果超过默认 Executor 内存的 5%就自动触发一次 P2 预警提醒开发者考虑是否改用更轻量的分发方式。第二把本次验证过的参数组合整理成一套 Spark 配置基线进入发布评审流程避免同类作业下次上线继续沿用高风险参数。第三把“先看内存曲线再看 Shuffle 曲线最后看日志”写成了故障排查的标准顺序贴在值班手册里新同学照着这套顺序也能在几分钟内切入问题。这套监控系统上线运行一年多最大的收获并不是“那一堆闪烁的告警”而是所有参与 Spark 作业开发、调度、运维的人有了一种共同语言开发提需求时知道配多少资源是合理的调度排任务时能看到集群资源水位值班同学在收到 P0 时能直接通过看板判断方向而不是像以前那样赌运气。如果让我给准备做类似事情的人一句建议我会说先从一个你最常遇到的故障场景入手把对应的指标、采集、告警闭环建起来再逐步扩大覆盖面。一些细碎的小技巧也有用比如把 EventLog 的清理周期从三天改到七天比如每个季度定期复核一遍告警规则对应的人员是否还在岗这些都是日常看不到、却会影响关键时刻效率的细节。监控系统的价值不在面板漂亮而在它能让你在夜里两点收到告警时还能在五分钟内做出正确的第一个操作。
