這期內(nèi)容當中小編將會給大家?guī)碛嘘PELK 在 Spark集群的應用是怎樣的，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
創(chuàng)新互聯(lián)主要從事網(wǎng)站設計制作、網(wǎng)站建設、網(wǎng)頁設計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務。立足成都服務侯馬,十載網(wǎng)站建設經(jīng)驗,價格優(yōu)惠、服務專業(yè),歡迎來電咨詢建站服務:18982081108大數(shù)據(jù)處理技術越來越火,云計算平臺也如火如荼,二者猶如 IT 列車的兩個車輪,相輔相成,高速發(fā)展。如果我們將大數(shù)據(jù)處理平臺比作一個可能會得病的人的話，那么日志分析系統(tǒng)就是給病人診斷的醫(yī)生。由于集群甚大，幾百臺機器都是起步價，甚至可能會有上千臺、上萬臺機器同時協(xié)作運行。如此大的集群，不可能一點問題都不出,就像一個人不可能不得病一樣。如果出現(xiàn)問題，如何快速的找到問題的根源并對癥下藥，則顯得至關重要。在這樣的背景下，日志分析和監(jiān)控系統(tǒng)也猶如雨后春筍，得到了空前的發(fā)展。
目前，日志分析工具多達數(shù)十種，其中應用較多的有 Splunk、ELK、AWStats、Graphite、LogAnalyzer、Rsyslog、Log watch、Open Web Analytics 等等，其中，領頭羊的當屬 Splunk 和 ELK，其中 Splunk 屬于商業(yè)運營產(chǎn)品，而 ELK 屬于開源產(chǎn)品。本文著重討論 ELK 方案，并詳細闡述 ELK 如何應用到 Spark 集群中。事實上，ELK 官方已稱之為 Elastic,考慮行業(yè)內(nèi)對此系統(tǒng)已經(jīng)熟識，故而繼續(xù)延用 ELK 來代替。
ELK 的應用大致可以分為兩大類，一類是系統(tǒng)和應用的監(jiān)控,可以通過 Kibana 做出不同的 Dashboard 來實時的監(jiān)控集群的狀況，比如 CPU 利用率，內(nèi)存的使用情況，集群的 Job/Task 完成情況等；另一大用處在于快速的故障排查,運行中的集群在時時刻刻的打印日志，我們可以通過 ELK 系統(tǒng)來收集、存儲和檢索日志，然后通過關鍵字或者日志類型等查詢條件來快速的查看用戶感興趣的 Log,以便快速的找出問題的根源。
那么什么是 ELK 呢？ELK 是 Elasticsearch, Logstash, Kibana 的簡稱，是最初的 ELK 的三大核心套件，隨著該系統(tǒng)的發(fā)展，多出了另外一個組件，我們稱之為 Shipper 端，專門用來收集終端（集群中的機器）上日志和數(shù)據(jù)。其實 Logstash 本身就有收集功能，那么為什么還需要發(fā)展處另外一個 Shipper 端呢？主要是因為 Logstash 并非輕量級的工具，在運行過程中，占用了較多的資源（比如 CPU 和內(nèi)存等），對于集群的整體性能來說無疑是一種損耗。所以，一般在終端上只運行輕量級的 Shipper 來收集日志。起初的 shipper 為 Logstash-forwarder,后來發(fā)展到了 Beats。下面對這四種工具逐一做簡單介紹。
Logstash 是一個用來搜集，分析，過濾日志的工具。它支持幾乎任何類型的日志，包括系統(tǒng)日志、錯誤日志和自定義應用程序日志。它可以從許多來源接收日志，這些來源包括 syslog、消息傳遞（例如 rabbitmq）和 jmx，它能夠以多種方式輸出數(shù)據(jù)，包括電子郵件、websockets 和 Elasticsearch。
Elasticsearch 是實時全文搜索和分析引擎，提供搜集，分析，存儲數(shù)據(jù)三大功能；是一套開放 REST 和 JAVA API 等結構提供高效搜索功能，可擴展的分布式系統(tǒng)。它構建于 Apache Lucene 搜索引擎庫之上。
Kibana 是一個基于 Web 的圖形界面，用于搜索、分析和可視化存儲在 Elasticsearch 指標中的日志數(shù)據(jù)。它利用 Elasticsearch 的 REST 接口來檢索數(shù)據(jù)，不僅允許用戶創(chuàng)建他們自己的數(shù)據(jù)的定制儀表板視圖，還允許他們以特殊的方式查詢和過濾數(shù)據(jù)。
Beats 負責在終端收集日志和數(shù)據(jù)，目前 Beats 有好幾種，包括：Filebeat, Packetbeat, Metricbeat, Winlogbeat, Topbeat 等，用戶還可以借助 Libbeat 來開發(fā)自己的 Beat。Filebeat 功能相當于 Logstash-forwarder，用在收集文件日志。 Packetbeat 用來收據(jù)網(wǎng)絡方面的數(shù)據(jù)。Topbeat 已經(jīng)合并到 Metricbeat 里面，用來收集系統(tǒng)或者某個指定的服務所占用的 Metrics, Winlogbeat 用來收集 Windows 系統(tǒng)上的日志信息。目前，已經(jīng)有數(shù)十種 Community Beats，可供下載使用。
在不同的應用場景，ELK 系統(tǒng)的構架略有不同，比如說有的場景運用到了 Redis 或者 Kafka 來做消息隊列，以減輕 Logstash 的壓力，以防數(shù)據(jù)丟失。此文只討論最為經(jīng)典的構架。如圖 1 所示。
圖 1 ELK 的架構
在大數(shù)據(jù)處理部署過程中，HA 是很重要的一個環(huán)節(jié)。就 Elasticsearch 而言，其本身就具備 HA 能力。大體上講，HA 可以分為兩個，一種是主備模式（Active-standby）模式，另外一種是負載均衡（Load Balance）模式。二者的區(qū)別在在于，Active-standby 模式是主節(jié)點（主要干活的）垮了，備用節(jié)點才啟用，繼續(xù)接著主節(jié)點的進程去干活；Load Balance 模式是，大家一起上，誰空閑了或者誰的資源多了，就把活分給誰干。如果把這二者結合起來，達到雙璧合一的效果。作為 ELK 的集群監(jiān)控系統(tǒng)，最好的方式是采用二者的結合。其中 Elasticsearch 最好是采用 Load Balance 模式，在 Master node 上進行負載均衡。Logstash 當然也可以采用負載均衡的方式，但是由于前文中講過，Logstash 運行起來后，占用資源（CPU 利用率和內(nèi)存）比較厲害，所以，筆者建議，如果 Master 節(jié)點比較繁忙的話，不建議在所有 Master 上啟動 Logstash,當然在資源允許的情況下,啟動 Logstash 也可以使得整個 ELK 系統(tǒng)的處理速度變快。Kibana 當然無須全部啟動了，采用 Active-standby 模式，只需在一個管理節(jié)點上啟動即可。Beats 在所有節(jié)點上都啟動，因為要收集所有節(jié)點上的日志，但是需要注意的是，在 Spark 集群中，一般采用分布式文件系統(tǒng)的方式來存儲日志和數(shù)據(jù)的，故而要注意避免日志重復性的問題。
CPU 是系統(tǒng)中的首要資源，CPU 利用率的監(jiān)控的至關重要。CPU 利用率一般分為兩種，用戶態(tài) CPU 利用率（User CPU Usage）和系統(tǒng)態(tài) CPU 利用率(System CPU Usage)。其中用戶態(tài) CPU 利用率是指執(zhí)行應用程序代碼的時間占總 CPU 時間的百分比，系統(tǒng)態(tài) CPU 利用率是指應用執(zhí)行操作系統(tǒng)調(diào)用的時間占總 CPU 時間的百分比。
利用 ELK 監(jiān)控 Spark 集群中的 CPU 利用率的大致流程為：用 TopBeat 來收集各個節(jié)點的內(nèi)存資源，然后存儲到 Elasticsearch 當中，由 Kibana 展示出來。下圖為例，展示了 Spark 集群中的 CPU 監(jiān)控，同時也監(jiān)控了系統(tǒng)負載情況（Jin Chi He2016-11-04T09:36:00.18JCH System Load）。如果 Spark 集群中的節(jié)點可能較多，可以使用 Kibana 的功能，來展示出 CPU 利用率最高的幾個節(jié)點，以便了解哪些節(jié)點的負載較重。
圖 3 ELK 對 Spark 集群 CPU 的監(jiān)控
網(wǎng)絡吞吐量也會影響 Spark 集群的性能，網(wǎng)絡方面的參數(shù)主要有 Packetbeat 來收集，可以統(tǒng)計 Spark 集群中節(jié)點網(wǎng)卡的發(fā)送和收到的吞吐量，如下圖所示。
圖 5 ELK 對 Spark 集群網(wǎng)絡的監(jiān)控
以上，我們展示了對 Spark 集群性能的監(jiān)控幾個關鍵的指標，用戶還可能利用 Kibana 的靈活性來定義感興趣的 Dashboard。如果現(xiàn)有在 Beat 不能滿足需求，可以更具 libbeat 來開發(fā)自己的 Beat,或者寫一些簡單的腳本來收集，寫入文件，然后由 FileBeat 讀取，發(fā)送給 Logstash 進行格式的處理，或者由 Logstah 直接讀取。
在實際應用中，Spark 集群可能包括上百臺，甚至更多的節(jié)點，作為管理員，首先需要只要的是節(jié)點的分配情況和節(jié)點的狀態(tài)。如下圖所示，此數(shù)據(jù)一般來自于資源調(diào)度平臺，Spark 資源調(diào)度大體上可以分為兩大類，一類的自帶的資源調(diào)度模塊，另外一類是外部的資源調(diào)度框架，比如 Mesos、YARN 和 IBM Platform EGO 等。構建 Spark Application 的運行環(huán)境，創(chuàng)建 SparkContext 后， SparkContext 向資源管理器注冊并申請資源。如下圖中列舉出了 Spark 集群中，總的節(jié)點數(shù)和未分配的節(jié)點數(shù)，已經(jīng)失敗的節(jié)點數(shù)。此數(shù)據(jù)是 PERF Loader 從 IBM Platform EGO 模塊中加載到 Elasticsearch 數(shù)據(jù)庫中，然后在 Kibana 檢索展示。
圖 7 ELK 對 Spark 集群節(jié)點的監(jiān)控
在 EGO Cluster 模式下，通過 sbin/spark-submit 來提交 Application（一般為.jar 或者.py 文件），EGO 分配一個 Container 來啟動 Driver。Driver 一旦啟動后，將在 Cluster 中的 node 上啟動 Executor 的進程，并在此 Executor 上執(zhí)行 task。各種模式下，資源調(diào)度器的調(diào)度單位是不同的，圖 9 以 IBM Platform EGO 為例，展示資源的分配和使用情況。
圖 9 ELK 對資源分配情況的監(jiān)控
如果想更進一步的了解錯誤日志或者告警信息，可以在 Kibana 的 Discover tab 下，輸入相應的判斷條件，即可檢索出用戶感興趣的日志。
圖 11 Kibana 對日志的檢索
通常，日志被分散的儲存在不同的設備上。如果管理大規(guī)模的集群，還使用依次登錄每臺機器的傳統(tǒng)方法查閱日志，這樣會使得效率極其低下，而且工作繁瑣，集中化的日志管理就顯得越來越重要，ELK 無疑是目前最火的日志收集、處理、存儲、Web 展現(xiàn)為一身的技術，更有利者，ELK 是開源的。本章闡述了 ELK 的部署形式和使用案例。事實上，ELK 已經(jīng)應用到了各種場合，包括 Hadoop 集群的監(jiān)控，Spark 集群的監(jiān)控等。在平時的使用中，如果因為某種缺陷而無法達到用戶的需求，可以根據(jù) ELK 官方的方法，來開發(fā)自己的插件。
小編所展示的構架和展示圖為 IBM Platform 團隊在使用 ELK 系統(tǒng)過程中的實戰(zhàn)案例和總結，同時 IBM Platform 團隊來 ELK 系統(tǒng)做了很多改善和提升，比如和 IBM Platform EGO 集成，擴展 Beats 的收集范圍，監(jiān)控 IBM Spectrum Storage 系統(tǒng)，ELK 的自動部署和管理等方面。并且，默認情況下 ELK 系統(tǒng)不支持 IBM JAVA，為此，IBM Platform 團隊通過完善 ELK 系統(tǒng)，來完美的支持和 IBM JAVA 和 Power 系統(tǒng)，并將 ELK 產(chǎn)品應用到了 IBM Spectrum Conductor with Spark 和 IBM Spectrum Cluster Foundation 等產(chǎn)品中。
上述就是小編為大家分享的ELK 在 Spark集群的應用是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注創(chuàng)新互聯(lián)-成都網(wǎng)站建設公司行業(yè)資訊頻道。
重慶分公司
重慶分公司
