ELK 在 Spark 叢集的應用

http://www.dajiangtai.com/community/18154.do?origin=csdn-geek&dt-1226 
http://www.ibm.com/developerworks/cn/analytics/library/ba-cn-elk-spark/index.html?ca=drs

概述

大資料處理技術越來越火,雲端計算平臺也如火如荼,二者猶如 IT 列車的兩個車輪,相輔相成,高速發展。如果我們將大資料處理平臺比作一個可能會得病的人的話，那麼日誌分析系統就是給病人診斷的醫生。由於叢集甚大，幾百臺機器都是起步價，甚至可能會有上千臺、上萬臺機器同時協作執行。如此大的叢集，不可能一點問題都不出,就像一個人不可能不得病一樣。如果出現問題，如何快速的找到問題的根源並對症下藥，則顯得至關重要。在這樣的背景下，日誌分析和監控系統也猶如雨後春筍，得到了空前的發展。

目前，日誌分析工具多達數十種，其中應用較多的有 Splunk、ELK、AWStats、Graphite、LogAnalyzer、Rsyslog、Log watch、Open Web Analytics 等等，其中，領頭羊的當屬 Splunk 和 ELK，其中 Splunk 屬於商業運營產品，而 ELK 屬於開源產品。本文著重討論 ELK 方案，並詳細闡述 ELK 如何應用到 Spark 叢集中。事實上，ELK 官方已稱之為 Elastic,考慮行業內對此係統已經熟識，故而繼續延用 ELK 來代替。

ELK 的應用大致可以分為兩大類，一類是系統和應用的監控,可以通過 Kibana 做出不同的 Dashboard 來實時的監控叢集的狀況，比如 CPU 利用率，記憶體的使用情況，叢集的 Job/Task 完成情況等；另一大用處在於快速的故障排查,執行中的叢集在時時刻刻的列印日誌，我們可以通過 ELK 系統來收集、儲存和檢索日誌，然後通過關鍵字或者日誌型別等查詢條件來快速的檢視使用者感興趣的 Log,以便快速的找出問題的根源。

一、ELK 系統架構

那麼什麼是 ELK 呢？ELK 是 Elasticsearch, Logstash, Kibana 的簡稱，是最初的 ELK 的三大核心套件，隨著該系統的發展，多出了另外一個元件，我們稱之為 Shipper 端，專門用來收集終端（叢集中的機器）上日誌和資料。其實 Logstash 本身就有收集功能，那麼為什麼還需要發展處另外一個 Shipper 端呢？主要是因為 Logstash 並非輕量級的工具，在執行過程中，佔用了較多的資源（比如 CPU 和記憶體等），對於叢集的整體效能來說無疑是一種損耗。所以，一般在終端上只執行輕量級的 Shipper 來收集日誌。起初的 shipper 為 Logstash-forwarder,後來發展到了 Beats。下面對這四種工具逐一做簡單介紹。

Logstash 是一個用來蒐集，分析，過濾日誌的工具。它支援幾乎任何型別的日誌，包括系統日誌、錯誤日誌和自定義應用程式日誌。它可以從許多來源接收日誌，這些來源包括 syslog、訊息傳遞（例如 rabbitmq）和 jmx，它能夠以多種方式輸出資料，包括電子郵件、websockets 和 Elasticsearch。

Elasticsearch 是實時全文搜尋和分析引擎，提供蒐集，分析，儲存資料三大功能；是一套開放 REST 和 JAVA API 等結構提供高效搜尋功能，可擴充套件的分散式系統。它構建於 Apache Lucene 搜尋引擎庫之上。

Kibana 是一個基於 Web 的圖形介面，用於搜尋、分析和視覺化儲存在 Elasticsearch 指標中的日誌資料。它利用 Elasticsearch 的 REST 介面來檢索資料，不僅允許使用者建立他們自己的資料的定製儀表板檢視，還允許他們以特殊的方式查詢和過濾資料。

Beats 負責在終端收集日誌和資料，目前 Beats 有好幾種，包括：Filebeat, Packetbeat, Metricbeat, Winlogbeat, Topbeat 等，使用者還可以藉助 Libbeat 來開發自己的 Beat。Filebeat 功能相當於 Logstash-forwarder，用在收集檔案日誌。 Packetbeat 用來收據網路方面的資料。Topbeat 已經合併到 Metricbeat 裡面，用來收集系統或者某個指定的服務所佔用的 Metrics, Winlogbeat 用來收集 Windows 系統上的日誌資訊。目前，已經有數十種 Community Beats，可供下載使用。

在不同的應用場景，ELK 系統的構架略有不同，比如說有的場景運用到了 Redis 或者 Kafka 來做訊息佇列，以減輕 Logstash 的壓力，以防資料丟失。此文只討論最為經典的構架。如圖 1 所示。

圖 1 ELK 的架構

