在線公開課 | 京東雲監控系統設計及落地之路

 

談運維爲何離不開監控？典型監控系統通常是如何設計的？業務驅動的高可用監控系統又有何不一樣？做爲巨頭之一的電商平臺京東， 其基於京東雲的監控系統是否有值得借鑑的地方？本文將解答這些問題。本文整理自 10 月 30 日由京東雲開發者社區和英特爾聯合舉辦的在線公開課，京東雲工具產品研發部專家架構師顏志傑的在線課程演講——業務驅動監控系統設計與落地。

世上沒有百分百可靠的系統，程序、機器、網絡均可能在運行中出現問題，進而致使服務異常, 帶來金錢及品牌的損失，因此監控目標就是下降損失，經過發現、定位、解決問題，指望縮短異常出現的 MTTR （平均修復時間）。

要達到這個目標，監控對象必須具有可觀測性，即經過數據描述是否出現異常，這些數據包括指標監控 Metric、日誌 log 和 Trace 數據。

爲了實現縮短 MTTR 的目標，監控系統應該具備這些能力：

1. 數據採集能力，獲取可觀測的數據
2. 數據可以方便加工，好比把相關的數據匯聚起來，獲得咱們須要關注的數據
3. 對這些關注的數據，作異常檢測，及時產生告警
4. 收到告警後，經過 Dashbord 查圖定位，最好有專家推薦，加速定位
5. 定位問題後，經過預案平臺進行快速止損
6. 整個監控系統須要作到高可用，監控就是爲了發現異常，若是因爲異常致使自身不可用，確定是減分的

「典型監控系統從功能模塊分爲採集、計算、存儲、告警、算法、業務端等。」

從下往上來看，首先是抽象層，包含 CMDB（配置管理數據庫），抽象了咱們對監控對象的定義，好比定義了應用、機器、域名、網絡等，好比肯定監控系統裏面機器究竟是用 IP 仍是 Hostname。採集層包含衆多采集手段，包括機器、容器、進程、日誌、端口等，能夠經過 Agent 數據傳輸，或者外部探測點按期拉取，也能夠用戶直接經過 API 推送進行數據採集。

數據採集後，分爲三條數據流處理：計算、存儲、告警，計算即進行數據加工，如聚合計算把 10 臺 Nginx 的 PV 累加起來；數據存儲便於 Dashbord 可以查看；報警通路進行異常檢測，快速發出報警。上層計算平臺基於智能算法對異常或者故障的根因進行分析，進行根因推薦，輸出專家輔助定位。最終到達用戶層，提供用戶常見的監控功能點：監控配置維護、告警處理、預案管理等。

「從數據視角去理解，監控系統就是一個數據處理系統，便於咱們簡化系統設計以及更好理解監控系統。」

從數據的視角來分解監控系統，一樣分爲四層，上圖嘗試用不一樣顏色、形狀的圖形去說明採集、計算、存儲、告警等模塊在數據視角的功能。打比方說：數據抽象層，即把監控數據被抽象成是各類形狀、各類顏色的模塊，數據採集就是標準化過程，把各類形狀顏色的數據用統一的方式表示，好比上圖用一個雲的形狀把各類圖形框起來；聚合計算就是對同一標籤的數據作聚合處理，好比上圖按照顏色來聚合，存儲流把相同的形狀顏色順序擺好，告警則是挑選出有紅色框的數據（上圖表示異常數據點）。因此，不管是採集、聚合、存儲、告警仍是查看 Dashbord，本質上都是對數據的一些處理、變換操做。

舉個例子，用戶 Dashbord 篩選耗時 >2s 的曲線、和告警模塊篩選出 >2s 告警，對應數據視角是一致的，都是作一些數據計算過濾等。因此，若是咱們把數據的通用處理，過濾轉換、運算表示爲統一通用能力，用 F(x) 表示，那麼在設計監控的時候，把這些通用能力封裝成 .lib 能夠應用到各個模塊中，不但可以實現很強的能力複用，還能簡化系統設計。站在數據的視角上，將監控系統理解爲一個數據處理系統，會有助於更好的理解監控系統。

那麼從數據視角分析監控系統，還須要優先考慮如下這幾個部分：

一、數據模型先行，不一樣模型表明着不一樣的數據描述及處理能力，進而會對監控產品的形態產生影響

