《獨(dú)領(lǐng)風(fēng)騷的B站，其監(jiān)控有何過人之處？》要點(diǎn)：
本文介紹了獨(dú)領(lǐng)風(fēng)騷的B站，其監(jiān)控有何過人之處？，希望對(duì)您有用。如果有疑問，可以聯(lián)系我們。

 

作者簡(jiǎn)介：胡凱

bilibili, 運(yùn)維負(fù)責(zé)人

從系統(tǒng)測(cè)試到自動(dòng)化測(cè)試到性能測(cè)試再到運(yùn)維,對(duì)服務(wù)端的興致帶他一步步走近互聯(lián)網(wǎng)、步入運(yùn)維行列.豐富的經(jīng)歷,讓他對(duì)運(yùn)維有著獨(dú)特的思考和認(rèn)知.

前言

隨著互聯(lián)網(wǎng)的高速發(fā)展,我們經(jīng)歷的數(shù)據(jù)量越來越大、越來越重,運(yùn)維也越來越重要.有幸參加“GOPS2017·全球運(yùn)維大會(huì).深圳站”,希望通過本文和大家分享過去一年多時(shí)間里B站運(yùn)維監(jiān)控系統(tǒng)的發(fā)展歷程以及我的思考.

一、自動(dòng)發(fā)布

回想2015年中入職B站,運(yùn)維部才正在成立.鋪面而來的各種事務(wù),壓得我和運(yùn)維小伙伴們喘不過氣來.

想想有好多系統(tǒng)要做,雖然忙得沒時(shí)間也沒人做.

按過往經(jīng)驗(yàn),掐指一算：要尋找破局點(diǎn)、盡早做出第一個(gè)改變!

當(dāng)時(shí)最耗精力的就是發(fā)布,沒多久我們看準(zhǔn)了從發(fā)布著手,先把勞動(dòng)力解放出來.于是做了簡(jiǎn)單的發(fā)布系統(tǒng)：

基于?OpenLDAP?和谷歌的“身份驗(yàn)證器”作為認(rèn)證,Gitlab?作為代碼托管,按需接入?Jenkins?構(gòu)建,在堡壘機(jī)上包裝?Ansible(腳本也在?Gitlab?上),用命令行完成批量部署上線.

初見成效后,簡(jiǎn)單包裝了一個(gè)頁面、加了發(fā)布時(shí)間的控制就開心的用起來了.

二、必須做監(jiān)控

我們服務(wù)端典型的應(yīng)用場(chǎng)景如下圖：

用戶訪問到邊緣的?CDN?節(jié)點(diǎn),然后通過二級(jí)緩存最后傳到核心機(jī)房的四層負(fù)載均衡LVS集群,再通過七層?Tengine?的?SLB?集群按規(guī)則分流到各個(gè)應(yīng)用里.

典型的應(yīng)用后端會(huì)有緩存、隊(duì)列,然后再到數(shù)據(jù)庫.開發(fā)語言有?Go、Java、PHP、Python、C/C++?等(排名不分先后)

那么問題來了：“監(jiān)控呢?”?B站工程師氣氛很濃,熱愛開源.連DNS都自研、CDN?自建,鏈路長、監(jiān)控少,隨業(yè)務(wù)增多定位問題變得非常困難.

三、第一個(gè)報(bào)警：ELK

很多人心里都有一套運(yùn)維自動(dòng)化系統(tǒng),而且是閉環(huán)的.在有效資源里,從哪里開始呢?

原計(jì)劃本是打算自下而上,從主機(jī)監(jiān)控一步步往上走.而后發(fā)現(xiàn)不少用戶反饋的問題,后端無感知.

鑒于?CDN?日志都在手上,用戶最開始接觸的就是?CDN.索性把錯(cuò)誤日志給收回來,錯(cuò)誤多了就報(bào)警.于是ELK誕生了：

我們僅收錯(cuò)誤日志,塞到?ElasticSearch?里,按域名、CDN?節(jié)點(diǎn)、用戶IP以及錯(cuò)誤碼進(jìn)行分類排序.

這樣當(dāng)收到報(bào)警短信時(shí),基本第一眼都可以鎖定一個(gè)故障區(qū)域了.隨后稍加流程,接入微信完美收工.

以下是報(bào)警短信的代碼片段,計(jì)劃任務(wù)第分鐘執(zhí)行(很土很有效).另外還有個(gè)腳本監(jiān)控錯(cuò)誤日志的數(shù)量,但數(shù)量為零時(shí)也會(huì)報(bào)警(你懂的).

四、可惜還是你：Zabbix

做完?CDN?監(jiān)控,我們想回頭把基礎(chǔ)監(jiān)控做起來.經(jīng)過開源、自研?各種討論,綜合下來還是選擇了?Zabbix.因?yàn)樗鼘?shí)施快、報(bào)警策略靈活、會(huì)用它的人多容易招.

五、監(jiān)控交給你：Statsd

好,CDN?前端的錯(cuò)誤監(jiān)控,應(yīng)用底層的系統(tǒng)監(jiān)控都有了.應(yīng)用自身的監(jiān)控怎么做呢?根據(jù)當(dāng)時(shí)同事的過往經(jīng)驗(yàn)看,怎么熟怎么來.那就?Statsd?吧!

