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

服務(wù)介紹

隨著實(shí)時(shí)分析技術(shù)的發(fā)展及成本的降低，用戶已經(jīng)不僅僅滿足于離線分析。目前我們服務(wù)的用戶包括微博、微盤、云存儲(chǔ)、彈性計(jì)算平臺(tái)等十多個(gè)部門的多個(gè)產(chǎn)品的日志搜索分析業(yè)務(wù)，每天處理約32億條(2TB)日志。

技術(shù)架構(gòu)

簡(jiǎn)單介紹一下服務(wù)的技術(shù)架構(gòu)：

這是一個(gè)再常見(jiàn)不過(guò)的架構(gòu)了：

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

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

(3)Elasticsearch：實(shí)時(shí)日志分析服務(wù)的核心技術(shù)，一個(gè)schemaless，實(shí)時(shí)的數(shù)據(jù)存儲(chǔ)服務(wù)，通過(guò)index組織數(shù)據(jù)，兼具強(qiáng)大的搜索和統(tǒng)計(jì)功能。

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

努力提供更好的服務(wù)

我這次分享的重點(diǎn)不是這種架構(gòu)的優(yōu)劣或?yàn)槭裁催x擇這樣的架構(gòu)，而是在如此的架構(gòu)上如何更好地傳遞實(shí)時(shí)日志分析的價(jià)值。為用戶做好服務(wù)也不是修改幾個(gè)配置文件，調(diào)優(yōu)幾個(gè)程序運(yùn)行參數(shù)就能搞定的。為了提供更好的服務(wù)，我們?cè)谙旅嫒齻€(gè)方向做了努力：

一、提升服務(wù)質(zhì)量

我們首先做了Elasticsearch優(yōu)化，Hardware Level由于我們當(dāng)時(shí)拿到機(jī)器沒(méi)有選擇余地，只開(kāi)啟了超線程;System Level的優(yōu)化如關(guān)閉swap，調(diào)整max open files等;App Level的優(yōu)化如Java運(yùn)行環(huán)境版本的選擇，ES_HEAP_SIZE的設(shè)置，修改bulk index的queue size等，另外還設(shè)置了默認(rèn)的index template，目的是更改默認(rèn)的shard，replica數(shù)并將string改為not_analyzed，開(kāi)啟doc_values以應(yīng)對(duì) elasticsearch進(jìn)程O(píng)OM。詳細(xì)的優(yōu)化內(nèi)容見(jiàn)Elasticsearch Optimization Checklist。

隨著用戶數(shù)據(jù)的不斷增長(zhǎng)，index管理也成了大問(wèn)題，我們需要基于大量不同的用戶配置定期的create、optimize、close、 delete、snapshot不同的index，在某個(gè)服務(wù)器上手工配置crontab已是不可能，而且cron是單點(diǎn)。于是我們開(kāi)發(fā)了一個(gè)獨(dú)立的 Elasticsearch Index管理系統(tǒng)，負(fù)責(zé)以上任務(wù)的調(diào)度及執(zhí)行。這個(gè)管理系統(tǒng)背后使用的技術(shù)是Celery，一個(gè)用Python開(kāi)發(fā)的任務(wù)隊(duì)列及執(zhí)行系統(tǒng)，提供了類似 crontab的定時(shí)任務(wù)配置語(yǔ)法，并且實(shí)現(xiàn)了分布式，可用性更高的架構(gòu)。

最近的服務(wù)升級(jí)，我們?yōu)镋lasticsearch安裝了HDFS Snapshot插件，可以定期將index備份到HDFS，這個(gè)功能目前主要用于備份Kibana的配置index，用以恢復(fù)用戶查看或配置可視化界面時(shí)的錯(cuò)誤操作。

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

要說(shuō)明的是，Marvel是Elasticsearch很好的監(jiān)控工具和插件，但是它們是商業(yè)軟件，我們沒(méi)有采用。Marvel是基于Kibana做的，里面對(duì)一些重要指標(biāo)(如index bulk reject number)的展示很有價(jià)值。

#p#

二、增強(qiáng)易用性

增強(qiáng)服務(wù)的易用性就是給用戶更好的用戶體驗(yàn)，減少用戶的抱怨。ELK性能優(yōu)化是一方面，但它是遠(yuǎn)遠(yuǎn)不夠的，我們遇到的實(shí)際情況是，用戶在其他方面抱怨更多，如下：

1，用戶***抱怨的是IP解析成地區(qū)、ISP信息一點(diǎn)都不準(zhǔn)，完全沒(méi)有參考意義。

如對(duì)于CDN這種服務(wù)，我們解析用戶IP不準(zhǔn)，定位問(wèn)題邊緣節(jié)點(diǎn)錯(cuò)誤，問(wèn)題沒(méi)法查，這是幫倒忙。原因：Logstash默認(rèn)自帶的IP庫(kù)是國(guó)外 maxmind公司的免費(fèi)版本，中國(guó)的信息尤其不準(zhǔn)。解決方案：使用我浪較新較全的IP庫(kù)生成能適配maxmind geoip2 api的二進(jìn)制格式IP庫(kù)(maxmindDB)，再開(kāi)發(fā)logstash-filter-geoip2來(lái)解析IP。實(shí)測(cè)不僅IP解析準(zhǔn)確率與公司IP庫(kù)相同了，解析速度也提高了。