其大致工作流程為：Beats 從終端機器收集到各種資料之後，傳送給 Logstash 進行解析和格式化處理之後，再插入到 Elasticsearch 中儲存，然後通過 Kibana 展示給使用者。從上圖中，我們可以看出，Beats 也可以直接將資料傳送給 Elasticsearch，省略掉 Logstash 環節（假如所收集的資料不需要進一步的解析處理的話）。當然，在一般情況下，都需要用 Logstash 對資料進行解析加工，方便於 Kibana 圖形化的展示。

二、ELK 在 Spark 叢集中高可用性構架

為了便於分析，我們將 Spark 叢集分為管理節點（Master Node）和計算節點（Slave Node）。管理節點（Master Node）可能有多個節點，分別安裝 Beat,Logstash, Elasticsearch 和 Kibana。計算節點上，只需要安裝 Beats 來收集日誌即可。下圖是 ELK 在 Spark 叢集中 HA 構架。

圖 2 ELK 在 Spark 叢集中 HA 構架

在大資料處理部署過程中，HA 是很重要的一個環節。就 Elasticsearch 而言，其本身就具備 HA 能力。大體上講，HA 可以分為兩個，一種是主備模式（Active-standby）模式，另外一種是負載均衡（Load Balance）模式。二者的區別在在於，Active-standby 模式是主節點（主要幹活的）垮了，備用節點才啟用，繼續接著主節點的程式去幹活；Load Balance 模式是，大家一起上，誰空閒了或者誰的資源多了，就把活分給誰幹。如果把這二者結合起來，達到雙璧合一的效果。作為 ELK 的叢集監控系統，最好的方式是採用二者的結合。其中 Elasticsearch 最好是採用 Load Balance 模式，在 Master node 上進行負載均衡。Logstash 當然也可以採用負載均衡的方式，但是由於前文中講過，Logstash 執行起來後，佔用資源（CPU 利用率和記憶體）比較厲害，所以，筆者建議，如果 Master 節點比較繁忙的話，不建議在所有 Master 上啟動 Logstash,當然在資源允許的情況下,啟動 Logstash 也可以使得整個 ELK 系統的處理速度變快。Kibana 當然無須全部啟動了，採用 Active-standby 模式，只需在一個管理節點上啟動即可。Beats 在所有節點上都啟動，因為要收集所有節點上的日誌，但是需要注意的是，在 Spark 叢集中，一般採用分散式檔案系統的方式來儲存日誌和資料的，故而要注意避免日誌重複性的問題。

三、ELK 監控 Spark 叢集的效能

1、CPU 利用率的監控

CPU 是系統中的首要資源，CPU 利用率的監控的至關重要。CPU 利用率一般分為兩種，使用者態 CPU 利用率（User CPU Usage）和系統態 CPU 利用率(System CPU Usage)。其中使用者態 CPU 利用率是指執行應用程式程式碼的時間佔總 CPU 時間的百分比，系統態 CPU 利用率是指應用執行作業系統呼叫的時間佔總 CPU 時間的百分比。

利用 ELK 監控 Spark 叢集中的 CPU 利用率的大致流程為：用 TopBeat 來收集各個節點的記憶體資源，然後儲存到 Elasticsearch 當中，由 Kibana 展示出來。下圖為例，展示了 Spark 叢集中的 CPU 監控，同時也監控了系統負載情況（Jin Chi He2016-11-04T09:36:00.18JCH System Load）。如果 Spark 叢集中的節點可能較多，可以使用 Kibana 的功能，來展示出 CPU 利用率最高的幾個節點，以便了解哪些節點的負載較重。

圖 3 ELK 對 Spark 叢集 CPU 的監控

2、記憶體利用率的監控

我們知道，Spark 是一種記憶體利用率非常高的技術，換句話說，Spark 叢集對記憶體的要求較高。Spark 叢集的管理者需要實時的掌握記憶體的使用情況。收集方式和 CPU 利用率的方式類似，用 Topbeat 或者 Metricbeat 來收集。一般來統計總的記憶體，已經使用和記憶體和平均的記憶體利用率。如下圖所示。

圖 4 ELK 對 Spark 叢集記憶體的監控

3、網路的監控

網路吞吐量也會影響 Spark 叢集的效能，網路方面的引數主要有 Packetbeat 來收集，可以統計 Spark 叢集中節點網路卡的傳送和收到的吞吐量，如下圖所示。

圖 5 ELK 對 Spark 叢集網路的監控

4、磁碟的監控

磁碟的監控只要分為兩個方面，一是的磁碟的使用率，以便監控而防止因磁碟不夠而影響應用的執行。二是磁碟的 IO 吞吐量，吞吐量是指每秒傳輸的 MB 位元組數來衡量，常用於衡量 OLAP 型資料塊的 IO 效能。如下圖所示。

圖 6 ELK 對 Spark 叢集磁碟的監控

以上，我們展示了對 Spark 叢集效能的監控幾個關鍵的指標，使用者還可能利用 Kibana 的靈活性來定義感興趣的 Dashboard。如果現有在 Beat 不能滿足需求，可以更具 libbeat 來開發自己的 Beat,或者寫一些簡單的指令碼來收集，寫入檔案，然後由 FileBeat 讀取，傳送給 Logstash 進行格式的處理，或者由 Logstah 直接讀取。

