我從2014年初入職新浪后就開始接觸實時日志分析相關的技術，主要是ELK(Elasticsearch、Logstash、Kibana)，當時是學習+ELK優化，接一些日志，小打小鬧。從2015年起，我們正式得把實時日志分析作為服務提供給公司的其他部門。今天要給大家分享的是在服務化的道路上，我們的想法，方案和疑問。

服務介紹

隨著實時分析技術的發展及成本的降低，用戶已經不僅僅滿足于離線分析。目前我們服務的用戶包括微博、微盤、云存儲、彈性計算平臺等十多個部門的多個產品的日志搜索分析業務，每天處理約32億條(2TB)日志。

技術架構

簡單介紹一下服務的技術架構：

這是一個再常見不過的架構了：

(1)Kafka：接收用戶日志的消息隊列。

(2)Logstash：做日志解析，統一成JSON輸出給Elasticsearch。

(3)Elasticsearch：實時日志分析服務的核心技術，一個schemaless，實時的數據存儲服務，通過index組織數據，兼具強大的搜索和統計功能。

(4)Kibana：基于Elasticsearch的數據可視化組件，超強的數據可視化能力是眾多公司選擇ELK stack的重要原因。

努力提供更好的服務

我這次分享的重點不是這種架構的優劣或為什么選擇這樣的架構，而是在如此的架構上如何更好地傳遞實時日志分析的價值。為用戶做好服務也不是修改幾個配置文件，調優幾個程序運行參數就能搞定的。為了提供更好的服務，我們在下面三個方向做了努力：

一、提升服務質量

我們首先做了Elasticsearch優化，Hardware Level由于我們當時拿到機器沒有選擇余地，只開啟了超線程;System Level的優化如關閉swap，調整max open files等;App Level的優化如Java運行環境版本的選擇，ES_HEAP_SIZE的設置，修改bulk index的queue size等，另外還設置了默認的index template，目的是更改默認的shard，replica數并將string改為not_analyzed，開啟doc_values以應對 elasticsearch進程OOM。詳細的優化內容見Elasticsearch Optimization Checklist。

隨著用戶數據的不斷增長，index管理也成了大問題，我們需要基于大量不同的用戶配置定期的create、optimize、close、 delete、snapshot不同的index，在某個服務器上手工配置crontab已是不可能，而且cron是單點。于是我們開發了一個獨立的 Elasticsearch Index管理系統，負責以上任務的調度及執行。這個管理系統背后使用的技術是Celery，一個用Python開發的任務隊列及執行系統，提供了類似 crontab的定時任務配置語法，并且實現了分布式，可用性更高的架構。

最近的服務升級，我們為Elasticsearch安裝了HDFS Snapshot插件，可以定期將index備份到HDFS，這個功能目前主要用于備份Kibana的配置index，用以恢復用戶查看或配置可視化界面時的錯誤操作。

監控報警方面，System Level的監控報警(如硬盤滿、損壞、服務器宕機)直接使用了在新浪內部提供了多年服務的sinawatch;App Level(如Elasticsearch JVM Heap Usage過高，Kibana能否正常訪問，Kafka topic的consumer offset lag)，我們開發了對應的監控報警腳本。User Level(如日志解析失敗數量)，主要通過elasticsearch python client執行query去統計或搜索。常見的報警是Logstash-filter-grok，logstash-filter-json解析日志失敗會輸出的json中添加_grokparserfailure、_jsonparsefailure，我們執行query判斷解析錯誤的量。

要說明的是，Marvel是Elasticsearch很好的監控工具和插件，但是它們是商業軟件，我們沒有采用。Marvel是基于Kibana做的，里面對一些重要指標(如index bulk reject number)的展示很有價值。

#p#

二、增強易用性

增強服務的易用性就是給用戶更好的用戶體驗，減少用戶的抱怨。ELK性能優化是一方面，但它是遠遠不夠的，我們遇到的實際情況是，用戶在其他方面抱怨更多，如下：

1，用戶***抱怨的是IP解析成地區、ISP信息一點都不準，完全沒有參考意義。

如對于CDN這種服務，我們解析用戶IP不準，定位問題邊緣節點錯誤，問題沒法查，這是幫倒忙。原因：Logstash默認自帶的IP庫是國外 maxmind公司的免費版本，中國的信息尤其不準。解決方案：使用我浪較新較全的IP庫生成能適配maxmind geoip2 api的二進制格式IP庫(maxmindDB)，再開發logstash-filter-geoip2來解析IP。實測不僅IP解析準確率與公司IP庫相同了，解析速度也提高了。

2，然后我們與用戶都發現日志接入流程復雜，溝通困難。

人做不到機器那樣分毫不差，有啥說啥。接入用戶日志的時候，例如常常因為用戶對日志格式表達的不全面，模棱兩可，導致日志解析失敗，服務對接人多次重寫配置。從用戶提需求到用戶可以看到數據可視化效果或搜到日志，需要幾個小時到幾天。一來二去，用戶和我們都煩了，只能求變。為此，我們正在逐步實現用戶數據接入的自動化，減少接入時間和溝通成本這個過程需要3個關鍵：A.用戶配置日志格式的界面，盡可能簡潔簡單;B.根據用戶配置自動生成 logstash config、index管理需要的配置;C.自動部署配置(logstash config等)，打通日志流。