Statsd?用起來比較簡(jiǎn)單,只需要開發(fā)在他關(guān)注的代碼前后加上錨點(diǎn)就可以了.

默認(rèn)是?UDP?協(xié)議上報(bào)數(shù)據(jù)(天生自帶異步光環(huán)),不容易出現(xiàn)由于監(jiān)控影響到程序本身.下圖是在?Shell?腳本里做?Statsd?監(jiān)控的示例代碼：

搭好一套?Statsd?收集器,配置一下?Graphite?就能出圖了：

前端用?Grafana?包裝一下,一個(gè)完整的?APM?監(jiān)控閃亮登場(chǎng).以下圖例為某接口的平均響應(yīng)耗時(shí)：

六、百花齊放：Grafana

網(wǎng)傳?Grafana?有插件可以直接通過?API?讀取?Zabbix?的監(jiān)控?cái)?shù)據(jù),然而沒多久新版本的?Grafana?就默認(rèn)自帶了此光環(huán).

然后我們就開心的給?Zabbix?裝上了?Grafana?套件,和?Statsd?的監(jiān)控?cái)?shù)據(jù)整合在一起、易用性加一分.

此時(shí)結(jié)合?CDN?錯(cuò)誤監(jiān)控、應(yīng)用層?APM?監(jiān)控、底層數(shù)據(jù)監(jiān)控,聯(lián)運(yùn)查問題某些時(shí)候感覺很舒適.下圖為一次故障過程的追蹤：

我們并沒有因此滿足,基礎(chǔ)架構(gòu)的同學(xué)參考谷歌的文獻(xiàn)實(shí)現(xiàn)了內(nèi)部的?Drapper?鏈接追蹤系統(tǒng).

請(qǐng)求從?CDN?入口開始就會(huì)攜帶?TrackID,甚至不忘在?SQL?的查詢語句里把?TrackID?帶上.以至于追蹤得很細(xì)致,哪里什么原因耗時(shí)最長一目了然.圖示：

七、突破壁壘：Misaka

做完如上監(jiān)控,發(fā)現(xiàn)仍然有用戶反饋問題時(shí)我們束手無策.因?yàn)槲覀儧]有收到任何與此用戶相關(guān)的錯(cuò)誤信息……

可能網(wǎng)路過程出現(xiàn)了未知原因,比如“被加速”、“功能問題”、“異常退出”等等.

于是我們的輿情監(jiān)測(cè)系統(tǒng)?Misaka?上線,和CDN錯(cuò)誤日志思路相同；不同的是客戶端是真客戶端,突破了服務(wù)端的壁壘.

由于?Misaka?上線的受眾群體更廣,我們簡(jiǎn)單包裝了一下界面(雖然我覺得?ELK?更漂亮)、添加了歷史數(shù)據(jù)的比較.更利于分析,下圖示例：

八、報(bào)警整合

隨著人員的加入和系統(tǒng)的逐步完善,定制化的監(jiān)控和系統(tǒng)也越來越多.比如,支持多種集群模式的?Redis?集群監(jiān)控：

還有隊(duì)列的監(jiān)控,以及把?Kafka?隊(duì)列包裝成支持?Redis?協(xié)議的?Databus?中間件的監(jiān)控.下圖示例：

隨即?Docker?的監(jiān)控也來了,下圖示例：

那么問題又來了,這么多監(jiān)控,眼不花嗎?會(huì)不會(huì)查問題的時(shí)候得開N個(gè)窗口,拼經(jīng)驗(yàn)看誰定位問題更快……

痛定思痛,我們走訪了幾家互聯(lián)網(wǎng)公司.然后默默的做了一次整合,將報(bào)警和事件以時(shí)間軸的方式展現(xiàn)了出來.

用過都說好,下圖示例：

九、在路上：Prometheus

經(jīng)歷約一年時(shí)間的洗禮,我們又回到了監(jiān)控系統(tǒng)的選型.

為什么?因?yàn)樵絹碓蕉嗟幕颖O(jiān)控需求,已經(jīng)無法很快得到滿足、而且維護(hù)工作日漸繁瑣.嗯,可能不同階段需要不同的解決方案.

那為什么是?Prometheus?因?yàn)榭蛇x的開源產(chǎn)品并不多,新潮前衛(wèi)的現(xiàn)代化監(jiān)控就?OpenFlaon?和?Prometheus?啦.

Prometheus?不止是監(jiān)控工具,它是一套完整的監(jiān)控解決方案.除了前端,其它都好.

很快?Prometheus?就上線了,逐步取代了?Zabbix.前端仍然是熟悉的Grafana：

不得不說?Prometheus?真的很強(qiáng)大,過去都用?Ganglia?監(jiān)控?Hadoop?監(jiān)控.如今?Prometheus?輕松搞定,顏值還不差：

MySQL?的監(jiān)控?cái)?shù)據(jù)也非常詳盡,以下截圖看懂的是專業(yè)?DBA：

我們?cè)诼飞?期待與你共享.

文章來自微信公眾號(hào)：高效運(yùn)維

轉(zhuǎn)載請(qǐng)注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4115.html