四、ELK 監控 Spark 叢集的作業

1、對節點的監控

在實際應用中，Spark 叢集可能包括上百臺，甚至更多的節點，作為管理員，首先需要只要的是節點的分配情況和節點的狀態。如下圖所示，此資料一般來自於資源排程平臺，Spark 資源排程大體上可以分為兩大類，一類的自帶的資源排程模組，另外一類是外部的資源排程框架，比如 Mesos、YARN 和 IBM Platform EGO 等。構建 Spark Application 的執行環境，建立 SparkContext 後， SparkContext 向資源管理器註冊並申請資源。如下圖中列舉出了 Spark 叢集中，總的節點數和未分配的節點數，已經失敗的節點數。此資料是 PERF Loader 從 IBM Platform EGO 模組中載入到 Elasticsearch 資料庫中，然後在 Kibana 檢索展示。

圖 7 ELK 對 Spark 叢集節點的監控

2、對 Task 執行情況的監控

在 Spark 叢集中，資源管理器根據預先設定的演算法，在資源池裡面分配合適的 Executor 執行資源，在執行過程中，Executor 執行情況將隨著心跳傳送到資源管理器上。SparkContext 構建 DAG 圖，作業排程模組 DAGScheduler 將 DAG 圖分解成 Stage。Executor 向 SparkContext 申請 Task，TaskScheduler 維護著所有 TaskSet，當 Driver 收到 Executor 的心跳的時候，Task Scheduler 會根據其資源剩餘情況分配相應的 Task 到 Executor 執行，同時 SparkContext 將應用程式程式碼發放給 worker。隨後 Task 便開始 worker 上開始執行。在此期間，TaskScheduler 還維護著所有 Task 的執行狀態，重試失敗的 Task。當 Task 執行結束，反饋給 SparkContext，並釋放資源。

在 Application 提交之後，監控 Task 執行狀態，可以得知 Application 的完成情況，下圖中，展示了正在執行的 Task 數量和已經完成的 Task 數量，以及各個節點完成 Task 的數量。此資料獲取的方式比較靈活，可以通過 RESTful API 直接獲取，或者配置 Spark 叢集中的 log4j，將這些資訊列印到日誌中，由 Logstash 來收集。

圖 8 ELK 對 Task 的監控

3、對資源分配情況的監控

在 EGO Cluster 模式下，通過 sbin/spark-submit 來提交 Application（一般為.jar 或者.py 檔案），EGO 分配一個 Container 來啟動 Driver。Driver 一旦啟動後，將在 Cluster 中的 node 上啟動 Executor 的程式，並在此 Executor 上執行 task。各種模式下，資源排程器的排程單位是不同的，圖 9 以 IBM Platform EGO 為例，展示資源的分配和使用情況。

圖 9 ELK 對資源分配情況的監控

4、對錯誤和告警的監控

在對日誌的收集過程中，根據 LOG LEVEL 的不同，可以將 ERROR 或者 WARN 的日誌分離出來，直觀的展示到 Dashboard 中，如圖 10 所示。

圖 10 ELK 對錯誤和告警的監控

如果想更進一步的瞭解錯誤日誌或者告警資訊，可以在 Kibana 的 Discover tab 下，輸入相應的判斷條件，即可檢索出使用者感興趣的日誌。

圖 11 Kibana 對日誌的檢索

五、結束語

通常，日誌被分散的儲存在不同的裝置上。如果管理大規模的叢集，還使用依次登入每臺機器的傳統方法查閱日誌，這樣會使得效率極其低下，而且工作繁瑣，集中化的日誌管理就顯得越來越重要，ELK 無疑是目前最火的日誌收集、處理、儲存、Web 展現為一身的技術，更有利者，ELK 是開源的。本章闡述了 ELK 的部署形式和使用案例。事實上，ELK 已經應用到了各種場合，包括 Hadoop 叢集的監控，Spark 叢集的監控等。在平時的使用中，如果因為某種缺陷而無法達到使用者的需求，可以根據 ELK 官方的方法，來開發自己的外掛。

本文所展示的構架和展示圖為 IBM Platform 團隊在使用 ELK 系統過程中的實戰案例和總結，同時 IBM Platform 團隊來 ELK 系統做了很多改善和提升，比如和 IBM Platform EGO 整合，擴充套件 Beats 的收集範圍，監控 IBM Spectrum Storage 系統，ELK 的自動部署和管理等方面。並且，預設情況下 ELK 系統不支援 IBM JAVA，為此，IBM Platform 團隊通過完善 ELK 系統，來完美的支援和 IBM JAVA 和 Power 系統，並將 ELK 產品應用到了 IBM Spectrum Conductor with Spark 和 IBM Spectrum Cluster Foundation 等產品中。

作者：何金池, 李 峰, 王 佔偉, 和 李 婷

來源：http://www.ibm.com/developerworks/cn/analytics/library/ba-cn-elk-spark/index.html?ca=drs

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14710393/viewspace-2132285/，如需轉載，請註明出處，否則將追究法律責任。