攜程ELK日志分析平臺深耕之路
來自： http://techshow.ctrip.com/archives/1042.html
源起
日志，看似簡單簡單的文本，在網站運維人員眼里卻似一座蘊含豐富的寶藏。通常以下運維任務都或多或少需要運維人員和日志打交道:
? 系統健康狀況監控
? 查找故障根源
? 系統瓶頸診斷和調優
? 追蹤安全相關問題
技能熟練的Linux SA們能夠很快的組合諸如grep, awk這樣的命令，奇幻般的從日志中挖掘出有用的信息；亦或是研發人員往往會基于MySQL,MongoDB,HBase開發自己的日志存儲和分析工具。
然而互聯網大規模、分布式的特性決定了日志的源頭越來越分散，產生的速度越來越快，傳統的手段和工具顯得日益力不從心。市場對新工具的需求已然催生出Splunk這樣近百億美元市值的專業日志分析解決方案供應商。
從2013年攜程網站運營中心成立伊始，集中化的運維日志分析平臺就被提上議事日程。作為中國最大的OTA網站，攜程基礎設施每日產生的各類日志有好幾十種，量級在數個TB級別，如果采用Splunk這樣的商業軟件，每年的授權費用就要近千萬。昂貴的授權費用驅使我們深入研究這個領域，尋求商業軟件以外的替代方案。
小試牛刀
一線運維部門對于日志分析工具有如下幾個重要的期盼點:
1. 日志要支持多種數據源
2. 日志解析方式靈活但簡單
3. 支持關鍵詞搜索和瀏覽，能支持組合條件搜索
4. 能夠按照時間窗對特定字段做數值統計，并且時間窗最好可以隨意縮放，比如計算某個時間段的平均響應時間，或者出現某種錯誤類型最多的URL等等。
當時公司已有基于MySQL和HBase的日志分析工具，然而功能與用戶期望相差甚遠。我們對這些工具的感覺是：可以很好的存，卻無法很好的用。具體說就是日志寫到數據庫問題不大，但一旦要用的時候，只能做類似tail的翻看，或者簡單的過濾；一旦有復雜的查詢和統計會非常非常慢，或者根本無法支持，用戶體驗比較差。
腦子里不停翻滾著用戶需求，持續探尋了幾天后，ELK進入了我們的視野。ELK是三個開源工具ElasticSearch，Logstash，Kibana組合而成的軟件棧，其中的核心是開源的分布式搜索引擎Elasticsearch，輔以Logstash靈活多樣的日志收集，過濾，傳送功能以及Kibana炫酷的前端展示面板，組合成一套可以媲美商業應用的解決方案。
下面是個典型的ELK架構方案；
看起來很簡單，logstash像一把瑞士軍刀，可以通過plugin的方式從多種渠道輸入日志、內部深加工（filter），再輸出到多種類型的目的地，這里我們送到Elasticsearch做索引和存儲。 中間的Redis用作消息隊列，使得架構的容錯性更高，當ES故障或者下線維護的時候，日志可以緩存一段時間而不至于丟失。
我們團隊經過短暫的測試環境POC以后，在線上部署了一個5臺服務器規模的小集群。 無線日志和云計算部門的VDI日志成了我們一批小白鼠，數據在Kibana里的可視化直觀易讀。
如下是一個Openstack日志的分析示例面板:
Elasticsearch是基于Lucene的，對于日志的所有字段都可以索引，并且其倒排索引的數據結構非常緊湊，搜索效率非常的高。Elasticsearch的Facet (aggregation)模塊可以對數據做分布式的聚合計算，速度驚人的快。反映到前端Kibana上，用戶可以隨意組合條件過濾日志，隨意伸統計時間窗，秒級獲取聚合計算結果。再也不需要在Hadoop上長久的等待，也不用為更改Storm/Spark定好的計算維度而犯愁，非凡的用戶體驗一下抓住了用戶的心，更多的日志接入需求隨之而來。
持續學習、實踐與優化
開源軟件并非沒有成本，如果無法理解其核心原理，無法將其駕馭往往會導致項目的失敗。隨著接入的日志量級增加，集群規模擴大，我們開始遇到各種詭異的穩定性和性能問題。一個系統再好，不穩定、慢，用戶就會慢慢喪失信心和興趣。這促使我們投入大量的精力，深入去研究ELK并持續的優化生產集群:
- 為提高系統穩定性和容量管理能力，我們加強了監控，在Ganglia上開發了ES監控插件:
- 為加強系統安全性，我們開發了開源的認證網關ESProxy( https://github.com/childe/esproxy) ，使得Kibana可以接入公司的SSO(單點登錄系統)，并在索引級別提供黑白名單的訪問控制；
- 為提高CPU利用率，節省硬件資源，我們開發了開源工具Hangout( https://github.com/childe/hangout ) 替代Logstash，吞吐量提升了5倍之多；
- 基于開源的Logstash Forwarder開發的Agent，解決了Windows平臺原有Log Agent的資源消耗高、不穩定的問題；
- 為提高Kibana易用性，我們開發了導航Panel、數據同比排名Panel、時間偏移對比等等特性。
- 為應對更大規模的日志流，我們研究Kafka并替換了Redis，使得運輸管道更易于水平擴展，穩定性和容錯性更高。
- 為提升大范圍數據聚合速度和防止內存溢出，我們很早發現了ES1.x版本對Doc Values特性的支持，率先采用后使得生產集群的聚合速度和穩定性大幅提高。
- 為提升數據數據寫入實時性，我們對集群做了冷熱數據分離和自動遷移，保障數據寫入實時性不會受到大范圍查詢的影響。
- 為提高ES集群穩定性，我們還做了客戶端節點和數據結點分離等架構上的優化。
以下架構是攜程生產集群逐步演變成過程:
成果與未來展望
經過1年多的不懈努力，我們的ES集群擴展到40個數據結點，收集50多種類型的日志，日處理日志160億條，大小近5TB。 運行穩定，響應快速，監控完備。目前已經成為攜程網站運維核心應用之一，用戶涵蓋運維，系統研發，信息安全，應用研發。
ElasticSearch成名于ELK，但絕非只擅長于做日志分析，作為分布式搜索引擎，很多公司將其用于全站搜索，相關性推薦等功能。ELK在攜程的成功應用也吸引了部分業務研發部門的架構師對Elasticsearch這項技術的關注。部分應用的搜索功能正在引入ElasticSearch進行重構，以期提高搜索的準確性、速度和系統可靠性。
我們下一個基于Elasticsearch的應用將是正在研發中的新一代分布式監控平臺HickWall。相較于主流監控平臺采用的時間序列存儲方案，例如RRDtool、MySQL、OpenTSDB、InfluxDB等，我們認為Elasticsearch可以提供更好的水平擴展性，更靈活快速的數值聚合計算功能。目前項目正在緊鑼密鼓的開發過程中，有望在明年下半年在生產上部署，并助力攜程網站流量10x的增長。