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》