如何监控Spark运行状态

Spark运行过程中的状态监控除了可以通过Web UI、Driver控制台日志、logs文件夹日志、work文件夹日志外，还可以使用专门的Profiler监控工具来进行。Profiler工具分为JVM方面的Profiler工具和集群方面的Profiler方法。

1.Web UI监控

通过Web UI控制台可以查看任务运行的基本信息，包括如下内容。

1）调度器运行阶段和task信息。

2）RDD大小和内存使用情况信息。

3）系统环境变量。

4）执行器的运行状态。

读者可以通过在浏览器输入“http：//<driver-node>：4040”查看应用信息。如果在一个主机上运行多个SparkContext，那么端口会因为被占用而自动往后顺延（如4040、4041、4042，依此类推）。注意在Web UI展示的信息默认在应用运行的时候才能查看。如果需要将它们持久化存储待以后查看，则可以在任务运行前将spark.eventLog.enabled设置为true，这样任务信息就会持久化到指定文件夹，后面将进一步解释该操作方法。

图5-1 通过Web UI监控应用状态

2.Driver控制台监控

在spark-shell中或spark-submit模式提交job后，Driver控制台在任务执行过程中会输出各种日志信息，包括不同级别的提示、运算过程中不同组件的实时运行状态、不同task执行的结果等，如图5-2所示。如果程序出错，一般先通过Driver日志查看问题原因，如果想看细节原因，则可以查看work的logs日志。调整Spark日志级别的配置文件是“$SPARK_HOME/conf/log4j.properties”，默认级别是INFO，如果将其改为DEBUG，那么有用的信息还没看完，就被大量的心跳检测日志给淹没了，所以可以根据实际情况自行调整日志级别。

图5-2 Driver控制台输出的信息

3.log文件夹监控

每个slave节点上，作业运行的日志也会详细的记录到默认的SPARK_HOME/work目录下。每个作业会对应两个文件，stdout和stderr，包含了控制台上的所有的历史输出。

4.历史服务器

如果Spark运行在Mesos或者YARN上，通过Spark的历史服务器仍然可以重建任务执行结束的应用UI，只要历史服务器存有应用程序执行的事件日志即可。

要使用历史服务器，可以在spark-defaults.conf下添加并配置spark.eventLog.enabled、spark.eventLog.dir和spark.eventLog.compress信息，如图5-3所示，然后在spark-env.sh增加相关的SPARK_HISTORY_OPTS配置信息，如图5-4所示，以上信息配置好后在SPARK_ HOME/sbin下执行./start-history-server.sh即可启动日志服务器。

图5-3 配置spark-defaults文件信息

图5-4 配置spark-env文件信息

5.JVM监控

JVM监控主要包括Yourkit、Jconsole工具以及JMap和JStack命令。(www.xing528.com)

（1）Yourkit

YourKit Java Profiler是业界领先的Java和.NET的剖析工具。一般来说CPU和内存的剖析是很困难的，然而YourKit创造出了革命性的剖析工具，其主要应用在研发和生产阶段，为专业的Java和.NET开发者提供优良的性能分析功能。

（2）Jconsole

Jconsole是一个基于JMX的监视工具。它使用Java虚拟机的JMX机制来分析运行在Java平台的应用程序，分析的信息包括性能信息与资源耗费信息。

（3）Jmap

Jmap是Java虚拟机本身自带的一种内存映像命令。使用Jmap命令可以生成堆转储快照，有时候也生成heapdump或dump文件。Jmap不仅仅可以获取dump文件，还可以查询finalize执行队列、Java堆和永久代的详细信息，如空间使用率以及当时所使用的收集器种类。

（4）Jstack

Jstack主要用于查看某Java进程、core file和远程调试服务的Java堆栈信息。

Jstack可以定位到线程堆栈，根据堆栈信息可以定位到具体代码，所以它在JVM性能调优中使用的较多。如果Java程序崩溃生成core文件，Jstack工具可以用来获得core文件的Java栈和本地栈的信息，从而可以轻松地获知程序是如何崩溃以及在何处发生问题。另外，Jstack工具还可以监控正在运行的Java程序状态，看到当时运行的Java程序的Java Stack和Native Stack的信息。

6.集群监控工具

集群监控工具主要包括Ganglia和Ambaria等，下面主要介绍这两种监控工具。

（1）Ganglia

Ganglia于2000年诞生于加州大学伯克利分校，是一个专门为集群和网格这类高性能计算系统设计的可扩展的分布式监控系统。它基于分层监控体系，能针对多集群同时监控。因为它巧妙的数据结构和算法能让每个被监控节点的资源消耗达到一个很低的水平。它已经被世界上数千集群所使用。

要了解Ganglia，可以先了解它的基本组成结构，包括Gmond、Gmetad、RDD tool和基于PHP的Web Server，下面将逐一介绍。

1）Gmond。Gmond在Ganglia中可以看作是监控守护进程。这是一个很小的安装在每个需要被监控的节点上的服务。在节点中Gmond线程会搜集各类信息，包括CPU消耗、内存消耗以及负载等信息，然后把这些信息通过TCP以XML格式传输。此外Gmond是多线程的，其主要Gmond配置文件信息在/etc/gmond.conf中。

2）Gmetad。Gmetad是一个从其他Gmetad守护进程和所有Gmond进程收集数据的进程。Gmetad将收集的数据以RRD（Round Robin Data Base）形式进行存储。Gmetad的主要配置文件在/etc/Gmetad.conf中，在每个集群中至少需要一个节点安装Gmetad守护进程，集群中的这个Gmetad进程负责收集该集群中各节点的Gmond进程发送的监测信息。

3）RDD tool。Ganglia使用RDD tool来储存它的数据，这是一个优秀的开源数据库工具。RDD tool按时间层级进行监控信息统计，依次为每小时到每年这几个时间梯度。RDD tool会使用这些数据进行画图，它是Ganglia中画图的核心组件。

4）Web Server。在拥有以上3个组件之后，在客户端显示监控信息还需要Web Server，Ganglia中的Web Server是基于PHP语言，主要用来把RDD tool画的图进行展示，一般选择使用Apache作为监控信息展示服务器。

其整体架构图如图5-5所示，可以看出这是一个分层级监控系统，根据Gmetad可以搜集其他集群中Gmetad收集到的本地集群的数据，在一个Web端就能同时监控不同集群的运行状态信息。

图5-5 Ganglia系统架构

2.Ambaria

Ambari是由Hortonworks主导的开源项目，主要用于Hadoop分布式集群的配置管理工作，属于Apache基金下管理的项目，它最初用于Hadoop系统运维，也支持Spark集群安装与监控。

Ambari所采用的架构是Server/Client的模式，其主要由两部分组成：ambari-agent和ambari-server。Ambari利用其他工业界使用成熟的工具，例如依赖Python的ambari-server，同时ambari-agent还会依赖Ruby，、Puppet和Facter等工具，其中Puppet是分布式集群配置管理工具，也是典型的Server/Client模式，能够集中式管理分布式集群的安装配置部署，主要语言是Ruby。Facter是用Python写的一个节点资源采集库，用于采集节点的系统信息，例如操作系统和主机信息等。由于ambari-agent主要是用Python写的，因此用Facter可以很好地采集到节点信息。此外Ambari还利用其他一些监控工具如Nagios和Ganglia，使用这些更专业的工具来监控集群状况。