這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。
【編者的話】我從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）的展示很有價值。
二、增強易用性
增強服務的易用性就是給使用者更好的使用者體驗，減少使用者的抱怨。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。
三、提供新功能
我們為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模式。
PPT已經上傳至微盤。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以上內容根據2015年7月14日晚群分享內容整理。分享人
高英舉，就職於新浪，主要負責dip即時日誌分析服務技術架構與實現，為微博，微盤，視頻，cdn等多個部門提供即時日誌統計和搜尋服務，熱衷於將開源技術服務化，產品化。微博：@gary的影響力。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加：liyingjiesx，進群參與。
