监控和工具
监控Spark应用有很多种方式：web UI，metrics 以及外部工具。
Web界面
每个SparkContext都会启动一个web UI，其默认端口为4040，并且这个web UI能展示很多有用的Spark应用相关信息。包括：
- 一个stage和task的调度列表
- 一个关于RDD大小以及内存占用的概览
- 运行环境相关信息
- 运行中的执行器相关信息
你只需打开浏览器，输入 http://<driver-node>:4040 即可访问该web界面。如果有多个SparkContext在同时运行中，那么它们会从4040开始，按顺序依次绑定端口（4041,4042，等）。
注意，默认情况下，这些信息只有在Spark应用运行期内才可用。如果需要在Spark应用退出后仍然能在web UI上查看这些信息，则需要在应用启动前，将 spark.eventLog.enabled 设为 true。这项配置将会把Spark事件日志都记录到持久化存储中。
事后查看
Spark独立部署时，其对应的集群管理器也有其对应的 web UI。如果Spark应用将其运行期事件日志保留下来了，那么独立部署集群管理器对应的web UI将会根据这些日志自动展示已经结束的Spark应用。
如果Spark是运行于Mesos或者YARN上的话，那么你需要开启Spark的history server，开启event log。开启history server需要如下指令：
./sbin/start-history-server.sh
如果使用file-system provider class（参考下面的 spark.history.provider），那么日志目录将会基于 spark.history.fs.logDirectory 配置项，并且在表达Spark应用的事件日志路径时，应该带上子目录。history server对应的web界面默认在这里 http://<server-url>:18080。同时，history server有一些可用的配置如下：
| 环境变量 |
含义 |
SPARK_DAEMON_MEMORY |
history server分配多少内存（默认: 1g） |
SPARK_DAEMON_JAVA_OPTS |
history server的 JVM参数（默认：none） |
SPARK_PUBLIC_DNS |
history server的外部访问地址，如果不配置，那么history server有可能会绑定server的内部地址，这可能会导致外部不能访问（默认：none） |
SPARK_HISTORY_OPTS |
history server配置项（默认：none）：spark.history.* |
| 属性名称 |
默认值 |
含义 |
| spark.history.provider |
org.apache.spark.deploy
.history.FsHistoryProvider |
Spark应用历史后台实现的类名。目前可用的只有spark自带的一个实现，支持在本地文件系统中查询应用日志。 |
| spark.history.fs.logDirectory |
file:/tmp/spark-events |
history server加载应用日志的目录 |
| spark.history.fs.update.interval |
10s |
history server更新信息的时间间隔。每次更新将会检查磁盘上的日志是否有更新。 |
| spark.history.retainedApplications |
50 |
UI上保留的spark应用历史个数。超出的将按时间排序，删除最老的。 |
| spark.history.ui.port |
18080 |
history server绑定的端口 |
| spark.history.kerberos.enabled |
false |
history server是否启用kerberos验证登陆。如果history server需要访问一个需要安全保证的hadoop集群，则需要开启这个功能。该配置设为true以后，需要同时配置 spark.history.kerberos.principal 和 spark.history.kerberos.keytab |
| spark.history.kerberos.principal |
(none) |
登陆history server的kerberos 主体名称 |
| spark.history.kerberos.keytab |
(none) |
history server对应的kerberos keytab文件路径 |
| spark.history.ui.acls.enable |
false |
指定是否启用ACL以控制用户访问验证。如果启用，那么不管某个应用是否设置了 spark.ui.acls.enabled，访问控制都将检查用户是否有权限。Spark应用的owner始终有查看的权限，而其他用户则需要通过 spark.ui.view.acls 配置其访问权限。如果禁用，则不会检查访问权限。 |
| spark.history.fs.cleaner.enabled |
false |
指定history server是否周期性清理磁盘上的event log |
| spark.history.fs.cleaner.interval |
1d |
history server清理磁盘文件的时间间隔。只会清理比 spark.history.fs.cleaner.maxAge 时间长的磁盘文件。 |
| spark.history.fs.cleaner.maxAge |
7d |
如果启用了history server周期性清理，比这个时间长的Spark作业历史文件将会被清理掉 |
注意，所有web界面上的 table 都可以点击其表头来排序，这样可以帮助用户做一些简单分析，如：发现跑的最慢的任务、数据倾斜等。
注意history server 只展示已经结束的Spark作业。一种通知Spark作业结束的方法是，显式地关闭SparkContext（通过调用 sc.stop()，或者在 使用 SparkContext() 处理其 setup 和 tear down 事件（适用于python），然后作业历史就会出现在web UI上了。
REST API
度量信息除了可以在UI上查看之外，还可以以JSON格式访问。这能使开发人员很容易构建新的Spark可视化和监控工具。JSON格式的度量信息对运行中的Spark应用和history server中的历史作业均有效。其访问端点挂载在 /api/v1 路径下。例如，对于history server，一般你可以通过 http://<server-url>:18080/api/v1 来访问，而对于运行中的应用，可以通过 http://localhost:4040/api/v1 来访问。
| 端点 |
含义 |
/applications |
所有应用的列表 |
/applications/[app-id]/jobs |
给定应用的全部作业列表 |
/applications/[app-id]/jobs/[job-id] |
给定作业的细节 |
/applications/[app-id]/stages |
给定应用的stage列表 |
/applications/[app-id]/stages/[stage-id] |
给定stage的所有attempt列表 |
/applications/[app-id]/stages/[stage-id]/[stage-attempt-id] |
给定attempt的详细信息 |
/applications/[app-id]/stages/[stage-id]/[stage-attempt-id]/taskSummary |
指定attempt对应的所有task的概要度量信息 |
/applications/[app-id]/stages/[stage-id]/[stage-attempt-id]/taskList |
指定的attempt的所有task的列表 |
/applications/[app-id]/executors |
给定应用的所有执行器 |
/applications/[app-id]/storage/rdd |
给定应用的已保存的RDD列表 |
/applications/[app-id]/storage/rdd/[rdd-id] |
给定的RDD的存储详细信息 |
/applications/[app-id]/logs |
将给定应用的所有attempt对应的event log以zip格式打包下载 |
/applications/[app-id]/[attempt-id]/logs |
将给定attempt的所有attempt对应的event log以zip格式打包下载 |
如果在YARN上运行，每个应用都由多个attempts，所以 [app-id] 实际上是 [app-id]/[attempt-id]。
这些API端点都有版本号，所以基于这些API开发程序就比较容易。Spark将保证：
- 端点一旦添加进来，就不会删除
- 某个端点支持的字段永不删除
- 未来可能会增加新的端点
- 已有端点可能会增加新的字段
- 未来可能会增加新的API版本，但会使用不同的端点（如：api/v2 ）。但新版本不保证向后兼容。
- API版本可能会整个丢弃掉，但在丢弃前，一定会和新版本API共存至少一个小版本。
注意，在UI上检查运行中的应用时，虽然每次只能查看一个应用， 但applicatoins/[app-id] 这部分路径仍然是必须的。例如，你需要查看运行中应用的作业列表时，你需要输入 http://localhost:4040/api/v1/applications/[app-id]/jobs。虽然麻烦点，但这能保证两种模式下访问路径的一致性。
度量
Spark的度量子系统是可配置的，其功能是基于Coda Hale Metrics Library开发的。这套度量子系统允许用户以多种形式的汇报槽（sink）汇报Spark度量信息，包括：HTTP、JMX和CSV文件等。其对应的配置文件路径为：${SPARK_HOME}/conf/metrics.properties。当然，你可以通过spark.metrics.conf 这个Spark属性来自定义配置文件路径（详见configuration property）。Spark的各个组件都有其对应的度量实例，且这些度量实例之间是解耦的。这些度量实例中，你都可以配置一系列不同的汇报槽来汇报度量信息。以下是目前支持的度量实例：
-
master: 对应Spark独立部署时的master进程。
-
applications: master进程中的一个组件，专门汇报各个Spark应用的度量信息。
-
worker: 对应Spark独立部署时的worker进程。
-
executor: 对应Spark执行器。
-
driver: 对应Spark驱动器进程（即创建SparkContext对象的进程）。
每个度量实例可以汇报给0~n个槽。以下是目前 org.apache.spark.metrics.sink 包中包含的几种汇报槽（sink）：
-
ConsoleSink:将度量信息打印到控制台。
-
CSVSink: 以特定的间隔，将度量信息输出到CSV文件。
-
JmxSink: 将度量信息注册到JMX控制台。
-
MetricsServlet: 在已有的Spark UI中增加一个servlet，对外提供JSON格式的度量数据。
-
GraphiteSink: 将度量数据发到Graphite 节点。
-
Slf4jSink: 将度量数据发送给slf4j 打成日志。
Spark同样也支持Ganglia，但因为license限制的原因没有包含在默认的发布包中：
-
GangliaSink: 将度量信息发送给一个Ganglia节点或者多播组。
如果需要支持GangliaSink的话，你需要自定义Spark构建包。注意，如果你包含了GangliaSink代码包的话，就必须同时将 LGPL-licensed 协议包含进你的Spark包中。对于sbt用户，只需要在编译打包前设置好环境变量：SPARK_GANGLIA_LGPL即可。对于maven用户，启用 -Pspark-ganglia-lgpl 即可。另外，除了修改集群的Spark之外，用户程序还需要链接 spark-ganglia-lgpl 工件。
度量系统配置文件语法可以参考这个配置文件示例：${SPARK_HOME}/conf/metrics.properties.template
高级工具
以下是几个可以用以分析Spark性能的外部工具：
- 集群整体监控工具，如：Ganglia，可以提供集群整体的使用率和资源瓶颈视图。比如，Ganglia的仪表盘可以迅速揭示出整个集群的工作负载是否达到磁盘、网络或CPU限制。
- 操作系统分析工具，如：dstat, iostat, 以及 iotop ，可以提供单个节点上细粒度的分析剖面。
- JVM工具可以帮助你分析JVM虚拟机，如：jstack可以提供调用栈信息，jmap可以转储堆内存数据，jstat可以汇报时序统计信息，jconsole可以直观的探索各种JVM属性，这对于熟悉JVM内部机制非常有用。
- 转载自 并发编程网 - ifeve.com
