Spark 作業監控

北風網spark學習筆記

對於Spark作業的監控，Spark給我們提供了很多種方式：Spark Web UI，Spark History Web UI，RESTFUL API以及Metrics。

SparkWebUI以及監控實驗

• 每提交一個Spark作業，並且啓動SparkContext之後，都會啓動一個對應的Spark Web UI服務。默認情況下Spark Web UI的訪問地址是driver進程所在節點的4040端口。在Spark Web UI上會展示作業相關的詳細信息，非常有用，是Spark作業監控的最主要的手段。

Spark Web UI包括了以下信息：

1. stage和task列表
2. RDD大小以及內存使用的概覽
3. 環境信息
4. 作業對應的executor的信息

• 可以通過在瀏覽器中訪問http://<driver-node>:4040地址，來進入Spark Web UI界面。如果多個driver在一個機器上運行，它們會自動綁定到不同的端口上。默認從4040端口開始，如果發現已經被綁定了，那麼會選擇4041、4042等端口，以此類推。
• 要注意的是，這些信息默認情況下僅僅在作業運行期間有效並且可以看到。一旦作業完畢，那麼driver進程以及對應的web ui服務也會停止，我們就無法看到已經完成的作業的信息了。如果要在作業完成之後，也可以看到其Spark Web UI以及詳細信息，那麼就需要啓用Spark的History Server。

監控實驗

1. 通過spark-shell以standalone模式執行一個wordcount作業，通過直接訪問4040端口以及從8080端口兩種方式進入web ui。
2. 在作業運行完畢之後，再嘗試看看作業的Web UI。
3. 通過spark-shell以yarn模式執行一個wordcount作業，並重覆上述過程。

standalone模式下查看歷史作業的WebUI

默認情況下，一個作業運行完成之後，就再也無法看到其web ui以及執行信息了，在生產環境中，這對調試以及故障定位有影響。

如果要在作業執行完之後，還能看到其web ui，那麼必須將作業的spark.eventLog.enabled屬性設置爲true，這個屬性會告訴spark去記錄該作業的所有要在web ui上展示的事件以及信息。

如果spark記錄下了一個作業生命週期內的所有事件，那麼就會在該作業執行完成之後，我們進入其web ui時，自動用記錄的數據重新繪製作業的web ui。

有3個屬性我們可以設置

1. spark.eventLog.enabled，必須設置爲true
2. spark.eventLog.dir，默認是/tmp/spark-events，建議自己手動調整爲其他目錄，比如/usr/local/spark-event或是hdfs目錄，必須手動創建
3. spark.eventLog.compress ，是否壓縮數據，默認爲false，建議可以開啓壓縮以減少磁盤空間佔用

• 這些屬性可以在提交一個作業的時候設置
• 如果想要對所有作業都啓用該機制，那麼可以在spark-defaults.conf文件中配置這三個屬性

實驗

1. 先看看之前的已經執行完成的作業，是否可以進入spark web ui界面
2. 關閉現有的master和worker進程
3. 修改spark-defaults.conf文件，配置上述三個屬性，啓用standalone模式下的作業歷史信息記錄，手動創建hdfs目錄
4. 重新啓動spark集羣
5. 使用spark-shell提交一個作業，然後再次嘗試進入spark web ui界面

注意：如果要讓spark完成作業的事件記錄，那麼必須最後以sc.stop()結尾。

啓動HistoryServer查看歷史作業的Web UI

修改spark-defaults.conf

spark.eventLog.enabled  true
spark.eventLog.dir      hdfs://192.168.75.101:9000/event_log_dir
spark.eventLog.compress true

spark-env.sh

export SPARK_HISTORY_OPTS="-Dspark.history.ui.port=18080 -Dspark.history.retainedApplications=50 -Dspark.history.fs.logDirectory=hdfs://192.168.75.101:9000/event_log_dir"

務必預先創建好hdfs://192.168.75.101:9000/spark-events目錄
而且要注意，spark.eventLog.dir與spark.history.fs.logDirectory指向的必須是同一個目錄
因爲spark.eventLog.dir會指定作業事件記錄在哪裏，spark.history.fs.logDirectory會指定從哪個目錄中去讀取作業數據

• 啓動HistoryServer: ./sbin/start-history-server.sh
• 訪問地址: 192.168.75.101:18080

實驗

1. 停止集羣
2. 配置spark-env.sh
3. 重啓集羣
4. 啓動history server
5. 運行spark-shell，在standalone模式下和yarn模式下，分別執行一個作業
6. 通過192.168.75.101:18080的HistoryServer UI可以看到所有運行後的作業信息

使用curl+REST API進行作業監控

除了查看ui上的統計來監控作業，還可以通過Spark提供的REST API來獲取作業信息，並進行作業監控。REST API就給我們自己開發Spark的一些監控系統或平臺提供了可能。REST API是通過http協議發送的，並給我們返回JSON格式的數據。因此無論你是用java，還是python，亦或是php，都可以獲取Spark的監控信息。

運行中的作業以及history server中的歷史作業，都可以獲取到信息

