監控是運維的生命線，監控系統的目標是通過快速發現問題、定位問題、解決問題來達到縮短異常出現的 MTTR，在這方面，京東云定義了一套統一的監控標準：即監控需要覆蓋基礎 - 存活 - 性能 - 業務四個層面，從而保證采集數據的全面，進而避免監控遺漏。
談運維為什么離不開監控？典型監控系統一般是如何設計的？業務驅動的高可用監控系統又有何不同？作為巨頭之一的電商平臺京東， 其基于京東云的監控系統是否有值得借鑒的地方？本文將解答這些問題。本文整理自 10 月 30 日由京東云開發者社區和英特爾聯合舉辦的在線公開課，京東云工具產品研發部專家架構師顏志杰的在線課程演講——業務驅動監控系統設計與落地。
1 為什么需要做監控
世上沒有百分百可靠的系統，程序、機器、網絡都可能在運行中出現問題，進而導致服務異常, 帶來金錢及品牌的損失，所以監控目標就是降低損失，通過發現、定位、解決問題，期望縮短異常出現的 MTTR （平均修復時間）。
要達到這個目標，監控對象必須具備可觀測性，即通過數據描述是否出現異常，這些數據包括指標監控 Metric、日志 log 和 Trace 數據。
為了實現縮短 MTTR 的目標，監控系統應該具有這些能力：
- 數據采集能力，獲取可觀測的數據
- 數據能夠方便加工，比如把相關的數據匯聚起來，得到我們需要關注的數據
- 對這些關注的數據，做異常檢測，及時產生告警
- 收到告警后，通過 Dashbord 查圖定位，最好有專家推薦，加速定位
- 定位問題后，通過預案平臺進行快速止損
- 整個監控系統需要做到高可用，監控就是為了發現異常，如果由于異常導致自身不可用，肯定是減分的
2 從功能模塊來分解監控系統
“典型監控系統從功能模塊分為采集、計算、存儲、告警、算法、業務端等。 ”
從下往上來看，首先是抽象層，包含 CMDB（配置管理數據庫），抽象了我們對監控對象的定義，比如定義了應用、機器、域名、網絡等，比如確定監控系統里面機器到底是用 IP 還是 Hostname。采集層包含眾多采集手段，包括機器、容器、進程、日志、端口等，可以通過 Agent 數據傳輸，或者外部探測點定期拉取，也可以用戶直接通過 API 推送進行數據采集。
數據采集后，分為三條數據流處理：計算、存儲、告警，計算即進行數據加工，如聚合計算把 10 臺 Nginx 的 PV 累加起來；數據存儲便于 Dashbord 能夠查看；報警通路進行異常檢測，快速發出報警。上層計算平臺基于智能算法對異常或者故障的根因進行分析，進行根因推薦，輸出專家輔助定位。最終到達用戶層，提供用戶常見的監控功能點：監控配置維護、告警處理、預案管理等。
3 從數據的視角來分解監控系統
“從數據視角去理解，監控系統就是一個數據處理系統，便于我們簡化系統設計以及更好理解監控系統。”
從數據的視角來分解監控系統，同樣分為四層，上圖嘗試用不同顏色、形狀的圖形去說明采集、計算、存儲、告警等模塊在數據視角的功能。 打比方說： 數據抽象層，即把監控數據被抽象成是各種形狀、各種顏色的模塊，數據采集就是標準化過程，把各種形狀顏色的數據用統一的方式表示，比如上圖用一個云的形狀把各種圖形框起來；聚合計算就是對同一標簽的數據做聚合處理，比如上圖按照顏色來聚合，存儲流把相同的形狀顏色順序擺好，告警則是挑選出有紅色框的數據（上圖表示異常數據點）。所以，無論是采集、聚合、存儲、告警還是查看 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、報警通路做好“質檢員”工作，同時完成通知用戶這件事情
告警通路的作用其實是質檢，通過抓取數據做檢查，發現問題就及時報警。從數據視角來看，報警通路作用歸納到兩類，一是時序數據處理，可以依據基于經驗的算法，比如簡單閾值、同環比等，如果這些方法解決不了，就嘗試基于統計的機器學習算法。二是為了讓通知更加有效，京東云目前的思路是事件的標簽化，支持對告警事件進行合并，比如：用戶通過標定告警級別，選擇不同的告警方式和時效性，按照環境合并告警。
4 京東云的監控標準設計
“監控需要覆蓋基礎 - 存活 - 性能 - 業務四個層面，從而保證采集數據的全面，進而避免監控遺漏。 ”
在京東云監控標準設計上，基礎監控這一層主要解決機器、網絡層面的問題，包括 CPU 、內存、機器死機等問題。存活監控層主要解決程序部署到機器上后是否存活的問題，比如進程退出、端口不工作等問題。應用性能監控層解決程序異常定界的問題，重點關注 google 提出的四大黃金指標 PV、平響，錯誤、容量。最上層業務監控，模擬用戶進行訪問，解決服務在用戶側的表現是什么。
那么如何按照監控標準去指導監控產品的落地呢？看京東云如何從發現問題、定位問題和解決問題三個方面來減少 MTTR：
在發現問題階段，分別面向管理者和運維人員設置監控系統的打分機制及推薦系統，給予管理者一個直觀的總分和每個維度的細分得分，使得管理人員對整體監控有個量化的指標，另一方面，對于運維人員，則提供配置推薦、一鍵啟用，可以快速地根據標準去完善監控，達到監控變‘全’。
在定位問題階段京東云推進了變更可視化項目，將上線、配置更改、第三方的變更事件，都接入到變更事件中，用戶可以根據時間去查詢時間段的變更，跟報警做關聯，京東云也會根據一些相關性的算法推薦，將變更推薦給用戶，加速問題定位過程。
處理問題階段京東云可提供預案平臺，對預案進行標準化分類，指導用戶管理預案。
5 京東云落地實踐：以監控告警收斂項目為例
在監控告警上，運維人員往往在提升告警手段上做了很多工作，比如說通過發郵件的形式到短信、電話的形式等，京東云每月短信發送量 200w+、電話告警每月 4000+，但是運維人員并沒有感受到有這么多問題，這就說明告警關注度是下降的，所以告警收斂勢在必行，目標就是讓告警關注度提升，那如何落地呢？
這就需要首先數據量化，先統計各個渠道的告警總數，然后分兩步走，對于產品線負責人，需要讓產品線的負責人知道自己部門的情況，另一路出分析數據，拆解產品線發送多的原因，給運維同學提供數據指導，分析各種有可能導致發送告警多的原因，如：一條短信平均接收人、哪些告警規則發送較多等。
基于這些統計數據，監控團隊去成立告警收斂項目：在面對接收人過多的情況（一個短信原來需要 10 幾個人接收），京東云推出值班表計劃，在產品設計上保證告警規則設置的合理性，對于一些大規模觸發情況，比如網絡故障，京東云默認會按照規則、應用進行合并，同時為了在合并之后讓用戶能看的更清楚，京東云也推出了移動端程序。
面向未來，顏志杰老師說：“數據處理原來基于規則和經驗解決了不少問題，后續疑難雜癥會慢慢嘗試基于統計和大數據的機器學習，因為效果更明顯。在數據收集方面，由于云原生的興起，常見的可觀測數據將會變得更加標準化，而對于一些非結構化的，比如日志，會有機器學習的算法去幫助語義理解標準化。在數據處理層面，對于單數據的處理，我們去判斷比如一條曲線的動態閾值是什么樣子，很多公司已有不少實踐，未來多數據之間的聯動處理，會更加有意義，比如一個域名告警了，如果同一時刻其他部門域名大規模告警，那么平臺或者網絡的可能性較大，否則應該是自身的原因較大，越來越多用大數據的思想分析多指標數據將會更加普遍。同時數據處理方面，Trace、log、Metric 之間的關聯將會越來越智能，準確，最后數據驅動整體閉環，未來，監控將會在數據的大道上，通向 AI 化，智能化。”