2，然后我們與用戶都發(fā)現(xiàn)日志接入流程復(fù)雜，溝通困難。

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

后來(lái)我們做了一個(gè)簡(jiǎn)單的用來(lái)協(xié)商日志格式的界面：

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

3，部分?jǐn)?shù)據(jù)可視化需求得不到滿足，Kibana配置難度大。

我們起初采用官方Kibana v3，用戶提出的類似SQL中的多個(gè)group by，畫(huà)百分比，求指定區(qū)間占比等常見(jiàn)需求無(wú)法滿足。之后通過(guò)三斗大神(微博@argv)定制版的Kibana 3滿足了一些用戶需求。Kibana 4誕生后，代碼幾乎是對(duì)Kibana3的重寫(xiě)，做了大幅改進(jìn)，通過(guò)Elasticsearch Aggregation的強(qiáng)大數(shù)據(jù)統(tǒng)計(jì)功能及靈活的配置從Kibana 3解放出來(lái)。近期我們將遷移到Kibana 4。

#p#

三、提供新功能

我們?yōu)镋lasticsearch安裝了國(guó)內(nèi)medcl大神開(kāi)發(fā)的ik中文分詞插件elasticsearch-analysis-ik。之前被分詞為『中』和『國(guó)』的中國(guó)，現(xiàn)在終于可以被當(dāng)做一個(gè)完整的詞匯，否則搜索『中國(guó)』、『美國(guó)』也會(huì)出現(xiàn)。微盤的一些離線搜索需求使用了我們的服務(wù)，也用到了中文分詞，Elasticsearch的搜索天賦滿足了他們的需求，減少了他們的痛苦。

我們經(jīng)歷過(guò)的坑和坎兒：

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

很長(zhǎng)一段時(shí)間，我們都在應(yīng)對(duì)JVM Heap High Usage，他帶了的問(wèn)題是Old GC次數(shù)多，時(shí)間長(zhǎng)，es節(jié)點(diǎn)頻繁退出集群，整個(gè)集群幾乎停止響應(yīng)?，F(xiàn)在我們的主要策略是開(kāi)啟doc_values;限制query執(zhí)行時(shí)占用的JVM Heap size;analyzed string只允許做query，不允許facets或者aggs;定期close 用戶不需要的index。

2，Elasticsearch Query DSL、Facets、Aggs學(xué)習(xí)困惑。

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

3，logstash不工作。

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

4，Kibana沒(méi)有用戶的概念，不同用戶的數(shù)據(jù)無(wú)法隔離。

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

5，與用戶溝通成本高。

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

Q & A:

問(wèn)：logstash連es出現(xiàn)timeout的情況有沒(méi)?如何解決的?

答：我們常見(jiàn)的是ES Jvm Heap Usage比較高的時(shí)候會(huì)timeout，如果是服務(wù)內(nèi)存小換大內(nèi)存。另外不要對(duì)analyzed的string做aggs、facets，開(kāi)啟doc_values。

問(wèn)：關(guān)于日志中異常報(bào)警的，有哪些方式?關(guān)鍵字過(guò)濾?

答：對(duì)于日志解析失敗的情況，logstash 常見(jiàn)的是_grokparsefailuer和_jsonparsefailure，數(shù)據(jù)寫(xiě)入es后，執(zhí)行query查詢這兩個(gè)關(guān)鍵詞的數(shù)量即可。對(duì)于報(bào)警方案，watch是官方剛出的，其實(shí)比它早的實(shí)現(xiàn)方案，如Yelp的elastalert。

問(wèn)：大數(shù)據(jù)分析平臺(tái)(基于HDFS)跟kibana的展現(xiàn)會(huì)有很大區(qū)別嗎?或者說(shuō)***的區(qū)別會(huì)在哪些方面?

答：你說(shuō)的區(qū)別，我理解是Hadoop與Elasticsearch的區(qū)別，一個(gè)是離線分析，以job為單位，一個(gè)是實(shí)時(shí)搜索和統(tǒng)計(jì)，以query為單位。這里有三個(gè)關(guān)鍵詞：實(shí)時(shí)，搜索，統(tǒng)計(jì)。Hadoop是離線的，es是實(shí)時(shí)的;es本質(zhì)上是一個(gè)搜引擎，可以用來(lái)做全文檢索等工作，Hadoop顯然于此無(wú)關(guān)。統(tǒng)計(jì)是Hadoop與es都能做的，我不了解Hadoop有沒(méi)有像Kibana這樣的數(shù)據(jù)可視化組件。

問(wèn)：你們的ES集群數(shù)據(jù)節(jié)點(diǎn)和查詢節(jié)點(diǎn)做了分離嗎?logstash是直接把數(shù)據(jù)寫(xiě)入查詢節(jié)點(diǎn)還是數(shù)據(jù)節(jié)點(diǎn)?另外你們直接用的node模式還是transport模式呢?

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

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