如何查看 YARN 报错 job？-HCRM博客

查看 Yarn Job 报错：实用排查指南

遇到提交到 Yarn 上的作业突然失败，屏幕上跳出刺眼的报错信息，确实让人头疼，别慌，这份手把手指南将带你系统性地定位和解决 Yarn Job 报错问题,让你从茫然无措到胸有成竹。

基础排查：定位源头信息

直击核心：YARN Application Logs 报错发生时，首要任务是获取应用程序日志，使用以下命令，替换 application_XXXX_YYYY 为你的实际 Application ID：
```
yarn logs -applicationId application_XXXX_YYYY > application_logs.txt



```
这个命令将完整日志（包含 AM Container 和所有 Task Attempt 日志）输出到文件，仔细查看文件末尾或搜索 ERROR、Exception、Failed 等关键词，通常能快速锁定失败根源，重点关注 Application Master (AM) 容器的日志,它掌控着作业的生命周期。
掌握全局：YARN Application 状态 使用 yarn application -status 命令获取作业的详细摘要信息：
```
yarn application -status application_XXXX_YYYY



```
输出包含最终状态 (Final-State)、诊断信息 (Diagnostics)、尝试次数 (Attempts)、使用的队列 (Queue) 等。Diagnostics 字段尤其关键，YARN 或框架（如 MapReduce, Spark）常在此提供简明扼要的失败原因，例如资源不足、节点故障或特定异常。

深度诊断：剖析关键日志

聚焦失败 Container 如果基础日志不够清晰，需深入失败的特定 Container（如 Map Task, Reduce Task, Spark Executor），在 yarn logs 输出的完整日志中，查找失败 Task Attempt 的 Container ID（格式如 container_XXXX_YYYY_ZZ_CCCCCC）。直接获取该 Container 的详细日志：
```
yarn logs -applicationId application_XXXX_YYYY -containerId container_XXXX_YYYY_ZZ_CCCCCC > container_logs.txt



```
分析此日志中的 stderr 和 syslog 内容，通常包含 Java 异常堆栈跟踪或框架特有的错误消息,这是定位代码或环境问题的关键。
资源视角：YARN ResourceManager Web UI 浏览器访问 ResourceManager 的 Web UI（默认 http://<rm-address>:8088），找到失败的 Application，点击其 ID。
- Application 详情页：查看 Diagnostics、Logs 链接（直接查看或下载日志）、ApplicationMaster 链接（跳转到 AM 运行节点的 NodeManager UI）。
- Attempts 信息：查看失败的 Task Attempts，点击其 Logs 链接直达对应 Container 日志。
- 资源使用：关注 Resources 部分，检查申请的内存 (Memory)、虚拟核数 (VCores) 是否合理，是否存在因资源不足 (AM Container 或 Task Container 因资源问题被 Kill) 导致的失败。

高级技巧：精准锁定问题

日志过滤与分析 面对海量日志，善用 grep, awk, sed 或 less 的搜索功能：
- grep -i 'error\\|exception\\|fail' application_logs.txt：快速提取关键错误行。
- grep 'Container exited with a non-zero exit code' application_logs.txt：查找因容器非正常退出导致的失败。
- 分析堆栈跟踪：重点关注 Caused by: 后的根本原因和异常类型 (OutOfMemoryError, IOException, ClassNotFoundException 等)。
历史对比与模式识别 若作业时好时坏，对比成功与失败的作业日志,关注差异点：
- 资源申请量是否变化？
- 输入数据路径或大小是否异常？
- 是否有特定节点 (NodeManager Hostname) 频繁失败？可能该节点存在硬件或环境问题。
- 失败是否发生在特定时间点？可能与集群负载高峰或外部依赖服务波动有关。
理解常见报错类型
- 资源不足 (Exit code: 143): 最常见原因，通常是 Container 内存 (OOM) 或 CPU 超限，需增大 mapreduce.map.memory.mb, mapreduce.reduce.memory.mb (MR) 或 spark.executor.memory, spark.executor.cores (Spark) 等参数,或优化代码减少资源消耗。
- 类路径问题 (ClassNotFoundException, NoClassDefFoundError): 依赖包缺失或冲突，检查 HADOOP_CLASSPATH、-libjars (MR)、--jars (Spark) 或 jar 包内容是否完整正确。
- 数据问题 (IOException, 文件不存在/权限拒绝): 检查输入/输出路径是否存在、权限是否正确、文件是否损坏。
- 网络/节点故障 (Connection refused, Node lost): 临时性网络波动或节点宕机，YARN 会自动重试,但频繁发生需检查集群健康状况。
- 用户代码错误 (NullPointerException, 逻辑错误): 需审查业务逻辑代码，Container 日志中的堆栈跟踪会指向具体代码行。

专家建议：预防胜于补救

合理资源配置：基于数据量和复杂度，在提交作业时设置足够但不过量的内存和 CPU,监控历史作业资源使用情况作为参考。
日志级别调优：在开发调试阶段，适当提高框架日志级别 (如 Hadoop 的 mapreduce.map.log.level, Spark 的 spark.logConf=true),便于发现问题。
依赖管理严谨：确保所有依赖库正确打包或分发到集群节点,避免版本冲突。
参数优化：熟悉所用框架（MapReduce/Spark/Flink）的参数，根据作业特点调整（如压缩、并行度、序列化方式）。
集群监控：密切关注集群整体资源利用率、NodeManager 健康状态、HDFS 健康状况，Zabbix、Prometheus+Grafana 等工具是运维好帮手。

处理 Yarn Job 报错的关键在于耐心和系统性，熟练运用日志查看命令、善用 Web UI、理解常见错误模式，并遵循从整体状态到具体 Container 日志的诊断流程，绝大多数问题都能迎刃而解，每次成功排错积累的经验，都是提升大数据平台运维能力的基石，面对报错保持冷静，逐层剖析,你终将成为解决问题的专家。