本文转自 http://ixiaosi.art/2019/01/23/spark/spark%E4%BB%BB%E5%8A%A1%E7%9B%91%E6%8E%A7/
Spark 作为计算引擎每天承载了大量的计算任务，为了监控集群的资源使用情况，对 Spark 的监控也在所难免，本文讲述如何获取已经执行完的 Spark 任务信息。
概述
Spark 提供了 3 个原生监控任务的入口，REST，EventLog，Metrics。另外我们也可以通过自己埋点的方式做一些定制化采集。
REST
Spark 提供了一个 history server 服务，也就是 UI，也可以通过 REST 接口去获取 JSON 格式的数据。但是这有个前提，必须打开日志功能，否则只能在某个 Spark 任务活着的时候通过 driver 端的临时 UI 查看到数据，打开配置 spark.eventLog.enable，Spark 可以将 event log 写到 HDFS 上的路径 spark.eventLog.dir，然后 history server 再通过配置 spark.history.fs.logDirectory 的路径读取到历史任务的执行信息。这里对 Spark 的 event 机制稍微解释一下，Spark 把每一个重要的动作封装成事件，比如任务启动完成，job 启动完成，task 启动完成等，收集的信息和 MapReduce 收集的内容差不多，主要是 JVM，资源，shuffle，IO 这四个方面，然后把这些事件通过总线的方式广播给所有监听事件的人。当开启了 spark.eventLog.enable 配置后，Spark 通过注册 EventLoggingListener 来获取所有的事件，再写到 HDFS 上。需要注意的是，由于 Spark 任务可大可小，有些任务 task 数量有好几千，那么生成的文件也会很大，压缩后一个文件几百 MB 是正常的。再扯的远一点，Spark 的 history server 还提供了删除过期日志等操作，例如配置 spark.history.fs.cleaner.enable，有兴趣可以看类 FsHistoryProvider。
REST 提供的接口也很全，完整的接口文档参考 Spark 官方链接
EventLog
上面在 REST 入口里提到了 Spark 的 event 机制，那么就很容易联系到除了通过 REST 接口，还可以直接分析 EventLog 来获取历史任务的执行信息。Spark 很贴心的提供了一个事件总线 ReplayListenerBus，只要输入 event log 流，就可以把该任务的所有事件重播一遍，然后你就可以注册自己的监听器来监听需要的事件。这些事件数据是最底层的数据，而 history server 提供的数据有一部分是经过聚合统计的，可能存在部分字段对不上，对应的代码可以参考 SparkListener，里面包括了所有的事件结构体。
Metrics
除了事件，Spark 也提供了 metrics 数据，但是相比 event，metrics 的这部分数据显得有点弱，主要包括了两部分
- 调度数据
JobScheduler 是 Spark 的调度中心，而 metrics 输出了 JobScheduler 的几个数据结构，比如所有的 job，可被执行的 job，正在执行的 stage，等待的 stage 等 - 资源使用
资源使用主要是依赖 BlockManager 内的数据，包括已使用的堆大小，已使用的堆外大小，已使用的磁盘大小等
默认下，Spark 是不打开 metrics，可以从 $SPARK_HOME/conf/metrics.properties 修改相关配置，如下配置，打开 Spark 的 metrics 并每过 10 秒输出到控制台。
*.sink.console.class=org.apahce.spark.metrics.sink.ConsoleSink
*.sink.console.period=10
*.sink.console.unit=seconds
此外，Spark 非常贴心的为每个应用留了一个 REST 接口 /metrics/json，如果是 streaming 任务，可以打开 streaming 的 metrics 开关，spark.sql.streaming.metricsEnabled 默认是关的。这样在 /metrics/json 接口返回的 JSON 里就会包括 streaming 的 metrics。
埋点数据
一般我们用的 Spark 都是 on YARN，而 YARN 的日志聚合功能一般也是会打开的，所以 Spark 的日志会被 YARN 输出到 HDFS 上，这样自己去解析日志也会很容易。如果想要通过日志来监控 Spark 任务执行情况，那么可能会需要业务层面的埋点，否则只能针对一些异常日常进行监测。
总结
Spark 由于本身只是计算执行引擎，没有常驻进程（除去辅助的 history server），所以在监控层面相对比较灵活，但是也有复杂的地方，当每天有成千上万个 Spark 任务提交到集群执行的时候，那么需要监控的数据量就上来了，粒度越细，监控的压力越大。
除了 Spark 的 History Server 之外，Dr. Elephant 也是一款不错的开源的基于 YARN 的计算任务性能分析软件，由 LinkedIn 贡献，详细可以参考博客dr-elephant 介绍。
参考
Spark 官方监控文档
Spark 代码 2.4.0
