一、監控系統分層
由於早期B站高速發展，巨石架構基於CMS系統搭建，導致代碼紊亂。
從研發角度切入，來分析監控系統。
1. 業務層：監控系統需要關注業務指標，如攜程網的酒店下單量，大眾點評、唯品會的商品購買指標、實時業務，B站的註冊成功率等。
2. 應用層：
（1）端監控，如：河北地區APP無法打開，需要通過端採集數據上報，查找原因；
（2）鏈路層監控（APM監控），如：唯品會跟蹤訂單的完整交易流程，或是完整調用鏈路，查找異常；
（3）日誌監控，通過回溯舊日誌，瀏覽TLF等，發現異常。
3. 系統層：關注網絡、AOC、CDN的質量，關注中間件、數據庫的問題等。
早期B站僅有Zabbix系統，監控思路是從下往上，效率低下。基於上述監控分層，對B站進行監控系統改進。
二、B站監控系統的演進
（一）B站監控系統改進步驟
1.編寫ELK日誌分析系統，讓研發人員有日誌可看，不用重複登錄系統查看；
2.將巨石架構逐步轉變為微服務化架構；架構轉變之後，我們發現系統發生問題時，很難定位Root cause。
3.基於谷歌的Dapper編寫監控系統，用於快速查找問題；
4.編寫負責PC端、移動端鏈路上報的Misaka系統，監控運營商信息；
5.編寫Traceon系統，關注業務指標和異常監控，將業務指標報表輸出給內容、產品同事，把敏感的變更告知監控系統報警。同時將監控報警短信、郵件，發送給 運維、開發，甚至運營、客服和產品同事。
（二）如何通過監控入口，研發找到系統問題
B站的內部指標：在登錄運維繫統後，核心業務與非核心業務發現故障的時間分別為5分鐘之內和20分鐘之內。
監控入口類別：
1. 大盤
變更：大部分故障是由於變更（發佈、修改配置、版本更新）引起的，大盤是看到整個變更的試件，做出變更防禦進行動作收集。
失敗率
全鏈路
2. 前段：通過提供端，進行服務的服務質量監控；
3. 異常：對失敗率、異常彙總統計入口；
5. 鏈路：方便查詢特定業務鏈路情況；
6. 系統： 核心網絡、CDN、IDC等；
通過以上六個監控入口不同職責的人員，找準自己所屬入口，進行監控，發現問題解決問題。
（三）將監控系統化整為零，分而治之
把監控系統全部打通到一個系統裡是非常困難的，所以需要把監控系統化整為零。
那麼如何串聯如此多的監控系統？
借鑑谷歌的traceid，使用traceid把包括日誌、鏈路、HDB接口，前端等在內的全業務系統串聯起來，通過Skyeye發現問題，address定位問題。比如：某次B站首頁發生故障，前端上報traceid到Misaka，Misaka標紅後，研發人員發現故障原因在於ELK。
從研發的角度來說，當監控系統發現故障時，需要及時做出正確報警和報警規劃。
1.正確報警：避免誤報，做到好的收點。
2.報警規劃：比如當核心機房出現問題時，大量接口全部報警，這會影響運維人員判斷。需要通過智能報警，自動匯聚一個完整的ELK。
最後總結一下：做好一套監控體系，需要將它拆分成數個小系統，化整為零。通過traceid、address等關聯起來，分而治之。
（四）Dapper系統
早期B站包含多種語言，機房分佈在多個地方，系統非常複雜。
後來B站參考谷歌Dapper，發現完整請求是一個樹型調用，會記錄在系統中完成一次特定的請求後所有的工作信息。只需要在公共組件中植入代碼就可以做到。
Dapper採樣率為抽樣採樣。
多數系統是全量採量，但是谷歌內部更傾向抽樣採量。B站Dapper也採用抽樣採樣，如果系統發生故障，一旦出現，之後必然會再次出現，抽樣採樣命中率很高。B站內部也採用多種採樣方式（固定採樣1/1024、可變採樣、可控採樣），這種做法，對於網絡、存儲的壓力也較小。
舉一個代碼實例：HTP請求，發生攔截。服務器請求中加入這種注入後，可以非常方便的採集到埋點。
加入之後，在編寫完整的鏈路後，推動其他業務部門使用，可以繪製出一個完整的依賴關係。
天貓雙十一時，需要花大量的時間進行整體架構梳理。但是如果依靠上文的依賴圖，思考在全鏈路上架構存在的問題、熱點、瓶頸，可以避免架構出現重大錯誤。
通過推動依賴方、業務方，接入事業部之後，十分容易便可以將公司大部分的鏈路繪製出來。比如說：B站的業務重點依賴瓶頸熱點，我們只需要按區域、用戶數量這個概念來完成多機房、機房內的單元化部署。通過APM系統，推測出問題。
如何使用Dapper系統定位問題？
如果一個接口耗時最久，那它就是最需要推進業務方改進的地方。從客戶端開始到服務端接受，是一個網絡開銷，到服務器處理完成之後回包給客戶端，Dapper系統可以藉此計算出網絡耗時。
通過Dapper系統搜索某個項目、接口、時間段，進行抽樣採樣，得出這個部件每分鐘的數據量、耗時。
（五）Lancer系統（以FATE系列槍兵庫·丘林命名）
早期B站具體部署到Docker、虛擬機、物理機的業務服務都需要日誌打包。但是收集日誌的過程不可控，小包數量大，容易丟失。
後來B站進行優化，部署了Log Docker通過進程類通訊上報，並將小包集合成大包後發送，再使用Lancer系統分發。
打開web界面，選定service，點擊按鈕，Lancer系統會自動發現這個行為，確定採集地點。最後，將採集日誌放到ES上和Lancer的商業存儲。
通過syslog、log-agent、sys-agent，最後Kafak進行數據緩衝。B站默認會支持Kafak、ES等比較通用的節點。
上圖是Kafak的後端緩衝，由agent完成日誌分解工作。Dapper系統的工作流程也類似於此，通過業務服務進程埋點。通過定製搜索需求，將數據鏡像一份至ES，暴露Dapper的API，最終通過APM平臺查閱其完整請求。
（六）Misaka系統（以超電磁炮御坂美琴命名）
Misaka作為端監控。需要移動端或PC端在前端埋點，將埋點數據上報，以此檢測故障。
就像上圖，南京某節點可能出現了DNS劫持或流量劫持。
我們無法解析出詳細信息，但是現階段解析出的內容是HTML，以此判定是流量劫持。通過此類事情，才能真正瞭解客戶端的情況和服務質量，推進HTTPS協議的使用，架構的演進。
（七）Traceon系統（以衛宮士郎投影魔術命名）
Traceon系統通過埋點，進行業務指標和異常收集。它可以通過代碼提前定義部門性質，比如：A部門的某個指標上報完成後，Traceon系統會通過原數據查詢“它是否被註冊過？”如果沒有被註冊，系統就會完成創建。訂單量的大量增加是在Redis中做遞增，不斷將其累加，再定期回刷至mysql。
上圖是B站某商城中的Traceon系統界面。它可以發現某些地方出現的峰值、問題。通過報警規則，把信息發給報警系統，通知具體人員來處理它。
三、監控系統展望
監控系統的各個子系統更加獨立完善，各司其責；
更完美的Dashboard。Dashboard、報警機制都更加準確；
更加完善的監控流程和Oncall機制。
https://zhuanlan.zhihu.com/p/34743584
閱讀更多 高效運維 的文章
