《獨領風騷的B站，其監控有何過人之處？》要點：
本文介紹了獨領風騷的B站，其監控有何過人之處？，希望對您有用。如果有疑問，可以聯系我們。

 

作者簡介：胡凱

bilibili, 運維負責人

從系統測試到自動化測試到性能測試再到運維,對服務端的興致帶他一步步走近互聯網、步入運維行列.豐富的經歷,讓他對運維有著獨特的思考和認知.

前言

隨著互聯網的高速發展,我們經歷的數據量越來越大、越來越重,運維也越來越重要.有幸參加“GOPS2017·全球運維大會.深圳站”,希望通過本文和大家分享過去一年多時間里B站運維監控系統的發展歷程以及我的思考.

一、自動發布

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

想想有好多系統要做,雖然忙得沒時間也沒人做.

按過往經驗,掐指一算：要尋找破局點、盡早做出第一個改變!

當時最耗精力的就是發布,沒多久我們看準了從發布著手,先把勞動力解放出來.于是做了簡單的發布系統：

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

初見成效后,簡單包裝了一個頁面、加了發布時間的控制就開心的用起來了.

二、必須做監控

我們服務端典型的應用場景如下圖：

用戶訪問到邊緣的?CDN?節點,然后通過二級緩存最后傳到核心機房的四層負載均衡LVS集群,再通過七層?Tengine?的?SLB?集群按規則分流到各個應用里.

典型的應用后端會有緩存、隊列,然后再到數據庫.開發語言有?Go、Java、PHP、Python、C/C++?等(排名不分先后)

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

三、第一個報警：ELK

很多人心里都有一套運維自動化系統,而且是閉環的.在有效資源里,從哪里開始呢?

原計劃本是打算自下而上,從主機監控一步步往上走.而后發現不少用戶反饋的問題,后端無感知.

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

我們僅收錯誤日志,塞到?ElasticSearch?里,按域名、CDN?節點、用戶IP以及錯誤碼進行分類排序.

這樣當收到報警短信時,基本第一眼都可以鎖定一個故障區域了.隨后稍加流程,接入微信完美收工.

以下是報警短信的代碼片段,計劃任務第分鐘執行(很土很有效).另外還有個腳本監控錯誤日志的數量,但數量為零時也會報警(你懂的).

四、可惜還是你：Zabbix

做完?CDN?監控,我們想回頭把基礎監控做起來.經過開源、自研?各種討論,綜合下來還是選擇了?Zabbix.因為它實施快、報警策略靈活、會用它的人多容易招.

五、監控交給你：Statsd

好,CDN?前端的錯誤監控,應用底層的系統監控都有了.應用自身的監控怎么做呢?根據當時同事的過往經驗看,怎么熟怎么來.那就?Statsd?吧!

Statsd?用起來比較簡單,只需要開發在他關注的代碼前后加上錨點就可以了.

默認是?UDP?協議上報數據(天生自帶異步光環),不容易出現由于監控影響到程序本身.下圖是在?Shell?腳本里做?Statsd?監控的示例代碼：

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

前端用?Grafana?包裝一下,一個完整的?APM?監控閃亮登場.以下圖例為某接口的平均響應耗時：

六、百花齊放：Grafana

網傳?Grafana?有插件可以直接通過?API?讀取?Zabbix?的監控數據,然而沒多久新版本的?Grafana?就默認自帶了此光環.

然后我們就開心的給?Zabbix?裝上了?Grafana?套件,和?Statsd?的監控數據整合在一起、易用性加一分.

此時結合?CDN?錯誤監控、應用層?APM?監控、底層數據監控,聯運查問題某些時候感覺很舒適.下圖為一次故障過程的追蹤：

我們并沒有因此滿足,基礎架構的同學參考谷歌的文獻實現了內部的?Drapper?鏈接追蹤系統.

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

七、突破壁壘：Misaka

做完如上監控,發現仍然有用戶反饋問題時我們束手無策.因為我們沒有收到任何與此用戶相關的錯誤信息……

可能網路過程出現了未知原因,比如“被加速”、“功能問題”、“異常退出”等等.

于是我們的輿情監測系統?Misaka?上線,和CDN錯誤日志思路相同；不同的是客戶端是真客戶端,突破了服務端的壁壘.

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

八、報警整合

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

還有隊列的監控,以及把?Kafka?隊列包裝成支持?Redis?協議的?Databus?中間件的監控.下圖示例：

隨即?Docker?的監控也來了,下圖示例：

那么問題又來了,這么多監控,眼不花嗎?會不會查問題的時候得開N個窗口,拼經驗看誰定位問題更快……

痛定思痛,我們走訪了幾家互聯網公司.然后默默的做了一次整合,將報警和事件以時間軸的方式展現了出來.

用過都說好,下圖示例：

九、在路上：Prometheus

經歷約一年時間的洗禮,我們又回到了監控系統的選型.

為什么?因為越來越多的花樣監控需求,已經無法很快得到滿足、而且維護工作日漸繁瑣.嗯,可能不同階段需要不同的解決方案.

那為什么是?Prometheus?因為可選的開源產品并不多,新潮前衛的現代化監控就?OpenFlaon?和?Prometheus?啦.

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

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

不得不說?Prometheus?真的很強大,過去都用?Ganglia?監控?Hadoop?監控.如今?Prometheus?輕松搞定,顏值還不差：

MySQL?的監控數據也非常詳盡,以下截圖看懂的是專業?DBA：

我們在路上,期待與你共享.

文章來自微信公眾號：高效運維

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4115.html