大數據處理已經進入了新時代，數據的復雜度越來越高，人們對數據實時處理的要求也越來越高。新時代帶來了很多的新改變，但是最大程度創造數據價值是大數據時代不變的宗旨。隨著實時數據處理的用例越來越多，實時數據處理框架也豐富起來，例如， Apache Spark、Storm、 Heron、 Flink、Apex、 Kafka Streams 等等。每一種框架都有其特定的適用場景，但是框架多樣化也帶來了一些問題，增加了數據處理的復雜性，增加了運營難度。
Apache Spark是當前最流行的數據處理技術，下面我們就來回顧一下Spark的基本知識。
Spark 是什么?
Spark是大數據處理的一種通用框架，主要應用在批處理和流式數據。下面我們來看一下Spark的執行模型以及Spark架構的組成部分。
1.Spark Manager和Master Manager主要運行在以下模式中：
Standalone: 單一的cluster manager，管理方便。
Mesos: 公司常用模式，使用方便靈活。
Yarn:是目前最有前景的部署模式，默認配置為Hadoop 2.0。
2.Spark Worker: 運行在standalone模式下，是Spark的工作節點，用于執行提交的作業。
3.Spark Executor: 真正執行作業的地方，一個集群一般包含多個Executor，每個Executor接收Driver的命令Launch Task，一個Executor可以執行一到多個Task。
4.Spark Driver: 一個Spark作業運行時包括一個Driver進程，也是作業的主進程，負責作業的解析、生成Stage并調度Task到Executor上。包括DAGScheduler，TaskScheduler。
Spark Driver會創建一個Spark Context，并與Manager、Master通信，在worker節點上獲取資源。Worker在本地為每個應用創建executor。完成之后，Driver和Executor就可以直接進行通信了。工作過程中，worker會一直監視Executor的情況。Driver中的DAGScheduler會根據用戶程序，生成執行計劃，并調度執行，Driver等程序全部結束之后才會結束。
Spark應用程序的執行是由很多組件共同協作來完成的。所以，如果要在生產環境中部署Spark，那么就要時刻監控不同組件，了解組件性能參數，當發生錯誤時，要能夠及時報警，合理處置。
Monitoring Spark Streaming 面臨的挑戰
Spark UI提供了儀表板功能，但是如果你想要投入實際生產，僅僅安裝這個是遠遠不夠的。必須要能夠時刻監控Spark的內部運作和其組件的情況。
我們要分三個層面來監控Spark：
1.Spark的基礎組成部分：Master、Standalone、Mesos、Yarn、Workers
2.Applications ：Driver、Executors
3.Underlying hosts：Disks、CPU、網絡
這三個層面是相互依存、密不可分的。如果主機或者磁盤發生故障，那么Spark的基礎設施就會發生問題進而影響到應用程序。所以，在這三層之間建立相關的洞察是至關重要的。這時，你就需要有一套監控系統來監控錯誤發生在哪一層。如果沒有這個系統，那么勢必得花費幾倍的時間去查找問題出在哪里。
OpsClarity成功解決了這個問題，它可以自動發現數據管道和應用中的全部服務的拓撲結構，并用紅，綠，橙三種顏色來標記接口，能夠更加快速的對問題做出響應。
▲OpsClarity 的界面展示
如何配置Monitoring
Spark通過不同的端點為每個組件提供metric。例如，你想查看Spark Driver的詳細信息，你只需知道它的URL，Spark就可以自動訪問該URL。在Driver中有一個典型的問題，就是如何判斷哪些worker在工作并識別出它的UI端口。其實，我們可以把客戶端的Driver當做固定的URL端點。該軟件能夠自動找出應用程序中運行的Driver，然后收集每個端口的metric。
類似于Spark這樣的框架，集群是可以動態調整大小的。所以，必須確保新增的組件也可以自動配置監控。另外，在一個executor發生故障時，啟用另一個executor的情況下不應該出現警報。
檢查Spark應用程序。在Driver發生故障時，應用程序需要連接到別的application context和worker節點上仍然可以使用。在這種情況下，metric collection、port checks 和 monitor接口都需要移植到新的Driver上 。
拓撲監測和自動配置功能能夠實時監測Spark基礎設施發生的變化，無需人為干預。
原文鏈接：
https://dzone.com/articles/monitoring-apache-spark-why-is-it-challenging
京公網安備 11010502049343號