以一個 Http 的 2xx 的請求 PV 爲例，用單值模型描述，即經過「監控項名字 + 取值」來描述，這種體驗就跟以下左圖同樣：去地攤買東西，不一樣數據平鋪開來，關聯比較弱；用多維度單值模型，引入了標籤的概念，好比這裏面的 code:200，經過「名字 + 標籤」組合去描述，如中間圖：去超市貨架買東西，同種商品公用一個飲料標籤，如上層是可樂標籤，經過標籤能夠快速找到相關性的衆多商品；而多維度多值模型，如右圖：一次性就可以把你想吃的東西都拿到，一樣還能獲得一些有趣的數據，如商家能夠知道喜歡吃番茄口味薯片的人對銅鑼燒的需求愛好是什麼。類比到監控領域，PV 和耗時放到一塊，而後一塊進行存儲，這樣咱們能夠方便獲取到耗時大於兩秒的那些 PV 是多少，由於他們是存儲在一塊兒的。因此先清楚監控系統的數據模型，對於理解監控系統很重要。

二、監控採集就是數據標準化的過程

若是是用 Agent 數據傳輸的方式，首先要考慮就是 Agent 穩定性，也就是資源消耗的問題。從 CPU、內存、磁盤等都須要作一些限制，保證 Agent 有肯定性最大資源消耗。

三、監控數據存儲具備讀寫正交、meta 的靈活查詢需求，基本上會採用列式存儲 + 倒排 +Gorilla 的方案選型

爲了知足讀寫正交要求，業界通常採用列式存儲做爲主存，如 Hbase、Cassandra，知足監控查詢按照標籤作靈活檢索，通常採用倒排存儲 meta 數據，這樣能夠實現相似百度經過標籤篩選指標，監控數據有最新值查詢的需求，因此採用基於 Gorilla 的緩存。因此京東雲的 TSDB 選型方案爲 Es+Cassandra+Gorilla。

四、聚合計算就是對數據進行範圍圈定，進行算子處理

數據另一條流加工常見的是聚合計算，好比有 3 臺 Nginx 程序，部署在 H一、H二、H3 機器上，須要把這三臺機器的 PV 加起來，這個就是聚合計算，而須要把 PV 在 httpCode=2xx、3xx 進行展開，則稱爲多維度聚合計算。

要實現這個目標，從數據視角看，首先須要作範圍圈定，也就是 H一、H二、H3 爲何是在一塊兒計算？這就須要經過標籤進行關聯。範圍圈定後進行數據的算子處理，好比常見的 sum、min、max、avg 運算，數據量級不大的狀況下，可讓存儲模塊完成，但當數據量級較大，通常會發送給流式計算平臺。京東雲選擇是用 Spark Streaming 來計算，爲了保證穩定性，京東雲設計了對流式計算的調度能力，分機房部署了 Spark 計算集羣，經過一個 map，指定調度，好比把 Nginx 應用放到 SparkA 進行計算，MySQL 應用放到 SparkB 進行計算，這樣，當某個 Spark 出現問題，也能快速作調度止損，定位恢復另外一個集羣。對於重型開源系統，設計實現的時候，能夠考慮在前面加一層 Proxy，將開源細節封裝起來，這樣當出現異常時，會有較強的掌控能力。

五、報警通路作好「質檢員」工做，同時完成通知用戶這件事情

告警通路的做用實際上是質檢，經過抓取數據作檢查，發現問題就及時報警。從數據視角來看，報警通路做用概括到兩類，一是時序數據處理，能夠依據基於經驗的算法，好比簡單閾值、同環比等，若是這些方法解決不了，就嘗試基於統計的機器學習算法。二是爲了讓通知更加有效，京東雲目前的思路是事件的標籤化，支持對告警事件進行合併，好比：用戶經過標定告警級別，選擇不一樣的告警方式和時效性，按照環境合併告警。

「監控須要覆蓋基礎 - 存活 - 性能 - 業務四個層面，從而保證採集數據的全面，進而避免監控遺漏。」

在京東雲監控標準設計上，基礎監控這一層主要解決機器、網絡層面的問題，包括 CPU 、內存、機器死機等問題。存活監控層主要解決程序部署到機器上後是否存活的問題，好比進程退出、端口不工做等問題。應用性能監控層解決程序異常定界的問題，重點關注 Google 提出的四大黃金指標 PV、平響，錯誤、容量。最上層業務監控，模擬用戶進行訪問，解決服務在用戶側的表現是什麼。

那麼如何按照監控標準去指導監控產品的落地呢？看京東雲如何從發現問題、定位問題和解決問題三個方面來減小 MTTR：

在發現問題階段，分別面向管理者和運維人員設置監控系統的打分機制及推薦系統，給予管理者一個直觀的總分和每一個維度的細分得分，使得管理人員對總體監控有個量化的指標，另外一方面，對於運維人員，則提供配置推薦、一鍵啓用，能夠快速地根據標準去完善監控，達到監控變‘全’。

在定位問題階段京東雲推動了變動可視化項目，將上線、配置更改、第三方的變動事件，都接入到變動事件中，用戶能夠根據時間去查詢時間段的變動，跟報警作關聯，京東雲也會根據一些相關性的算法推薦，將變動推薦給用戶，加速問題定位過程。

