spark作业日志定位过程
客户端界面或其它位置处已发送spark作业
1、打开yarn网页端，查看正在运行中的作业，点击ApplicationMaster（如果作业运行完成红框这里显示为"history"）
2、点击后，跳转到 Spark History Server 的界面，如下所示的界面
该页面中Jobs、Stages、Executors关系通过AI得到以下结果：
3、作业失败定位顺序
先查failed状态的job、再查failed状态的stages、点击stages可以看到failed状态的task，如果Task的Errors字段非空，则表明该 Task 出现错误，进一步查看stdout和stderr的内容。
如果task也没失败的，那大概率就是executors页面中的driver报错，查看stdout和stderr的内容。
以上为正常情况下的失败作业原因排查
打不开history的情况
但是有时候history是切换不过去的，如下图所示，将8088端口改为18080，然后搜索applicationID。
如果都找不到，那就在客户端节点上通过命令行工具yarn logs -applicationId application_xxx_xxx>xxx.log下载。
先看Driver： 000001 的 Container 的 stdout 和 stderr 日志；
再看Executor：其它编号的 Container 的 stdout 和 stderr 日志。类似这种无法到history页面的作业问题定位，可能是spark作业运行前，yarn检测到达不到运行条件，直接抛出错误，上图问题后来定位是挂载盘丢失导致文件找不到。
spark作业其它常见错误
场景一：
134退出码大概是进程自身崩溃，因为内存超出等原因。
在 Spark on YARN 里，常见错误码原因：
| 退出码 | 信号 | 含义 | 常见原因 | 排查方向 |
|---|---|---|---|---|
| 134 | SIGABRT(6) | 进程异常终止 | JVM 崩溃、native 库问题、glibc 报错、断言失败 | hs_err_pid*.log、Executor stderr、系统日志 |
| 137 | SIGKILL(9) | 被强制杀死 | 内存超限、YARN 容器 OOM、系统 OOM Killer、kill -9 |
YARN 内存配置、dmesg、NodeManager 日志 |
| 139 | SIGSEGV(11) | 段错误 | native 代码崩溃、JVM 崩溃、非法内存访问 | hs_err_pid*.log、core dump、Executor stderr |
场景二：
作业提交后，一直是ACCEPTED状态，无法切换为running状态。
这种问题得分情况，如果spark-submit时未指定spark.yarn.am.nodeStrictLocality，YARN 会在任意满足资源要求的节点上启动 AM，不会强制去某个节点。这时候出现一直ACCEPTED，要查队列和集群整体资源情况，比如资源不足，或达到队列最大应用数/资源上限等原因。
但若指定了spark.yarn.am.nodeStrictLocality参数，可以从spark提交服务日志中查到它的目标计算节点是哪个，这样就锁定了范围，直接排查这个节点状态和资源情况，是否下线等，下线了去查nodemanager日志（$HADOOP_HOME/logs/xxxx.log）。我工作中遇到的情况就是刚提交作业，碰巧节点出现问题下线，然后就会一直accepted。