Windows linux apache 云计算 编程 开源 微软 mysql java Python php google nginx shell 程序员 wordpress centos Android Firefox Ubuntu

Better ELK, 新浪實時日誌分析服務進化

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

---

服務介紹

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

技術架構

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

Better ELK, 新浪实时日志分析服务进化

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

(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等),打通日誌流。

後來我們做了一個簡單的用來協商日誌格式的界面:

Better ELK, 新浪实时日志分析服务进化

目前我們已完成了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的搜索天賦滿足了他們的需求,減少了他們的痛苦。

Better ELK, 新浪实时日志分析服务进化

我們經歷過的坑和坎兒:

(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模式

延伸阅读

    评论