Spark 核心之 Spark-WebUI 详解及日志查看

简介: 本文详解 Spark Web UI(4040端口)与 History Server(18080端口)的监控调优体系,涵盖 Jobs/Stages/Storage/Executors 等7大核心Tab指标解读、EventLog重放机制、log4j日志配置及YARN/K8s日志查看,并附架构图与命令速查表,助你高效排障与性能优化。(239字)

摘要:Spark Web UI 是监控、调试和性能调优的核心入口。本文从架构全景出发,逐一详解 7 大核心 Tab(Jobs/Stages/Storage/Executors/Environment/SQL/Streaming)的使用方法和指标含义,深入 History Server 的 EventLog 重放机制、log4j 日志体系配置、YARN/K8s 容器日志查看,配合 2 张架构图 + 超实用命令速查表,助你成为 Spark 排错高手。

关键词:Spark WebUI, History Server, EventLog, log4j, Jobs/Stages/Executors Tab, yarn logs, Spark 监控, 性能调优


一、开篇:4040 端口背后的秘密

每个 Spark 应用启动后,都会在日志中看到:

SparkUI: Bound SparkUI to 0.0.0.0, and started at http://host:4040

这行信息背后是一个完整的监控体系:

Spark Web UI 体系
├── 运行时 Web UI:     http://driver-host:4040          (应用存活时)
├── History Server:    http://history-host:18080        (跨应用历史)
├── REST API:          http://host:4040/api/v1/...       (JSON 接口)
├── EventLog:          spark.eventLog.dir (HDFS/S3/本地) (持久化)
└── MetricsSystem:     JVM / Executor Metrics             (指标收集)

核心配置

# spark-defaults.conf — Web UI 核心参数
spark.ui.port=4040
spark.ui.retainedJobs=1000         # 保留 Job 数量
spark.ui.retainedStages=1000       # 保留 Stage 数量
spark.ui.retainedTasks=100000      # 保留 Task 数量
spark.ui.timeline.tasks.maximum=1000
spark.sql.ui.retainedExecutions=1000
spark.ui.reverseProxy=true         # 反向代理支持

二、WebUI 架构全景

在这里插入图片描述

图 1:Spark WebUI 监控与调试全景架构 — 4040 UI + 7 Tab + 18080 History Server

三、7 大核心 Tab 逐个详解

3.1 ① Jobs Tab — 全局 Job 视图

每个 Spark Action 触发一个 Job。Jobs Tab 列出所有 Job 的状态、Duration、Stage 数量和 Event Timeline 时间轴。

Jobs Tab 关键指标
├── Duration:   Job 总耗时(含调度等待)
├── Stages:     成功 / 失败 / 跳过(因结果已缓存)
├── Tasks:      总数(所有 Stage 的 Task 数之和)
└── Event Timeline:  Executor 加入/移除、Job 起止时间轴

3.2 ② Stages Tab — DAG 分段监控 🔍

点击任一 Stage 进入详情页,可以看到该 Stage 下所有 Task 的执行明细:

Stage Detail — 调优重点区域
├── Summary Metrics: Duration / Input Size / Shuffle Read/Write
├── Aggregated Metrics by Executor:          (每个 Executor 的聚合)
├── Tasks 列表: Duration / GC Time / Shuffle Read Write
├── DAG Visualization:                        Stage DAG 图
└── Event Timeline:                           Task 执行时间轴【检测数据倾斜!】

数据倾斜检测:如果 Max Duration >> Median,说明存在数据倾斜。

3.3 ③ Storage Tab — RDD 缓存状态

显示所有被 cache() 或 persist() 的 RDD/DataFrame 的缓存状态:

Storage Tab 关注点
├── Cache 命中率 < 100%  →  数据量 > 总缓存空间
├── Size on Disk > 0    →  内存不足,已溢写磁盘
└── Fraction Cached < 1 →  部分 Partition 未被缓存

3.4 ④ Executors Tab — 资源与性能 ⚡

最重要的性能诊断 Tab,展示每个 Executor 的:

Executors Tab — 关键指标
├── RDD Blocks:         内存中缓存的数据块数
├── Storage Memory:      已用 / 总存储内存
├── Task Time:           GC Time + Non-GC Task Time
├── Shuffle Read/Write:  跨Executor 数据传输量
├── Input / Output:      从外部源读取/写入量
├── Thread Dump:         Executor JVM 线程快照
└── stdout / stderr:     Executor 级日志直接查看

3.5 ⑤ Environment Tab — 运行环境

全量展示 Spark / Hadoop / JVM 配置。排查"为什么 spark.sql.shuffle.partitions 没生效"时来这里确认实际生效值。同时显示 Classpath Entries 和 System Properties。

3.6 ⑥ SQL Tab — DataFrame/SQL 执行计划

