監控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、4041、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進行詳細的性能分析。