源起
日志，看似簡單簡單的文本，在網站運維人員眼裡卻似一座蘊含豐富的寶藏。通常以下運維任務都或多或少需要運維人員和日志打交道:
- 系統健康狀況監控
- 查找故障根源
- 系統瓶頸診斷和調優
- 追蹤安全相關問題
技能熟練的Linux SA們能夠很快的組合諸如grep, awk這樣的指令，奇幻般的從日志中挖掘出有用的資訊；亦或是研發人員往往會基于MySQL,MongoDB,HBase開發自己的日志存儲和分析工具。
然而網際網路大規模、分布式的特性決定了日志的源頭越來越分散，産生的速度越來越快，傳統的手段和工具顯得日益力不從心。市場對新工具的需求已然催生出Splunk這樣近百億美元市值的專業日志分析解決方案供應商。
從2013年攜程網站營運中心成立伊始，集中化的運維日志分析平台就被提上議事日程。作為中國最大的OTA網站，攜程基礎設施每日産生的各類日志有好幾十種，量級在數個TB級别，如果采用Splunk這樣的商業軟體，每年的授權費用就要近千萬。昂貴的授權費用驅使我們深入研究這個領域，尋求商業軟體以外的替代方案。
小試牛刀
一線運維部門對于日志分析工具有如下幾個重要的期盼點:
- 日志要支援多種資料源
- 日志解析方式靈活但簡單
- 支援關鍵詞搜尋和浏覽，能支援組合條件搜尋
- 能夠按照時間窗對特定字段做數值統計，并且時間窗最好可以随意縮放，比如計算某個時間段的平均響應時間，或者出現某種錯誤類型最多的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并持續的優化生産叢集:
1. 為提高系統穩定性和容量管理能力，我們加強了監控，在Ganglia上開發了ES監控插件:
2. 為加強系統安全性，我們開發了開源的認證網關ESProxy(https://github.com/childe/esproxy)，使得Kibana可以接入公司的SSO(單點登入系統)，并在索引級别提供黑白名單的通路控制；
3. 為提高CPU使用率，節省硬體資源，我們開發了開源工具Hangout(https://github.com/childe/hangout) 替代Logstash，吞吐量提升了5倍之多；
4. 基于開源的Logstash Forwarder開發的Agent，解決了Windows平台原有Log Agent的資源消耗高、不穩定的問題；
5. 為提高Kibana易用性，我們開發了導航Panel、資料同比排名Panel、時間偏移對比等等特性。
6. 為應對更大規模的日志流，我們研究Kafka并替換了Redis，使得運輸管道更易于水準擴充，穩定性和容錯性更高。
7. 為提升大範圍資料聚合速度和防止記憶體溢出，我們很早發現了ES1.x版本對Doc Values特性的支援，率先采用後使得生産叢集的聚合速度和穩定性大幅提高。
8. 為提升資料資料寫入實時性，我們對叢集做了冷熱資料分離和自動遷移，保障資料寫入實時性不會受到大範圍查詢的影響。
9. 為提高ES叢集穩定性，我們還做了用戶端節點和資料結點分離等架構上的優化。
以下架構是攜程生産叢集逐漸演變成過程:
成果與未來展望
經過1年多的不懈努力，我們的ES叢集擴充到40個資料結點，收集50多種類型的日志，日處理日志160億條，大小近5TB。 運作穩定，響應快速，監控完備。目前已經成為攜程網站運維核心應用之一，使用者涵蓋運維，系統研發，資訊安全，應用研發。
ElasticSearch成名于ELK，但絕非隻擅長于做日志分析，作為分布式搜尋引擎，很多公司将其用于全站搜尋，相關性推薦等功能。ELK在攜程的成功應用也吸引了部分業務研發部門的架構師對Elasticsearch這項技術的關注。部分應用的搜尋功能正在引入ElasticSearch進行重構，以期提高搜尋的準确性、速度和系統可靠性。
我們下一個基于Elasticsearch的應用将是正在研發中的新一代分布式監控平台HickWall。相較于主流監控平台采用的時間序列存儲方案，例如RRDtool、MySQL、OpenTSDB、InfluxDB等，我們認為Elasticsearch可以提供更好的水準擴充性，更靈活快速的數值聚合計算功能。目前項目正在緊鑼密鼓的開發過程中，有望在明年下半年在生産上部署，并助力攜程網站流量10x的增長。