监控Spark应用方法简介

监控Spark应用有不少种方法。

Web接口
每个SparkContext启动一个web UI用来展现应用相关的一些很是有用的信息，默认在4040端口。这些信息包括：

任务和调度状态的列表
RDD大小和内存使用的统计信息
正在运行的executor的信息
环境信息
你能够在浏览器中打开http://<driver-node>:4040网址来访问这些信息。若是在同一台机器上有多个SparkContext正在运行，那么他们的端口从4040开始依次增长（4041，4042等）。

Spark在单机模式下也提供了web UI。

注意，在全部这些web接口能够经过点击“表头”来对这些表格进行排序。这使得鉴别运行速度慢的任务、判别数据倾斜等很是容易。

Metrics
Spark基于Coda Hale Metrics库提供一个可配置的统计系统。这容许用户向不一样的终端发送统计信息，包括HTTP、JMX和CSV文件。统计系统能够经过配置文件来进行配置，Spark默认将配置文件保存在$SPARK_HOME/conf/mertics.conf。用户能够经过Java property spark.metrics.conf来修改配置文件的保存路径。Spark根据组件的不一样将统计信息分为多个实例。能够配置每个实例向多个方向发送统计信息。目前支持下面几种实例：

master:Spark管理进程
applications:位于master的组件，统计发送各类应用的信息
worker:Spark工做进程
executor:执行器
driver:Spark驱动程序
每个实例能够向多个渠道发送统计信息。渠道包含在包org.apache.spark.metrics.sink：

ConsoleSink：将统计信息发送到控制台
CSVSink：每隔一段时间将统计信息写入到CSV文件
GangliaSink：将统计信息发送到Ganglia或者多播组
JmxSink：将统计信息注册到JMX控制台
MetricsServlet：在Spark UI中添加servlet用来以JSON的方式提供统计信息
统计信息配置文件的语法有一个示例文件——$SPARK_HOME/conf/metrics.conf.template.

外部工具
有几个外部工具可用来衡量Spark做业的性能：

集群范围的监控工具，好比 Ganglia，能够洞察整个集群的利用率和资源瓶颈。例如，Ganglia仪表盘能够迅速揭示出某个特定载荷是磁盘相关，网络相关，仍是CPU相关的。
OS性能分析工具，好比 dstat, iostat,和 iotop， 能够提供各个节点的细粒度的分析。
JVM工具，好比 jstack提供了堆栈跟踪，jmap提供了建立堆转储，jstat提供了时间序列统计报告，还有jconsole提供了各类JVM属性的视觉显示，它们对JVM内部构件的温馨运做都是很是有用的。

 

讨论Spark的配置监控和性能优化（某课程笔记）
 
上完这节课之后，你将可以描述集群的概念
经过修改Spark的属性，环境变量，或者是日志属性来配置Spark
使用Web端界面，以及各类不一样的外部工具来监控Spark和应用程序
 
 
在Spark集群中有三种主要的组成部分。驱动程序，是放置主程序中SparkContext的地方,要运行一个集群，你须要一个集群管理器
它能够是单机版的集群管理器，也能够是 Mesos 或者 Yarn
而worker节点，就是放置执行器的地方


 
执行器，是运行计算和储存应用程序数据的地方。SparkContext以JAR或者Python文件
的形式向每一个执行器发送应用程序。最终，它向每一个执行器发送任务并运行
 
由于驱动程序在集群上调配任务，它应该在相同的本地网络中
  
的woker节点运行。若是要向集群发送远端请求


最好使用一个RPC，而且从附近的节点提交操做
 
咱们前面提到三个支持的集群管理器
 
对于Spark的配置，主要有三个主要的地方


Spark属性，你能够用SparkConf对象或者经过Java系统属性来设置应用程序的参数
环境变量，你能够用它们来设置每个机器的设定，好比IP地址这是经过配置每个节点上的conf/spark-env.sh脚本实现的
对于日志属性，它能够经过log4j.propertieis来进行设置
你能够选择修改目前位于SPARK_HOME/conf目录下的默认配置目录设定SPARK_CONF_DIR环境变量而且在这个目录下提供你的配置文件


 
 