SQL Tab — 每个 Query 的详细信息
├── Logical Plan:        逻辑执行计划
├── Physical Plan:       物理执行计划
├── WholeStageCodegen:   是否走全阶段代码生成
├── Exchange (Shuffle):  数据量 + Partition 数
├── Scan:                读取行数 + 数据量
└── Duration 分解:       每个算子耗时占比

四、EventLog 与 History Server

在这里插入图片描述

图 2:Spark EventLog + log4j 日志体系 — 从事件产生到 History Server 重放

4.1 EventLog 配置

# spark-defaults.conf — EventLog 必备配置
spark.eventLog.enabled=true
spark.eventLog.dir=hdfs://namenode:8020/spark-history
spark.eventLog.compress=true          # 压缩节省 60-80% 空间
spark.eventLog.rolling.enabled=true   # 大日志文件滚动
spark.eventLog.rolling.maxFileSize=128m

# History Server 配置
spark.history.fs.logDirectory=hdfs://namenode:8020/spark-history
spark.history.ui.port=18080
spark.history.fs.cleaner.enabled=true
spark.history.fs.cleaner.maxAge=7d    # 只保留 7 天

4.2 启动 History Server

# 方式一:独立启动
$SPARK_HOME/sbin/start-history-server.sh

# 方式二:指定配置文件和目录
$SPARK_HOME/sbin/start-history-server.sh \
  --properties-file /etc/spark/conf/history.properties \
  hdfs://namenode:8020/spark-history

4.3 REST API 直接查询

# 查询应用列表
curl http://history-host:18080/api/v1/applications

# 查询具体应用 Job 列表
curl http://history-host:18080/api/v1/applications/{
   appId}/jobs

# 查询 Stage 详情
curl http://history-host:18080/api/v1/applications/{
   appId}/stages/{
   stageId}

五、log4j 日志体系

5.1 日志级别动态调整

// ① 代码中动态调整(仅 Driver 端)
spark.sparkContext.setLogLevel("DEBUG")
// 可选: ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF
# ② spark-submit 传入(Driver + Executor)
--conf "spark.driver.extraJavaOptions=-Dlog4j.configuration=file:log4j.properties"
--conf "spark.executor.extraJavaOptions=-Dlog4j.configuration=file:log4j.properties"

5.2 log4j2.properties 模板(Spark 3.x)

# $SPARK_HOME/conf/log4j2.properties
rootLogger.level=WARN
rootLogger.appenderRef.stdout.ref=console

# 关键包日志调整
logger.spark.name=org.apache.spark
logger.spark.level=INFO

logger.scheduler.name=org.apache.spark.scheduler
logger.scheduler.level=DEBUG          # 查看 Task 调度细节

logger.hadoop.name=org.apache.hadoop
logger.hadoop.level=WARN              # Hadoop 太吵了

5.3 YARN / K8s 日志查看

# === YARN ===
yarn logs -applicationId application_1234567890_0001
yarn logs -applicationId app_xxx -containerId container_xxx
yarn logs -applicationId app_xxx -logFiles stdout

# === Kubernetes ===
kubectl logs <driver-pod> -c spark-kubernetes-driver
kubectl logs <executor-pod> -c executor
kubectl exec <driver-pod> -- ls /var/log/spark/

六、实战排查三场景

场景一:Task 数据倾斜检测

诊断路径:
  Stage Detail → Tasks Duration (Max vs Median)
  Max Duration >> Median → 数据倾斜!
  → 查看 Shuffle Read Size 分布
  → 方案: 加盐 / 两阶段聚合 / Broadcast Join

场景二:GC 时间过高

诊断路径:
  Executors Tab → GC Time 列
  GC Time > Task Time 的 10% → GC 压力过大
  → 增大 executor memory 或堆外内存
  → 调整 GC 策略(G1GC / ParallelGC)
  → 启用 GC 日志: -verbose:gc -XX:+PrintGCDetails

场景三:Shuffle 数据量异常

诊断路径:
  SQL Tab → Exchange → 检查数据量和 Partition 数
  Shuffle Write >> 合理范围 → 检查是否有不必要的 Shuffle
  → 检查 spark.sql.shuffle.partitions 是否过小
  → 使用 Broadcast Hint 避免 Shuffle

七、总结

  1. 运行时 Web UI (4040):Jobs → Stages → Tasks 自上而下定位瓶颈;Executors Tab 查看资源与 GC;SQL Tab 检查物理计划算子耗时。

  2. History Server (18080):通过 EventLog 重放已结束应用,支持跨应用对比。必备配置 spark.eventLog.enabled=true。

  3. 日志体系:log4j 分级控制 + sc.setLogLevel() 动态调整 + yarn logs / kubectl logs 查看容器日志。

  4. 三大实战场景:Task 倾斜(Duration Max vs Median)、GC 压力(GC Time > 10%)、Shuffle 异常(Exchange 数据量分析)。