后來我們做了一個簡單的用來協商日志格式的界面：

目前我們已完成了A的一部分：用戶日志格式配置界面;B的全部：開發了自動生成logstash conf的 python api;C即將開始，并且考慮使用Docker技術為我們提供一些便利。

3，部分數據可視化需求得不到滿足，Kibana配置難度大。

我們起初采用官方Kibana v3，用戶提出的類似SQL中的多個group by，畫百分比，求指定區間占比等常見需求無法滿足。之后通過三斗大神(微博@argv)定制版的Kibana 3滿足了一些用戶需求。Kibana 4誕生后，代碼幾乎是對Kibana3的重寫，做了大幅改進，通過Elasticsearch Aggregation的強大數據統計功能及靈活的配置從Kibana 3解放出來。近期我們將遷移到Kibana 4。

#p#

三、提供新功能

我們為Elasticsearch安裝了國內medcl大神開發的ik中文分詞插件elasticsearch-analysis-ik。之前被分詞為『中』和『國』的中國，現在終于可以被當做一個完整的詞匯，否則搜索『中國』、『美國』也會出現。微盤的一些離線搜索需求使用了我們的服務，也用到了中文分詞，Elasticsearch的搜索天賦滿足了他們的需求，減少了他們的痛苦。

我們經歷過的坑和坎兒：

1，elasticsearch 進程JVM Heap High Usage( > 90% )。

很長一段時間，我們都在應對JVM Heap High Usage，他帶了的問題是Old GC次數多，時間長，es節點頻繁退出集群，整個集群幾乎停止響應。現在我們的主要策略是開啟doc_values;限制query執行時占用的JVM Heap size;analyzed string只允許做query，不允許facets或者aggs;定期close 用戶不需要的index。

2，Elasticsearch Query DSL、Facets、Aggs學習困惑。

有人為此開發了使用SQL執行ES Query的插件，一定程度上減輕了進入門檻。我們給出的學習他們的建議是觀察Kibana的Request Body或試用Marvel的Senese插件，它有自動完成Query、Facets、Aggs的功能。另外最常用的query是query string query，最常用的aggs是Terms、Date Histogram，可以應付大部分需求。

3，logstash不工作。

非官方的問題插件，及使用logstash-filter-ruby時未考慮到的異常等，導致Logstash運行時工作線程(worker thread)異常退出，Logstash僵死。我們的建議是盡可能不要在config中使用logstash-filter-ruby，盡量使用官方插件。不過我們也遇到過復雜的日志，寫過250行+的config，用盡了ruby filter。當前未發現Logstash有好的成熟的監控方案，Logstash的內部狀態也獲取不到。我們目前通過間接的監控Kafka topic consumer是否落后或elasticsearch indexing rate來檢驗logstash的工作情況。

4，Kibana沒有用戶的概念，不同用戶的數據無法隔離。

多個用戶共享的Kibana Dashboard，誤操作或誤刪時常影響其他用戶，保存的dashboard太多，找到特定的dashboard很困難。官方到目前為止，未在這方面做過改進。有很多非官方的改進，我們也曾經用過三斗大神定制的Kibana3，也對Kibana index做了snapshot儲存到HDFS里面。

5，與用戶溝通成本高。

與我們的用戶協商日志格式，數據可視化配置時，由于人的不確定性容易造成多次來回確定和修改，效率低下。我們畢竟是提供日志分析服務的，不給用戶做日志運維，所以近期也在探索通過日志接入自動化、推薦用戶提供給我們json格式數據，定期組織用戶的Kibana培訓來減少溝通成本。

Q & A:

問：logstash連es出現timeout的情況有沒?如何解決的?

答：我們常見的是ES Jvm Heap Usage比較高的時候會timeout，如果是服務內存小換大內存。另外不要對analyzed的string做aggs、facets，開啟doc_values。

問：關于日志中異常報警的，有哪些方式?關鍵字過濾?

答：對于日志解析失敗的情況，logstash 常見的是_grokparsefailuer和_jsonparsefailure，數據寫入es后，執行query查詢這兩個關鍵詞的數量即可。對于報警方案，watch是官方剛出的，其實比它早的實現方案，如Yelp的elastalert。

問：大數據分析平臺(基于HDFS)跟kibana的展現會有很大區別嗎?或者說***的區別會在哪些方面?

答：你說的區別，我理解是Hadoop與Elasticsearch的區別，一個是離線分析，以job為單位，一個是實時搜索和統計，以query為單位。這里有三個關鍵詞：實時，搜索，統計。Hadoop是離線的，es是實時的;es本質上是一個搜引擎，可以用來做全文檢索等工作，Hadoop顯然于此無關。統計是Hadoop與es都能做的，我不了解Hadoop有沒有像Kibana這樣的數據可視化組件。

問：你們的ES集群數據節點和查詢節點做了分離嗎?logstash是直接把數據寫入查詢節點還是數據節點?另外你們直接用的node模式還是transport模式呢?

答：(1)還沒有做分離。(2)我們還在用http protocol模式。

原文鏈接：http://www.dockone.io/article/505