作者簡介：

胡凱

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：

我們在路上，期待與你共享。

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