服務(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è)再常見不過的架構(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ù)，通過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ī)器沒有選擇余地，只開啟了超線程；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, 開啟doc_values，以應(yīng)對(duì)elasticsearch進(jìn)程OOM。詳細(xì)的優(yōu)化內(nèi)容見?Elasticsearch Optimization Checklist?。

隨著用戶數(shù)據(jù)的不斷增長(zhǎng)，index管理也成了大問題，我們需要基于大量不同的用戶配置定期的create, optimize, close, delete, snapshot不同的index，在某個(gè)服務(wù)器上手工配置crontab已是不可能，而且cron是單點(diǎn)。于是我們開發(fā)了一個(gè)獨(dú)立的 Elasticsearch Index管理系統(tǒng)，負(fù)責(zé)以上任務(wù)的調(diào)度及執(zhí)行。這個(gè)管理系統(tǒng)背后使用的技術(shù)是Celery，一個(gè)用Python開發(fā)的任務(wù)隊(duì)列及執(zhí)行系統(tǒng)，提供了類似 crontab的定時(shí)任務(wù)配置語法，并且實(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過高，Kibana能否正常訪問，Kafka topic的consumer offset lag）, 我們開發(fā)了對(duì)應(yīng)的監(jiān)控報(bào)警腳本。User Level(如日志解析失敗數(shù)量)，主要通過elasticsearch python client執(zhí)行?query?去統(tǒng)計(jì)或搜索。常見的報(bào)警是Logstash-filter-grok，logstash-filter-json解析日志失敗會(huì)輸出的json中添加_grokparserfailure,_jsonparsefailure,我們執(zhí)行query判斷解析錯(cuò)誤的量。

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

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

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

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

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

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

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

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

?

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

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

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

三、提供新功能

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

?

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

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

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

（2） Elasticsearch Query DSL, Facets, Aggs學(xué)習(xí)困惑

有人為此開發(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不工作

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

（4）Kibana沒有用戶的概念，不同用戶的數(shù)據(jù)無法隔離

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

（5）與用戶溝通成本高

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

---

Q & A:

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

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

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

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

問：大數(shù)據(jù)分析平臺(tái)（基于hdfs）跟kibana的展現(xiàn)會(huì)有很大區(qū)別嗎？或者說最大的區(qū)別會(huì)在哪些方面？

答：你說的區(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è)搜引擎，可以用來做全文檢索等工 作，hadoop顯然于此無關(guān)。統(tǒng)計(jì)是hadoop與es都能做的，我不了解hadoop有沒有像Kibana這樣的數(shù)據(jù)可視化組件。

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

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

?

參考資料：

Python 多進(jìn)程日志記錄:http://itindex.net/detail/14658-python-%E8%BF%9B%E7%A8%8B-%E6%97%A5%E5%BF%97

Better ELK, 新浪實(shí)時(shí)日志分析服務(wù)進(jìn)化:http://www.open-open.com/news/view/1bbf9

Kafka實(shí)戰(zhàn)－實(shí)時(shí)日志統(tǒng)計(jì)流程:http://www.open-open.com/lib/view/open1434523721208.html

基于fluem和kafka的實(shí)時(shí)日志收集系統(tǒng):http://www.colabug.com/thread-1099061-1-1.html?pp=2

fluent/fluentd:https://github.com/fluent/fluentd/

?

日志客戶端（Logstash,Fluentd, Logtail）橫評(píng):https://yq.aliyun.com/articles/3228

Logstash and Log Monitoring With Nagios:https://www.nagios.com/solutions/logstash/

How can we monitor performance of Kafka, Logstash and elasticsearch? Is there any tool available for monitoring their performance?:https://www.quora.com/How-can-we-monitor-performance-of-Kafka-Logstash-and-elasticsearch-Is-there-any-tool-available-for-monitoring-their-performance

?

Send Nagios metrics to Graphite via Logstash:http://philippe.lewin.me/2014/10/02/nagios-metrics-to-graphite-via-logstash/

報(bào)警到 Nagios:http://logstash-best-practice.readthedocs.io/zh_CN/latest/output/nagios/

Logstash and Log Monitoring With Nagios:https://www.nagios.com/solutions/logstash/

scribe、chukwa、kafka、flume日志系統(tǒng)對(duì)比:http://www.ttlsa.com/log-system/scribe-chukwa-kafka-flume-log-system-contrast/

?

?

http://jasonwilder.com/blog/2013/11/19/fluentd-vs-logstash/

http://logz.io/blog/fluentd-logstash/

https://yq.aliyun.com/articles/3228

http://www.tuicool.com/articles/7FzqeeI

https://segmentfault.com/q/1010000002894783

http://blog.csdn.net/benpaobagzb/article/details/50903323

?

https://www.cnblogs.com/felixzh/p/6413526.html

總結(jié)

以上是生活随笔為你收集整理的新浪是如何分析处理32亿条实时日志的？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。