作者:starzy
博客:blog.starzy.cn
GitHub:starzy1990.github.io
专注 AI Agent · LangGraph · RAG · 大数据架构 · 数据工程实践

目录
相关文章
|
5天前
|
云安全 人工智能 运维
当攻击全面Agent化,你的安全防御能否跟上AI Speed?
多起客户侧AK泄露事件应急的真实观察
1242 4
|
28天前
|
人工智能 JSON API
全网刷屏的 Jev 模型正式开放!一手实战测评 + 保姆级教程
全网爆火的 Jev 模型是什么?有什么用?怎么使用?怎么接入 AI 编程工具?效果真的好么?傻子可懂的 Jev 保姆级实战教程 + 项目实战测评来啦
9791 32
|
8天前
|
存储 人工智能 安全
千问办公官网入口网页版登录:qwenwork.cn 注册送2000积分、登录送100积分
阿里云千问办公(QwenWork)是AI智能工作平台,支持一句话生成PPT、表格、网页、视频及数据分析。个人免费版送2000积分+每日登录赠100分,含1GB存储、5个发布页;企业版198元/席/月起。阿里千问办公QwenWork官网:https://t.aliyun.com/U/0VCTGt 阿里AI工作平台,一句话完成数据分析、PPT 生成、视频剪辑、网页搭建等复杂任务
|
3天前
|
人工智能 API 开发工具
DeepSeek Harness 神插件:白嫖 13 家大厂模型
`dsh-our-free-model` 是 DeepSeek Harness 神级插件:零配置、零API Key、零账号,聚合13家大厂免费模型(含DeepSeek V4.1 Flash、Kimi K3等),支持本地网关、用量看板与自动降级,真正实现“白嫖即用”。
|
14天前
|
存储 人工智能 并行计算
大模型本地部署终端选型方法论:以 Qwen3.8-27B 为例的四档分层完整流程
本文提出一套大模型本地部署终端选型方法论:定约束、定档位、定框架、定参数四步决策法,配合入门、主力、质量、无损四档分层模型。以 Qwen3.8-27B 实测数据为例,逐环节解读显存、带宽、存储、散热、系统、预算等要素,给出面向不同预算的优选方案、决策自查清单与市场观察框架。文末前瞻 AI 笔记本的 CPU+GPU 与统一内存两条路线,论证四步决策法在新品类上的延续性。
|
5天前
|
Web App开发 人工智能 JavaScript
太猛了,一个月干到15W+,给大家推荐一个最近爆火的开源逆向工具:REA
REA(Reverse Engineer Anything)是近期爆火的开源AI逆向工具,4月发布,1个月内斩获15万+ Star。它让AI Agent无需源码即可分析二进制、APK、JS/Electron、HAR包等17类目标,自动反编译、生成可运行代码,并强制返回带证据与局限的结论。全本地执行,MIT协议,支持Hopper/Ghidra/IDA等引擎,一行命令即可上手。
628 1
太猛了,一个月干到15W+,给大家推荐一个最近爆火的开源逆向工具:REA
|
13天前
|
人工智能 JSON 自然语言处理
2026 年 Jev 决策模型深度拆解:原理解读、实战测评与保姆级落地教程
有一款特殊AI模型在开发者圈子刷屏,它摒弃传统大模型擅长的对话聊天能力,专注做高速结构化决策,它就是TypeSafe AI推出的Jev模型。该模型由ChatGPT共同发明人Diogo Almeida主导研发,定位为**System One Model(系统一模型)**,对标人类大脑快速直觉判断的思维模式,在响应延迟、调用成本、结构化输出稳定性上相比传统生成式大模型有着巨大差异。本文会完整拆解Jev底层原理、三大核心原语能力、适用业务场景,同时提供可直接运行的curl、Python代码示例,并且结合多组实测数据,客观分析模型优势与能力边界,帮助普通开发者和AI应用从业者快速上手落地。
933 1
|
9天前
|
人工智能 JSON 自然语言处理
2026 年 Jev 决策模型全解析:核心原理拆解,性能实战测评与落地部署教程
有一款特殊AI模型在开发者圈子刷屏,它摒弃传统大模型擅长的对话聊天能力,专注做高速结构化决策,它就是TypeSafe AI推出的Jev模型。该模型由ChatGPT共同发明人Diogo Almeida主导研发,定位为System One Model(系统一模型),对标人类大脑快速直觉判断的思维模式,在响应延迟、调用成本、结构化输出稳定性上相比传统生成式大模型有着巨大差异。本文会完整拆解Jev底层原理、三大核心原语能力、适用业务场景,同时提供可直接运行的curl、Python代码示例,并且结合多组实测数据,客观分析模型优势与能力边界,帮助普通开发者和AI应用从业者快速上手落地。
593 0