ELK 在 Spark集群的應用是怎樣的

這期內容當中小編將會給大家帶來有關ELK 在 Spark集群的應用是怎樣的，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

概述

大數據處理技術越來越火,云計算平臺也如火如荼,二者猶如 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 的架構

在大數據處理部署過程中，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 的監控

3、網絡的監控

網絡吞吐量也會影響 Spark 集群的性能，網絡方面的參數主要有 Packetbeat 來收集，可以統計 Spark 集群中節點網卡的發送和收到的吞吐量，如下圖所示。

圖 5 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 集群節點的監控

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

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

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

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

圖 11 Kibana 對日志的檢索<img src="https://cache.yisu.com/upload/information/20200706/149/73588.png" class="ibm-downsize"  height="220" width="553" font-size:14px;white-space:normal;background-color:#FFFFFF;height:auto !important;" />

通常，日志被分散的儲存在不同的設備上。如果管理大規模的集群，還使用依次登錄每臺機器的傳統方法查閱日志，這樣會使得效率極其低下，而且工作繁瑣，集中化的日志管理就顯得越來越重要，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 等產品中。

上述就是小編為大家分享的ELK 在 Spark集群的應用是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。