新浪是如何分析处理32亿条实时日志的?
服務(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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 互联网亿级日志实时分析平台,一个码农半小
- 下一篇: 标准化Keras:TensorFlow