1. 如果是要獲取運行中的作業的信息，可以通過http://host:4040/api/v1/...的方式來獲取
2. 如果是要獲取歷史作業的信息，可以通過http://host:18080/api/v1/...的方式來獲取

比如說，http://192.168.75.101:18080/api/v1/applications，就可以獲取到所有歷史作業的基本信息

以下是所有API的說明

API	說明
/applications	獲取作業列表
/applications/[app-id]/jobs	指定作業的job列表
/applications/[app-id]/jobs/[job-id]	指定job的信息
/applications/[app-id]/stages	指定作業的stage列表
/applications/[app-id]/stages/[stage-id]	指定stage的所有attempt列表
/applications/[app-id]/stages/[stage-id]/[stage-attempt-id]	指定stage attempt的信息
/applications/[app-id]/stages/[stage-id]/[stage-attempt-id]/taskSummary	指定stage attempt所有task的metrics統計信息
/applications/[app-id]/stages/[stage-id]/[stage-attempt-id]/taskList	指定stage attempt的task列表
/applications/[app-id]/executors	指定作業的executor列表
/applications/[app-id]/storage/rdd	指定作業的持久化rdd列表
/applications/[app-id]/storage/rdd/[rdd-id]	指定持久化rdd的信息
/applications/[app-id]/logs	下載指定作業的所有日誌的壓縮包
/applications/[app-id]/[attempt-id]/logs	下載指定作業的某次attempt的所有日誌的壓縮包

• 當作業運行在yarn中時，每個作業都可能會嘗試多次運行，所以上述的所有[app-id]都必須替換爲[app-id]/[attempt-id]
• 這些API都非常便於讓我們去基於它們開發各種監控系統或應用。特別是，spark保證以下幾點:

1. API永遠不會因爲版本的變更而更改
2. JSON中的字段用於不會被移除
3. 新的API接口可能會被增加
4. 已有API接口中可能會增加新的字段
5. API的新版本可能會作爲新接口被添加進來。新版本的接口不要求向後兼容。
6. API版本可能會被刪除掉，但是肯定是在一個相關的新API版本發佈之後。

• 要注意的是，當查看運行中作業的UI時，applications/[app-id]還是需要提供的，儘管此時在那個4040端口上可能只有一個作業在運行。比如說，要查看正在運行的作業的job列表，可能需要使用以下API: http://host:4040/api/v1/applications/[app-id]/jobs
• 這主要是爲了儘可能地複用API接口

實驗

1. 安裝curl工具，來發送http請求:yum install -y curl
2. 試一試以上的幾個API，去獲取standalone模式和yarn模式運行中的作業，以及歷史作業的信息

Spark Metrics系統以及自定義Metrics Sink

Spark有一套可配置的metrics系統，是基於Coda Hale Metrics類庫實現的。該metrics系統允許用戶將Spark的metrics統計指標上報到多種目標源（sink）中，包括http，jmx和csv文件。這個metrics系統是通過一個配置文件進行配置的，在$SPARK_HOME目錄的conf目錄下，用一個metrics.properties文件來配置。可以通過在spark-defaults.conf中配置spark.metrics.conf屬性來配置自定義的文件路徑。spark metrics依據不同的spark組件劃分爲了不同的實例。在每一個實例中，你都可以配置一系列的sink來指定該實例的metrics要上報到哪裏去。

以下實例是目前被支持的

master: spark standalone master進程
applications: master中的組件，可以上報所有application的metrics
worker: spark standalone worker進程
executor: spark executor進程
driver: spark driver進程

每個實例都可以上報metrics到0個或多個sink中。sink被包含在了org.apache.spark.metrics.sink包下。

• ConsoleSink: 日誌metrics，打印到控制檯

• CSVSink: 以固定的頻率將metrics數據導出到CSV文件中

• JmxSink: 註冊metrics到JMX console中

• MetricsServlet: 在Spark UI中添加一個servlet來通過JSON數據提供metrics數據（之前的REST API就是通過該方式進行的）

• Slf4jSink: 以日誌的形式發送metrics到slf4j

• GraphiteSink: 發送metrics到Graphite節點

• GangliaSink: 發送metrics到Ganglia節點。

  Spark也支持Ganglia sink，但是沒有包含在默認的打包內，因爲有版權的問題。

  要安裝GangliaSink，就需要自己編譯一個spark。要注意，必須要提供必要的授權信息。

metrics系統的意義

1. metrics只能在spark web ui上看到，或者是history server上看歷史作業的web ui。
2. 如果你希望將metrics數據，結構化處理以後導入到，比如mysql裏面，然後進行一個存儲，開發一個系統對外開放
3. spark集羣運行分析系統
4. 自定義metrics sink，將所有的metrics全部寫入外部的你指定的存儲文件中，然後定時導入到你的mysql中

實驗: 自定義metrics sink

1. 停止集羣
2. 配置metrics.properties文件，啓用CSVSink
3. 重啓集羣
4. 運行一個作業，查看指定目錄下的csv文件