ELK初步指南

ELK的簡單科普文章，加入了本身的一些理解。 內容包括ELK的基本介紹， 應用場景， 架構設計， 監控及自監控， 業界進展及推薦資料等。

用戶故事

場景一

做爲一個運維工程師， 某天虛擬機出現故障， 想看看虛擬機是否有異常日誌，物理機上是否有異常日誌， 管理物理機的雲平臺／系統是否有發生異常日誌， 一個個主機 系統登錄過去， 輸入帳號密碼費時費力，有時還會出現記不住密碼乾着急的狀況，大大影響了排障的效率。 有沒有一個系統，可以集中查看和搜索日誌，不須要繁瑣的登錄， 方便的獲取排障所需的重要信息， 有異常還可以訂閱？

場景二

做爲一個開發人員， 開發的系統常常須要調用外部的api， 每次出現問題須要去查看日誌，看是哪一個環節出現問題， 是調用第三方api出錯，仍是鏈接數據庫出錯，只能一個一個查。 另外還會遇到的問題是， 有時候無心中grep了一個大的文件，致使iowait衝高，引起沒必要要的系統異常告警。 有沒有一個工具可以提供各類儀表盤，每次打開一個頁面就能一目瞭然的看到調用各個api的狀況，調用了多少次， 失敗了多少次？

場景三

開發人員上線新版本，上線過程當中可能會出現各類問題。 有時不能及時發現會引發哪些異常，對其它系統有哪些影響。有沒有一個工具 能夠看到和分析上線新版本先後的變化？這樣 就能有助於分析相應的故障是不是和上線新版本有關了。

場景四

做爲一個團隊領導， 團隊開發產品已經上線一段時間了， 但願看到產品有多少人訪問， 哪一個功能訪問了多少次，模塊的出錯率如何，每次都到機器上去跑分析腳本，費時費力，還不直觀， 若是產品部署在分佈式集羣統計起來更是麻煩， 有沒有一個系統能以更加簡便的方式能夠查看到這些狀況？

上述的問題，ELK通通能夠解決。

ELK是什麼鬼?

簡而言之， 若是說日誌是埋在土裏的寶藏，那麼ELK是開採寶藏的藍翔挖掘機。

概述

ELK是一套解決方案而不是一款軟件， 三個字母分別是三個軟件產品的縮寫。 E表明Elasticsearch,負責日誌的存儲和檢索； L表明Logstash, 負責日誌的收集，過濾和格式化；K表明Kibana，負責日誌的展現統計和數據可視化。

其中Elasticsearch是整個ELK的核心， L和K都有相應的替代方案。 這裏重點介紹下ElasticSearch（下面簡稱es）的一些知識。

相關架構概念

上面是一個1個node， 2個replica， 3個shard的結構
cluster（集羣）由多個node（節點）組成
數據會被索引，並保存在index裏（類比RDBMS裏的DB)
一個index能夠切成多個shard（分片），每一個shard能夠有多個replica（副本）
node分爲三種類型， 分別是master node，data node ，client node。 每一個cluster會有一個node被選舉成master，負責維護cluster state data。
shard均勻分佈在全部可用的data node
ES 和 關係型數據庫的概念比較

ES自己能夠理解爲自帶搜索引擎的數據庫。 有些概念能夠和關係型數據庫（好比說MySQL） 進行對比。 概念的對好比下表所示：

ELK vs Linux Grep

ELK能作什麼?

應用場景

安全領域
經過分析系統日誌， 發現攻擊或者非法訪問行爲，能夠追蹤定位相關安全問題。 好比結合FreeIPA(一款集成的安全信息管理解決方案)， 能夠作一些暴力破解行爲可視化分析等。

網絡領域
日誌分析和監控能夠做爲網絡設備監控的一種補充， 其它監控系統，如zabbix大可能是經過snmp的方式來獲取網絡設備的性能數據， 這種方式有其侷限性，如沒法監控端口的flapping， 沒法監測到設備引擎掛掉等狀況。 此外因爲snmp監控的方案通用型很差， 各個廠商有本身的私有OID, 意味着須要對這些不一樣的廠商適配不一樣的監控模板。 另外， snmp獲取數據的實時性相對會比syslog日誌慢一些。

應用領域
分析和展現移動端業務的實時狀況，如設備類型分析， 業務訪問量， 業務訪問高峯狀況等；分析nginx日誌獲得網站的訪問狀況，如網站點擊數， api請求總數、平均每秒請求數、峯值請求數，能夠大致瞭解系統壓力，做爲系統擴容、性能及壓力測試時的直接參考。

另類應用
用於社會工程學的用戶畫像；函數堆棧調用分析；網絡流量分析

ELK落地方案

架構選型

下面是一種常見的ELK架構

這個架構的優勢是簡單，維護起來也方便。 可是也有一些問題。

shipper耗主機資源。 直接用logstash看成日誌採集的agent， 會比較重，會佔用很多主機資源， 所以官方如今已經不推薦用logstash當shipper了， 推薦使用beat。
權限控制的問題。 kbana自身對頁面訪問權限控制這塊是比較弱。 若是但願對頁面的訪問權限作控制， 能夠考慮使用es search guard + ldap + nginx的方案來實現。
跨網絡分區的問題 。若是有多個數據中心，且日誌的流量比較大， 讓日誌跨網絡分區進行傳輸，無疑會佔用很多寶貴的專線帶寬資源，會增長運營的成本，且有可能影響到其它應用的正常運行。 有一個解決此類問題的方案， 在各個網絡分區各搭建一套ELK集羣，日誌不跨網絡分區進行傳輸， 而後單獨使用某些es節點做爲tribe角色， 對搜索請求進行合併和路由。
爲解決上面提到的問題， 設計瞭如下架構：

固然， 上面的架構也不是一層不變。若是日誌量更大，能夠考慮使用hangout來代替logstash， 用kafka來替代redis， 從而得到更大的日誌吞吐量。

監控告警

日誌的告警

能夠採用elastalert。 固然也能夠本身開發應用從es或者kafka取數據來作分析。

自身的監控

使用zabbix 監控。 網上能夠找到對應的模版。
使用官方提供的marvel方案， 不過是收費的。
使用open falcon監控。 咱們內部有一套open falcon系統， 因此咱們嘗試用open falcon來監控es集羣。
挑戰和思路

SaaS化

就是把ELK提供爲SaaS服務，目前新浪雲， 青雲， aws等雲平臺上面已經有相應的服務了。 把日誌分析系統SaaS化， 能夠免去用戶搭建和維護elk集羣的麻煩，減小用戶的使用成本，同時也能夠給雲平臺自身帶來更多的附加值。

大數據分析

用ELK堆棧來存儲和索引海量的日誌數據， 後面再結合大數據分析和機器學習工具，能夠作智能運維分析， 減小運維人員之苦。

推薦資料

《Elasticsearch 權威指南》 《ELK中文指南》 《Mastering ElasticSearch》 《Manning Elasticsearch in Action》