这里有两种方法来设定Spark属性：
第一种方法是经过SparkConf对象来传递应用程序属性
第二种方法是动态地设置Spark的属性。Spark容许你在建立一个SparkContext的时候传递一个空的SparkConf
而后，在运行时用 “—master” 或者 “—conf” 参数命令行选项来提供设置值


你能够运行spark-submit脚本的时候，经过“—－help”来查看各类选项
另外一种设定Spark属性的方法是在spark-defaults.conf文件里设置
spark-submit脚本会从你的文件中读取这些配置
你能够在应用程序的默认端口为4040的Web客户端上查看Spark属性


最后我想提到的一件注意事项，直接SparkConf上设置的属性具备最高的优先级
spark-submit或者spark-shell是第二优先级，最后是spark-default.conf文件里的设置。


监控Spark应用程序有三种方法：第一种方法是使用基于Web的客户端，它的默认端口是4040
在应用程序运行期间，你能够在这个客户端上得到Spark实时监控信息
若是你但愿在程序运行完之后查看这些信息，你须要在应用程序开始以前把spark.eventlog.enabled属性设定为true,这样全部运行的信息就会被储存起来




Metrics是另外一种检测Spark应用程序的方法。这个metric系统是基于Coda Hale Metrics库的
你能够自定义输出的格式，例如CSV格式的运行报告
能够在conf目录下的metrics.properties文件中配置metrics系统


最后，也能够经过外部工具来监控Spark。例如，Gangalia是用来查看总体集群的利用状况和资源瓶颈的工具。
各类不一样的OS profiling工具和JVM工具也能够用来监测Spark


默认设置下，Web客户端能够在端口4040下查看，它显示当前
正在运行的应用程序的信息。Web客户端，能够看到任务协调器的状态，提交的任务状态，RDD的大小，内存使用量的报告，环境设置信息以及
正在运行的执行器的信息




要在应用程序运行完之后查看应用程序的历史，你须要启动历史记录服务器配置历史记录服务器能够规定给它分配多少内存
各类JVM的选项，服务器的公共地址以及一系列的属性




集群中的任何一种资源都有可能成为Spark的瓶颈
Spark的内存计算属性，数据序列化以及内存优化成为可以提高Spark效能的
两个主要的因素。


数据的序列化是一种提高网络效能并减小内存使用的关键这是当你要优化Spark应用程序须要优先考虑的
Spark提供两个数据序列化的库。Java序列化提供更多的选择，可是它们一般很慢
并且生成过大的序列化对象。但这个是Spark用来序列化对象的默认库
Kyro序列化比Java要快不少，可是不支持全部的序列化类型
你须要提早注册这些类库，来得到最好的性能效果,能够经过设置SparkConf对象来使用Kyro序列化




在内存优化中，你须要考虑三件事：
1)对象使用的内存有多少(不管你是否想将所有对象导入到内存中); 
2)获取这些对象的成本;
3)垃圾回收的管理费用


你建立一个RDD，先将它缓存，而后查看你驱动程序中的
SparkContext日志。查看日志能够帮助你了解数据集须要多少内存
这里有减小每一个对象内存使用量的一些建议。尽可能避免增长管理费用的某些Java特征
好比基于指针的数据结构和wrapper对象。若是能够的话,使用数组或者原始数据类型而且避免使用迭代结构




序列化储存也能够帮助减小内存使用。缺点是它会致使要花更多的时间来获取数据
由于在你使用这些数据以前，你必需要对它们进行反序列化


你能够在垃圾回收器中查看它发生的频率，以及它使用时间的、一系列指标。你能够经过将此行增长到SPARK_JAVA_OPTS环境变量中来实现它


