線上公開課 | 京東雲監控系統設計及落地之路 京東雲技術新知

談運維為什麼離不開監控？典型監控系統一般是如何設計的？業務驅動的高可用監控系統又有何不同？作為巨頭之一的電商平臺京東， 其基於京東雲的監控系統是否有值得借鑑的地方？本文將解答這些問題。本文整理自 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 可以應用到各個模組中，不但能夠實現很強的能力複用，還能簡化系統設計。站在資料的視角上，將監控系統理解為一個資料處理系統，會有助於更好的理解監控系統。

那麼從資料視角分析監控系統，還需要優先考慮以下這幾個部分：

1、資料模型先行，不同模型代表著不同的資料描述及處理能力，進而會對監控產品的形態產生影響

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

2、監控採集就是資料標準化的過程

如果是用 Agent 資料傳輸的方式，首先要考慮就是 Agent 穩定性，也就是資源消耗的問題。從 CPU、記憶體、磁碟等都需要做一些限制，保證 Agent 有確定性最大資源消耗。

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

為了滿足讀寫正交要求，業界一般採用列式儲存作為主存，如 Hbase、Cassandra，滿足監控查詢按照標籤做靈活檢索，一般採用倒排儲存 meta 資料，這樣可以實現類似百度透過標籤篩選指標，監控資料有最新值查詢的需求，所以採用基於 Gorilla 的快取。所以京東雲的 TSDB 選型方案為 Es+Cassandra+Gorilla。

4、聚合計算就是對資料進行範圍圈定，進行運算元處理

資料另外一條流加工常見的是聚合計算，比如有 3 臺 Nginx 程式，部署在 H1、H2、H3 機器上，需要把這三臺機器的 PV 加起來，這個就是聚合計算，而需要把 PV 在 httpCode=2xx、3xx 進行展開，則稱為多維度聚合計算。

要實現這個目標，從資料視角看，首先需要做範圍圈定，也就是 H1、H2、H3 為什麼是在一起計算？這就需要透過標籤進行關聯。範圍圈定後進行資料的運算元處理，比如常見的 sum、min、max、avg 運算，資料量級不大的情況下，可以讓儲存模組完成，但當資料量級較大，一般會傳送給流式計算平臺。京東雲選擇是用 Spark Streaming 來計算，為了保證穩定性，京東雲設計了對流式計算的排程能力，分機房部署了 Spark 計算叢集，透過一個 map，指定排程，比如把 Nginx 應用放到 SparkA 進行計算，MySQL 應用放到 SparkB 進行計算，這樣，當某個 Spark 出現問題，也能快速做排程止損，定位恢復另一個叢集。對於重型開源系統，設計實現的時候，可以考慮在前面加一層 Proxy，將開源細節封裝起來，這樣當出現異常時，會有較強的掌控能力。

5、報警通路做好“質檢員”工作，同時完成通知使用者這件事情

告警通路的作用其實是質檢，透過抓取資料做檢查，發現問題就及時報警。從資料視角來看，報警通路作用歸納到兩類，一是時序資料處理，可以依據基於經驗的演算法，比如簡單閾值、同環比等，如果這些方法解決不了，就嘗試基於統計的機器學習演算法。二是為了讓通知更加有效，京東雲目前的思路是事件的標籤化，支援對告警事件進行合併，比如：使用者透過標定告警級別，選擇不同的告警方式和時效性，按照環境合併告警。

“監控需要覆蓋基礎 - 存活 - 效能 - 業務四個層面，從而保證採集資料的全面，進而避免監控遺漏。”

在京東雲監控標準設計上，基礎監控這一層主要解決機器、網路層面的問題，包括 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點有簡訊、電話告警；如果缺失了，那就表明監控系統有問題。