圈子裏關於大數據、雲計算相關文章和討論是越來越多，愈演愈烈。行業內企業也爭前恐後，羣雄逐鹿。而在大數據時代的運維挑站問題也就日漸突出，任重而道遠了。本文旨在針對複雜的大數據運維繫統推薦一把利器，達到拋磚引玉的效果，如果文中出現任何紕漏和錯誤的地方，懇請指正，歡迎討論，希望大家不吝賜教。
衆所周知，大數據平臺組件是很複雜的。筆者之前接觸的一個大數據平臺解決方案，僅平臺組件就達20多個，這還沒有加上物聯網系統各組件。而這龐大的系統整合問題，對於運維來說是很頭疼的。所以，在大數據時代下的運維問題是日漸尖銳。
有人把運維比作醫生給病人看病，那麼日誌則是病人對自己的陳述。所以只有在海量分佈式日誌系統中有效的提取關鍵信息，才能對症下藥。如果能把這些日誌集中管理，並提供全文檢索功能，不僅可以提高診斷的效率，同時可以起到實時系統監測、網絡安全、事件管理和發現bug等功能。基於此，本文向大家推薦一款開源利器——ELK組件（Apache 2.0 License），提供分佈式的實時日誌（數據）蒐集和分析的監控系統。
ELK多種架構及優劣
既然要談ELK在大數據運維繫統中的應用，那麼ELK架構就不得不談。本章節引出四種筆者曾經用過的ELK架構，並討論各種架構所適合的場景和優劣供大家參考。
先大致介紹ELK組件。ELK是Elasticsearch、Logstash、Kibana的簡稱，這三者是核心套件，但並非全部。後文的四種基本架構中將逐一介紹應用到的其它套件。
-
Elasticsearch是實時全文搜索和分析引擎，提供蒐集、分析、存儲數據三大功能；是一套開放REST和JAVA API等結構提供高效搜索功能，可擴展的分佈式系統。它構建於Apache Lucene搜索引擎庫之上。
-
Logstash是一個用來蒐集、分析、過濾日誌的工具。它支持幾乎任何類型的日誌，包括系統日誌、錯誤日誌和自定義應用程序日誌。它可以從許多來源接收日誌，這些來源包括 syslog、消息傳遞（例如 RabbitMQ）和JMX，它能夠以多種方式輸出數據，包括電子郵件、websockets和Elasticsearch。
-
Kibana是一個基於Web的圖形界面，用於搜索、分析和可視化存儲在 Elasticsearch指標中的日誌數據。它利用Elasticsearch的REST接口來檢索數據，不僅允許用戶創建他們自己的數據的定製儀表板視圖，還允許他們以特殊的方式查詢和過濾數據。
我們先談談第一種ELK架構，如圖1，這是最簡單的一種ELK架構方式。優點是搭建簡單，易於上手。缺點是Logstash耗資源較大，運行佔用CPU和內存高。另外沒有消息隊列緩存，存在數據丟失隱患。建議供學習者和小規模集羣使用。
此架構首先由Logstash分佈於各個節點上搜集相關日誌、數據，並經過分析、過濾後發送給遠端服務器上的Elasticsearch進行存儲。Elasticsearch將數據以分片的形式壓縮存儲並提供多種API供用戶查詢，操作。用戶亦可以更直觀的通過配置Kibana Web Portal方便的對日誌查詢，並根據數據生成報表（詳細過程和配置在此省略）。
第二種架構（圖2）引入了消息隊列機制，位於各個節點上的Logstash Agent先將數據/日誌傳遞給Kafka（或者Redis），並將隊列中消息或數據間接傳遞給Logstash，Logstash過濾、分析後將數據傳遞給Elasticsearch存儲。最後由Kibana將日誌和數據呈現給用戶。因爲引入了Kafka（或者Redis）,所以即使遠端Logstash server因故障停止運行，數據將會先被存儲下來，從而避免數據丟失。
這種架構適合於較大集羣的解決方案，但由於Logstash中心節點和Elasticsearch的負荷會比較重，可將他們配置爲集羣模式，以分擔負荷，這種架構的優點在於引入了消息隊列機制，均衡了網絡傳輸，從而降低了網絡閉塞尤其是丟失數據的可能性，但依然存在Logstash佔用系統資源過多的問題。
第三種架構（圖3）引入了Logstash-forwarder。首先，Logstash-forwarder將日誌數據蒐集並統一發送給主節點上的Logstash，Logstash分析、過濾日誌數據後發送至Elasticsearch存儲，並由Kibana最終將數據呈現給用戶。
這種架構解決了Logstash在各計算機點上佔用系統資源較高的問題。經測試得出，相比Logstash，Logstash-forwarder所佔用系統CPU和MEM幾乎可以忽略不計。另外，Logstash-forwarder和Logstash間的通信是通過SSL加密傳輸，起到了安全保障。如果是較大集羣，用戶亦可以如結構三那樣配置logstash集羣和Elasticsearch集羣，引入High Available機制，提高數據傳輸和存儲安全。更主要的配置多個Elasticsearch服務，有助於搜索和數據存儲效率。但在此種架構下發現Logstash-forwarder和Logstash間通信必須由SSL加密傳輸，這樣便有了一定的限制性。
第四種架構（圖4），將Logstash-forwarder替換爲Beats。經測試，Beats滿負荷狀態所耗系統資源和Logstash-forwarder相當，但其擴展性和靈活性有很大提高。Beats platform目前包含有Packagebeat、Topbeat和Filebeat三個產品，均爲Apache 2.0 License。同時用戶可根據需要進行二次開發。
這種架構原理基於第三種架構，但是更靈活，擴展性更強。同時可配置Logstash 和Elasticsearch 集羣用於支持大集羣系統的運維日誌數據監控和查詢。
不管採用上面哪種ELK架構，都包含了其核心組件，即：Logstash、Elasticsearch 和Kibana。當然這三個組件並非不能被替換，只是就性能和功能性而言，這三個組件已經配合的很完美，是密不可分的。各系統運維中究竟該採用哪種架構，可根據現實情況和架構優劣而定。
ELK在大數據運維繫統中的應用
在海量日誌系統的運維中，以下幾個方面是必不可少的：
-
分佈式日誌數據集中式查詢和管理
-
系統監控，包含系統硬件和應用各個組件的監控
-
故障排查
-
安全信息和事件管理
-
報表功能
ELK組件各個功能模塊如圖5所示，它運行於分佈式系統之上，通過蒐集、過濾、傳輸、儲存，對海量系統和組件日誌進行集中管理和準實時搜索、分析，使用搜索、監控、事件消息和報表等簡單易用的功能，幫助運維人員進行線上業務的準實時監控、業務異常時及時定位原因、排除故障、程序研發時跟蹤分析Bug、業務趨勢分析、安全與合規審計，深度挖掘日誌的大數據價值。同時Elasticsearch提供多種API（REST JAVA PYTHON等API）供用戶擴展開發，以滿足其不同需求。
彙總ELK組件在大數據運維繫統中，主要可解決的問題如下：
-
日誌查詢，問題排查，上線檢查
-
服務器監控，應用監控，錯誤報警，Bug管理
-
性能分析，用戶行爲分析，安全漏洞分析，時間管理
綜上，ELK組件在大數據運維中的應用是一套必不可少的且方便、易用的開源解決方案。
ELK實戰舉例
ELK實戰舉例一，通過ELK組件對Spark作業運行狀態監控，蒐集Spark環境下運行的日誌。經過篩選、過濾並存儲可用信息，從而完成對Spark作業運行和完成狀態進行監控，實時掌握集羣狀態，瞭解作業完成情況，並生成報表，方便運維人員監控和查看。
數據來源可以是各式各樣的日誌，Logstash配置文件有三個主要模塊：input()輸入或者說收集數據，定義數據來源；filter()對數據進行過濾，分析等操作；output()輸出。input plugin目前支持將近50種，如下表所示：
| Beats | couchdb_changes | Xmpp | eventlog | exec | s3 | file | ganglia | gelf |
|---|---|---|---|---|---|---|---|---|
| Github | Heartbeat | Heroku | http | Sqs | Irc | imap | jdbc | JMX |
| lumberjack | varnishlog | Pipe | snmptrap | generator | Rss | rackspace | RabbitMQ | Redis |
| Sqlite | Elasticsearch | http_poller | Stomp | syslog | TCP | unix | UDP | |
| websocket | drupal_dblog | Zenoss | ZeroMQ | Graphite | Log4j | stdin | wmi | relp |
| Kafka | puppet_facter | Meetup |
數據源蒐集到後，然後通過filter過濾形成固定的數據格式。目前支持過濾的類JSON、grep、grok、geoip等,最後output到數據庫，比如Redis、Kafka或者直接傳送給Elasticsearch。當數據被存儲於Elasticsearch之後，用戶可以使用Elasticsearch所提供API來檢索信息數據了，如通過REST API執行CURL GET請求搜索指定數據。用戶也可以使用Kibana進行可視化的數據瀏覽。另外Kibana有時間過濾功能，運維人員可對某一時間段內數據查詢並查看報表，方便快捷。
ELK實戰舉例二，通過ELK組件對系統資源狀態監控，如圖7、圖8所示，是筆者前段時間使用ELK組件爲集羣提供日誌查詢和系統資源監控的例子。通過各類日誌蒐集，分析，過濾，存儲並通過Kibana展現給用戶，供用戶實時監控系統資源、節點狀態、磁盤、CPU、MEM，以及錯誤、警告信息等。
ELK實戰舉例三，通過ELK組件對系統負載狀態監控，如圖9所示。
ELK實戰舉例四，通過ELK組件對系統日誌管理和故障排查，如圖10所示。用戶可根據故障發生時間段集中查詢相關日誌，可通過搜索、篩選、過濾等功能，快速定位問題，從而排查故障。另外，通過對各個應用組件的日誌過濾，可快速列舉出各個應用對應節點上的Error或Warning日誌，從而對故障排查或者對發現產品bug提供快捷途徑。
結束語
除ELK套件以外，業界關於運維監控產品還有很多，如Splunk、Nagios等。
Splunk是在語句裏生成圖表。而ELK則是用戶在Kibana Web Portal上鼠標選擇的方式來點出來，相比Splunk來說要簡單得多，用戶不用記住那些語法即可繪製多種Chart。易用性有很大提高。另外，Splunk屬於入庫後對內容的即使處理，比如rex函數等等，而ES是儘量在入庫前，即在Logstash端已經將數據源實時過濾、分析。提高了數據處理能力。最重要一點，ELK是免費的，Splunk則需要昂貴的費用。
Nagios最大的特點是其強大的管理中心，但看不到歷史數據，很難追查故障原因，而且配置複雜，這些恰恰是ELK組件的優勢所在。
本文所述案例和架構來自於IBM Platform團隊在使用ELK套件中的實戰經歷和工作總結，IBM Platform衝出了ELK套件僅對日誌蒐集的約束，除Logstash所支持input plugin外，還充分利用了Elasticsearch本身所支持多種數據源輸入，從而增強了數據源的輸入條件，提高了系統監控範圍，大大提高了ELK的擴展性和實用性。
ELK本身對POWER系統，還有IBM JAVA支持有一定侷限性，不過IBM Platform團隊已經將這些問題一一解決，使之可以完美地集成於多個平臺。除此之外，IBM Platform將ELK和IBM Platform Cluster Manager、IBM Platform EGO集成於一體。用於ELK自動部署和管理，有效提高了ELK的部署和管理效率。並對IBM Platform Converge、IBM Platform Conductor（包括Spark）提供監控和Dashboard等功能。
作者簡介
李峯，供職於IBM Platform 多年，從事分佈式計算、高性能計算、大數據相關工作，傾向於日誌分析、數據監控等研究。
王佔偉，資深研發工程師，供職於IBM多年，專注於大數據、雲計算、高性能計算等平臺的日誌分析、數據監控等方面的研發工作。
何金池，畢業於西安郵電大學，目前供職於IBM，工作方向爲大數據日誌處理、高性能計算等領域。
李婷，研發工程師，供職於IBM Platform，從事分佈式計算、高性能計算、大數據相關工作，對前端開發有較深研究。
