七牛雲架構師實踐日南京站於 11 月 9 日在南京成功舉行，以「大數據技術的實踐與分享」為主題，邀請了多名業內大咖，為大家帶來了精彩演講。bilibili 的架構師屠輝，在會上作了題為《海量監測平臺的演進之路》的分享。
屠輝，擁有 10 年以上運維經驗，現任嗶哩嗶哩基礎平臺架構師
以下內容為根據現場演講內容速記的實錄整理。
各位下午好！我叫屠輝。目前在 bilibili 擔任基礎平臺的架構開發。在加入 bilibili 之前，曾在京東擔任 APM 平臺和公網鏈路探測的架構開發。
今天我分享的主題是《海量監測平臺的演進之路》。首先介紹一下bilibili，我想在座的應該都很熟悉，有大量年輕人喜歡在我們的平臺上發佈視頻。而我們的監測平臺，具有平臺化、數據化、自主化、全局性和定位性這樣的特點。
bilibili 監控系統的演進階段
首先，我來介紹一下 bilibili 的監控系統，在演進過程中存在的幾個階段。
人肉堆積階段
因為 bilibili 的監測系統起步較晚，從 2015 年才有第一名運維人員入職。之前都是處在一個人肉運維的堆積階段，這是比較原始的，這些監測系統基本上就是八仙過海各顯神通，所有數據都分佈在一個個孤島上面，沒有統一的整合。
監測系統的平臺化建設
大概從2016年開始，在意識到之前分散的系統是無法整合之後，我們開始注重監測系統平臺化建設。我們開始了新一代 B 站的系統研發，把一些紛亂複雜的系統去除，選用PROMETHEUS系統作為我們的基礎。
監測數據的分析和統計
第三個是用監測系統做分析，對之前割裂的信息進行空前的聚合，我們可以基於這些海量的數據做大數據分析，例如對容量的動態擴速容的評估。
研發和運維共同合作階段
第四個階段是研發和運維合作的階段。把研發和運維密切結合起來，PROMETHEUS 的特性是可以從研發側接入到運維的監控平臺，提供有力保障，可以用不同的開發語言來作為買點。
站點可靠性建設
第五個階段是可靠性建設。首先說一下 B 站監測平臺的動向覆蓋，bilibili 分為兩個視角。一個是用戶的視角，比如說用戶的視覺感觀有卡頓，從運維上可以反映出一些奇怪的問題。我們需要從中介入，找到問題的根源。另外一個視角，就是運維側發起的監控需求。兩邊同時往中間演進，中間有一些中間件，比如說應用程序買點和其他系統監測，達到一個縱向的覆蓋。
在 2016 年之前，因為 B 站都是用拉維克斯（音），只能做一些基礎監控，像 CPU 、內存等，對於研發的接入成本是比較高的。所以我們的監控覆蓋率就只有大概在 30% 左右，很多業務上的運維都是獨立的。比如說有一些彈幕系統，運維部這邊是完全沒有感知的。
經過大概一年的時間，我們從 2017 年下半年開始對整個系統進行重構，我們用一個比較通用的模式來進入到監控平臺，基本上是基於 PROMETHEUS 的二次開發，把它埋在一個公共框架裡面。到了 2018 年我們的監測覆蓋率大概可以達到 90% 。我們的願景是最終達到 100% 的可以橫向監控覆蓋率。
下面我來說一下，建設海量指標的監測平臺需要什麼。目前 bilibili 的監測是分為兩個團隊兩個技術站，我所在的主要是基於度量值的監控平臺。
首先是多樣化自主接入。不僅侷限在網絡監測，而且從不同的角度來洞悉全局，我們需要一個可靠的數據採集系統。
第二個是各個指標的靈活配置。監測指標全部接進來之後，每種指標的配置規則是不同的。相對來說就是紛亂複雜，無法達到一個有機的整合。
第三個是監測指標可視化。把海量的監測指標有機結合起來，針對某個系統來進行一個集中展示。例如我們對直播的監控，可以統計在線人數，用不同的活動頁來展示，這樣我們可以針對一個特殊的場景來解決問題，例如每半年季的活動。
第四個是告警的調用鏈和洞悉全局。像我個人每天可能要收到4000多條的告警消息，當然不可能一一看過來，所以說我們如何把一些關鍵的消息在最關鍵的時刻推送給關鍵的人，這是比較重要的問題。
整個系統重構之後發生了什麼？
我們系統從選用 PROMETHEUS 之後，我們的數據採集量從原來的 30% 到目前翻了 20 倍。因為 bilibili 的業務比較複雜，有一些海外業務，包括在臺灣、日本，包括在歐洲、美洲都有一些節點，我們的服務器是比較分散的。這就無法滿足我們的監測需求，所以說我們必須採用分佈式場景來做。當然網絡監控目前也是統一到PROMETHEUS 這邊來。
這裡就介紹一下我們的可視化監測平臺。我們把所有的服務器和應用都掛在一個服務器上，從部門級別分散到應用級別，每個應用級別都有自己對應的系統。我們的監測系統不會直接把告警人寫在裡面，包括監測系統的規則配置等所有系統，都和這個平臺關聯起來，這樣可以看到，主機名和一些規則配置都是基於我們這個概念來做的。
這是我們的監測平臺事件中心。對每天產生的事件，有告警認領和簡單統計的功能，你可以對告警屏蔽一段時間甚至進行進一步操作。當然每個告警都有它的級別，不同的級別告警頻率也是不同的。目前來說，我們定了五個級別。比如 P0 級會通過電話、短信、企業微信三個渠道發送到具體接收人。P1 級別可能只有短信和企業微信，而 P2 級別，是目前最多的，一般來說都是通過企業微信來發送。P2 以下的 P3、P4、P5 都是通過郵件來發送。因為有些告警並不是致命性的問題，所以說我們會在週末對它進行靜默。因為告警太多，所以說很多運維人員不想在週末接收到這種非致命性告警，所以我們在週末會把一些級別下調，調到 P3 左右。這裡可以看到，每天的告警量最高在 2000 左右，平均一天大約在 1500 條左右。
這是我們可視化的監測平臺 METRIC 管理。在用了 PROMETHEUS 以後，我們原則上不添加新的 METRIC，不同的 METRIC 之間肯定是不到 1000 個，包括一些中間的，還有一些個性化的埋點。
這個是我們的可視化監測平臺。其中定製化的不多，稍微改了一些界面。
這是可視化的監測平臺中的告警配置。我們目前的告警可視化後端，都是 PROMETHEUS。下面是它的查詢語句呈現出的圖形，上面是一些篩選的條件。
這是我們可視化監測平臺的首頁。其中包括時鐘、基礎監測，以及網絡方面的信息。它是分幾個級別，包括基礎側、中間件、應用側，是我們根據主站的調用關係、外部鏈路的首超時、冗段這些數據，來進行不同的級別分層。目前我們所有的監控平臺都是基於這個來做的。
下圖是監控模板和它的一些配置，主要是數據的展示。
下圖是我們的彙總，它可以看到每臺機器的 QPS，找到一些關鍵的指標和相關的負責人。
與很多互聯網公司不同，bilibili 採用的是一個大運維體系。從 2015 年做運維開始，我們所有的監控都是統一的整合，很多都是研發提供給我們的。所以我們來比較瞭解一下，研發大概需要什麼樣的運維監測系統。
· 海量數據檢索能力
不管是基礎監控，還是研發埋點的上報數據，都需要一個統計的數據檢索，這個 PROMETHEUS 就完全能滿足需求。
· 故障的發現能力
因為研發的所有數據都已經上報了，研發這一側完全沒有監控能力。所以整個監控的壓力全部壓在技術平臺這邊，所以我們對每一個監控都要有及時發現的能力，把它反饋給研發。
· 高度自由化的系統
作為一個平臺建設者，我們的系統並不處在人肉運維的階段。比如配置一個複雜的告警，每天可能有十幾個研發從早到晚找你，並不能夠滿足大量的需求，所以說我們需要一個高度自由化的系統。
目前來說，我們這一塊做得還是不夠。因為這裡所有都是基於 PROMETHEUS 來做的，就無法滿足如計算冗段的值數據複雜的一些複雜場景。如何解決這個問題，當然會成為我們今後工作的重點。
· 使 SRE 的落地成為可能
因為 bilibili 是主推 SRE 的，目前公司有大概十個平臺全部是做這個的，所以站點可靠性建設是一個長期的過程，光靠運維或者研發一方的各自努力是不行的，必須進行合作共贏，需要一個大強度的整合。
擋在我們新一代監測系統之前的幾座大山
第一座大山-配置複雜的問題
儘管 PROMETHEUS 提供一個很強大的查詢系統，但有一定的學習成本，如果有相對複雜的告警配置，一般需要專業的工程師才能完成，無法完全下放研發。
第二座大山-平臺的擴展能力
原生的 PROMETHEUS 並沒有很好的企業級解決方案，並且不支持集群化，所有都分散在各個機房，PROMETHEUS 的機房也比較複雜，首先有 IDC，也有海外的公有云和自己的私有云，基本上是一個混合雲的架構。所以說我們的 PROMETHEUS 不支持集群化方案，我們必須在不同的環境去部署 PROMETHEUS，每臺系統之間都是無法有效集合在一起。也就是你要查一個數據，可能首先要知道這個數據在哪個雲上，業務在哪裡，才能查詢到，所以說這是一個比較麻煩的問題。
第三個座大山-告警的智能化
這個問題主要是如何應對告警公報。如果每天收集到 4000 多條消息，這些消息是完全沒有價值的，你根本不可能一條條看過來。我們目前是採用一個打標籤的方式，也在研究一些機器學習的算法，來把它應用到一個告警平臺裡面去，可以對相同內容的告警進行一些智能的聚合。
配置 18000 行監測告警的痛苦
在這種情況下調配，我們一般來說是安排兩個運維工程師坐班不停地跟研發配告警規則，如果是相似的可以做到一些程序化，如果有一些特殊的需求就無法滿足了。
告警配置自主化下放是目前我們是和友商合作進行的，對我們所有的配置文件進行圖形化的配置，可以基於一些標籤，用服務器進行篩選，然後對服務進行篩選。因為所有的監控都在我們這邊，所以說你們會看到形形色色的監控。
原生的 PROMETHEUS 是不支持告警的，如果這邊告警斷了以後你是無法察覺到，就是你告警是完全報不出，你不知道它的數據。這邊是一個配置，就是把所有的配置做成圖形化。
目前我們把這些配置下到研發，大概有 300 多個研發，完全讓他們自主化配置，可以對它進行一些靜默操作。
下圖是一些複雜告警配置。比如說一個主站的監控，可能要監測到設備耗時，是一些第三方組件的耗時，所有的服務都是在我們這個平臺上託管。等於我們現在把所有的監控通過這個平臺下放給研發，讓研發可以自主配置。
下圖是一個複雜告警配置。像這樣的語句是計算 HTDP 錯誤碼佔比，正常情況下應該是有一定比例的，當超過一定的比例以後我們就要發出告警。假如你要寫 PROMETHEUS 的告警語句，是相當複雜的，如果你是沒有受過專業學習的普通研發，可能這個語句都寫不了。所以說我們目前會有一個運維人員把具體的語句寫好，再在平臺上創建一個指標，普通的人只要針對這個指標過濾一些方法、UIL，來決定到底哪個 UIL 需要報警。用這樣的方法，就解放出我們很大的工作量。
下圖是我們 PROMETHEUS 的企業解決方案。這可以基本上把擋在我們面前的三座大山解決，可以提高我們研發 PROMETHEUS 的很多潛力，包括一些告警策略可視化、監測指標白名單等等都是可以完善的。
針對告警配置無法下放和 PROMETHEUS 的企業平臺化問題，我們通過和 OPSMIND 合作，使得 bilibili 基於 PROMETHEUS 的企業級監測方案獲得了很大的提高，成功縮減了人力成本，提升了平臺的交付能力，同時也夯實了間系統的工程強度，為後續基於監測數據大數據分析和 AIOPS 的實施提前掃清了障礙。目前使用 11 臺服務器分佈式環境承載 1 億條時序指標，成功解決了原有系統的性能和容量問題，將兩名配置專員從日常的機械性工作中解放出來。
原來 PROMETHEUS 一個簡單的告警可能要反覆寫，目前通過抽象以後，可以把原來 10 萬行的告警配置通過優簡化大概到 300 條左右，因為這些都可以通過標籤來選擇了，而不需要創建新的，這樣就降低我們維護的勞動成本。平均每天我們需求方之前大概需要 120 人次，由人力輸出變成一個服務型輸出，響應時間也大大縮短。
下圖是 PROMETHEUS 的整合方案。我們的數據通過不同的結構上報到 PROMETHEUS以後，會有一些自己的外部系統來進行 PROMETHEUS 的數據展示。同時這是一個雙寫過程，把這個數據拷貝一份，上到我們 PROMETHEUS 平臺，和外部系統的一個展示功能，通過這邊可以做一些告警。對整個系統是無損的，對我們架構來說用不著太大的改進。
海量監測平臺的建設任重而道遠，我覺得可以分為下圖所示的四個階段。
首先是初級階段。B 站的運維起步比較晚，從 2015 年開始，所以很長一段時間我們都是處在初級階段。
入門階段是 2015 年到 2017 年之間，通過整合所有監測系統，引入 PROMETHEUS 監測方案來統一。目前我們通過和友商的合作，把一個複雜的告警配置完全下放，我們自身只是專注於平臺化建設。例如海量的 PROMETHEUS 探測目標的管理。
接下來是高級階段。我們目前所用的，都是一些業務系統上淘汰下來的，所以說高可用的幾乎沒有。做好平臺的高可用、消除單點故障，是這個階段的關鍵。一個機房可能只有一臺 PROMETHEUS ，如果一個掛了，整個機器在監控平臺機房就會掛掉。一旦發生了致命性故障，其實並不會影響到生產系統，所以說隨著我們的數據不斷接入，我們的重要性越來越高，我們需要一個高可用消除單點故障。
最後是一個智能運維階段。因為監控本身是有規律的一些數據，我們可以基於這些做一些大數據分析，進行一個整合，這樣我們就可以從繁重的勞動中解脫出來。
以上就是我演講的全部內容，謝謝大家！
閱讀更多 七牛雲 的文章