處理問題階段京東雲可提供預案平臺，對預案進行標準化分類，指導用戶管理預案。

在監控告警上，運維人員每每在提高告警手段上作了不少工做，好比說經過發郵件的形式到短信、電話的形式等，京東雲每個月短信發送量 200w+、電話告警每個月 4000+，可是運維人員並無感覺到有這麼多問題，這就說明告警關注度是降低的，因此告警收斂勢在必行，目標就是讓告警關注度提高，那如何落地呢？

這就須要首先數據量化，先統計各個渠道的告警總數，而後分兩步走，對於產品線負責人，須要讓產品線的負責人知道本身部門的狀況，另外一路出分析數據，拆解產品線發送多的緣由，給運維同窗提供數據指導，分析各類有可能致使發送告警多的緣由，如：一條短信平均接收人、哪些告警規則發送較多等。

基於這些統計數據，監控團隊去成立告警收斂項目：在面對接收人過多的狀況（一個短信原來須要 10 幾我的接收），京東雲推出值班表計劃，在產品設計上保證告警規則設置的合理性，對於一些大規模觸發狀況，好比網絡故障，京東雲默認會按照規則、應用進行合併，同時爲了在合併以後讓用戶能看的更清楚，京東雲也推出了移動端程序。

面向將來，顏志傑老師說：「數據處理原來基於規則和經驗解決了很多問題，後續疑難雜症會慢慢嘗試基於統計和大數據的機器學習，由於效果更明顯。在數據收集方面，因爲雲原生的興起，常見的可觀測數據將會變得更加標準化，而對於一些非結構化的，好比日誌，會有機器學習的算法去幫助語義理解標準化。在數據處理層面，對於單數據的處理，咱們去判斷好比一條曲線的動態閾值是什麼樣子，不少公司已有很多實踐，將來多數據之間的聯動處理，會更加有意義，好比一個域名告警了，若是同一時刻其餘部門域名大規模告警，那麼平臺或者網絡的可能性較大，不然應該是自身的緣由較大，愈來愈多用大數據的思想分析多指標數據將會更加廣泛。同時數據處理方面，Trace、log、Metric 之間的關聯將會愈來愈智能，準確，最後數據驅動總體閉環，將來，監控將會在數據的大道上，通向 AI 化，智能化。」

點擊「閱讀」瞭解京東雲監控系統產品

歡迎點擊「京東雲」瞭解更多精彩內容

---

Q&A 課程問答

Q

報警系統，優先級怎麼處理？

A

告警分級是常見的處理方式，不一樣的告警級別（好比0級1級2級）表明不一樣的處理時效性，通常對於0級的告警的話，須要有對應預案，並按期演練，收到告警以後，應該直接快速進行預案處理，5-10分鐘要進行預案執行完成並check，同時第一時間須要進行上級的通告；1級告警，可能處理的時間要求更寬鬆一點，但好比在30分鐘沒有處理完成，也須要進行上級的通告；2級告警，可能進行按期巡檢，在更寬鬆的時間處理完成便可。因此，不一樣的級別，能夠對應不一樣的通知方式、處理時效性、通告時效性、預案管理等；衡量標準就是異常MTTR對公司形成的金錢或者品牌的損失。

Q

請問監控有專門的團隊嗎？監控團隊 大概是怎麼分工的？

A

其實這邊是在剛開始按照監控模塊分解監控系統的時候，已經給了說明，對於我理解來講，監控的團隊通常分爲採集計算存儲，而後告警，還有算法，加業務端這些模塊，相應的團隊也是這麼去分的，今天想要強調的是，若是站在數據視角，那麼團隊之間的分工就相對比較清晰，你們都是圍繞數據的流轉來協做，採集的數據能夠進行聚合加工，最終進行存儲；告警對加工後關聯的數據作運算，發現異常；業務端則是站在用戶的角度思考怎麼對數據作呈現；因此，若是把數據的處理統一抽象成爲公共模塊或者lib，對於監控系統設計是能極大簡化，同時，不一樣團隊之間也更加緊密。

Q

請問一下監控系統自身的監控是怎麼作的？

A

這是一個好問題，好比說你們業界開源的好比說普羅米修斯，他多是兩個普羅米修斯之間互相去作監控，而後因此說監控系統你確定不能依賴於自身去作監控，通常來講，就是你得有另一個系統去作這個監控。因此好比前面說的prometheus互相監控，達到A掛了B能夠報，B掛A能夠報；另外就是設置一些必然會有的告警，好比每條早上9點有短信、電話告警；若是缺失了，那就代表監控系統有問題。