强力推荐，相见恨晚的文档，建议先看
关于Spark监控，推荐一个讲的非常好的PPT：monitoring-spark-applications，简练、全面的讲解了Spark监控的必要性、方法、缺点及改进方法。
下面是我自己的一些总结
本文内容主要来自Spark Monitoring官方文档和Cloudera文档，和一些自己的思考。
Spark UI监控，有三个维度
对Spark运行时的状态进行监控可以对运行时间较长的大型任务运行过程心中有数，明白时间花费在什么地方，看任务在什么地方发生异常。首先说明Spark的一个application的划分规则。
- job :job是application的组成单位。 A job is triggered by an action, like count() or saveAsTextFile(). Click on a job to see information about the stages of tasks inside it. 一个 job，就是由一个 rdd 的 action 触发的动作，可以简单的理解为，当你需要执行一个 rdd 的 action 的时候，会生成一个 job.
- stage : stage 是 job 的组成单位，就是说，一个 job 会被切分成 1 个或 1 个以上的 stage，然后各个 stage 会按照执行顺序依次执行。job 根据Spark的shuffle过程来切分 stage，如某stage有2个shuffle过程，它就被切分成3个stage.
- task : A unit of work within a stage, corresponding to one RDD partition。即 stage 下的一个任务执行单元。“一般来说，一个 rdd 有多少个 partition，就会有多少个 task，因为每一个 task 只是处理一个 partition 上的数据。”
对Spark的监控需求，可以按需划分为针对job的监控、针对stage的监控和针对task的监控，Spark UI提供了以下三种监控界面：
- 针对job的监控：每次查询都是一个Job，下图显示一个已经完成的查询任务和一个正在进行的查询任务，每一个任务的具体进度在行末展示
- 针对stage的监控：一个job里所有的stage列表
- 针对task的监控：一个stage里所有的task列表
每一种监控方式都能展示其每一步消耗的时间，可以通过Event Timeline的方式只管的看时间消耗。针对某一消耗时长异常的步骤进行检查或者调优。
这种监控方式的优点是直观易懂，而且大部分的表格可以用json的形式提供给其他应用，缺点是图形化的工具不易在其他界面上集成。
值得注意的是，Spark UI监控的端口有配置有些小trick，spark默认配置和CDH配置有所不同：
Spark Monitoring 将端口默认配置为18080和4040.
For the history server, they would typically be accessible at http://:18080/api/v1, and for a running application, at http://localhost:4040/api/v1.
CDH将端口配置为18088和8088.
From Managing the Spark History Server and Ports Used by Components of CDH 5.
Spark 日志监控，详细但不直观
此外，Spark日志也可以打印Spark的运行状态，节选一个task从启动到结束的日志：
18/07/05 18:18:24 INFO executor.CoarseGrainedExecutorBackend: Got assigned task 1242
18/07/05 18:18:24 INFO executor.Executor: Running task 32.0 in stage 18.0 (TID 1242)
18/07/05 18:18:24 INFO rdd.HadoopRDD: Input split: hdfs://sdg/user/hive/warehouse/transfer.db/mobile_reg_info_mid_orc/part_date=2016-10-31/part-00003-bd8e8e72-7946-45c4-b995-badead467bab.c000:268435456+69819839
18/07/05 18:18:24 INFO orc.OrcRawRecordMerger: min key = {originalTxn: 0, bucket: -1, row: 15099999}, max key = null
18/07/05 18:18:24 INFO orc.ReaderImpl: Reading ORC rows from hdfs://sdg/user/hive/warehouse/transfer.db/mobile_reg_info_mid_orc/part_date=2016-10-31/part-00003-bd8e8e72-7946-45c4-b995-badead467bab.c000 with {include: [true, false, false, false, false, false, false, false], offset: 268435456, length: 9223372036854775807}
18/07/05 18:18:25 INFO executor.Executor: Finished task 32.0 in stage 18.0 (TID 1242). 1510 bytes result sent to driver这种方式较优点是易于输出、易于在其他工具上集成，缺点是不直观。
对于交互式查询场景的监控
- 每次查询都是一个Job，可以展示所有已经完成的查询任务和正在进行的查询任务
- 如果只想大概了解程序运行的进度（类比MR过程中map和reduce的百分比），建议展示所有stage的运行进度，如上图“针对job的监控”所示。
- 如果想了解运行程序过程中，具体到哪一步卡住了，建议展示“针对stage的监控：一个job里所有的stage列表”，查看该内容并排查错误需要对Spark的运行机制有一定的了解。
- “针对task的监控：一个stage里所有的task列表”具体到了代码行的层面，需要对Spark很了解才能理解，需要专业的开发人员解读。