为了要充分利用集群，并行的级别也是须要考虑的因素之一
它自动地被设置为任务文件的大小，可是你能够经过例如在SparkContext.textFile里的
选项参数来配置它。你也能够对spark.default.parallelism的config属性设置默认的并行级别。一般来讲，咱们建议在集群中
为每个CPU核设置2到3个任务
当你的内存不能容纳你的RDD的时候，你会获得一个OutOfMemoryError错误
在这种状况下，经过提高并行级别能够解决这个问题
经过提高并行级别，每个输入的任务集都会变得更小，这样内存就能够容纳了




经过Spark的广播变量的功能，能够极大地减少序列化对象的大小
有一个比较好的例子，好比你有某种静态的公共查询表
考虑一下把它变成一个广播变量，这样它就不须要被发送到
每个worker节点上，省去了不少序列化对象的工做
Spark将每个任务序列化以后的大小打印到主节点上。经过查看这些信息，
也能够帮助检查否有任务过大。若是你发现某些任务超过20KB，你就有必要考虑
是否须要对它进行优化，好比建立广播变量

 

 

 

 Spark1.0.0能够经过如下几种方式来对Spark应用程序进行监控：

• Spark应用程序的WebUI或者Spark Standalone的集群监控
• 指标，而后经过支持指标收集的集群监控系统，如ganglia进行监控
• 辅助监控工具

1：WebUI
      Spark应用程序提交后，driver和Executor之间不断的交换运行信息，能够经过driver的4040端口（默认端口）获取有用的Spark应用程序的运行信息，如：

• Stage和Task
• RDD大小和内存使用状况
• 环境变量信息
• executor的运行信息
• ...

      若是多个Spark应用程序在同一个client上以client方式提交，那么driver的WebUI端口将绑定从4040开始的连续端口，如4040、404一、4042...。
      须要注意的是，用过WebUI只能查看Spark应用程序在运行期间的信息，一旦Spark应用程序运行完，这些信息将没法查看，由于WebUI端口随Spark应用程序的完成而关闭。若是想要过后查看Spark应用程序的运行信息，那么须要配置history Server来持久化Spark应用程序运行信息。关于history Server参见Spark1.0.0 history server配置（正在撰写，迟点给上连接） 。

2：指标
      Spark采用了基于Coda Hale Metrics Library 的可配置的指标体系，经过各类指标收集器，如JMX、CSV、GraphiteSink、Ganglia等能够进行汇总报告。该指标体系的配置文件位于conf/metrics.properties（经过复制conf/metrics.properties.template生成或自建），若是要采用自定义的配置文件，还须要在属性配置上配置一下spark.metrics.conf。
      Spark的指标体系针对Spark不一样的组件分解成相应的实例，每一个实例涵盖一套指标。Spark如今支持的实例有：

• master
• worker
• applications
• driver
• executor

      Spark的指标体系支持多种收集器，每一个实例能够采用多个收集器，也能够不采用。Spark支持的收集器定义在org.apache.spark.metrics.sink，如今支持的收集器有：

• ConsoleSink
• CSVSink.
• JmxSink
• MetricsServlet
• GraphiteSink
• GangliaSink 由于版权问题，部署包默认不含有该收集器；若是须要，要从新编译嵌入LGPL受权代码的源码。具体使用参见用ganglia监控Spark1.0.0（正在撰写，迟点给上连接）。

3：辅助监控工具
      能够经过一些辅助监控工具对Spark应用程序运行先后和运行过程当中系统性能变化来监控Spark应用程序。这些辅助工具备：

• 集群监控系统，如ganglia、negios、zabbix等，这些工具能够监控整个集群的磁盘、网络、内存利用率和性能瓶颈；
• 操做系统性能分析工具，如dstat、iostat、iotop，这些工具能够对单台机器的性能进行细致地分析；
• JVM性能分析工具，如 jstack、jmap、jstat 、jconsole，这些工具能够对JVM进行详细的性能分析。