來源：http://www.dockone.io/article/505
【編者的話】我從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模式。
閱讀更多 javafirst 的文章
