DevOps專題 | 大型企業級監控系統設計

10月30日，全球權威資料調研機構IDC正式釋出《IDCMarketScape: 中國DevOps雲市場2019，廠商評估》報告。京東雲憑藉豐富的場景和實踐能力，以及高質量的服務交付和平臺穩定性，取得優異出成績， 躋身“Major Players”（核心廠商）位置。
京東雲DevOps能力起源於自身的業務實踐，針對京東集團的複雜業務場景打造並經受住多次618、11.11電商大促的嚴峻考驗，保證了高效高質的交付和對變化的靈活應對。能夠支援複雜場景的自動化運維需求、實現工具鏈產品與平臺化產品結合，幫助客戶根據不同的需求靈活定製方案。

為了讓大家更深入的理解devops，瞭解京東雲devops具體的落地實踐以及如何提升效率與保障穩定性，進一步結合自身業務設計實施devops。我們第一期將會重點為大家介紹DevOps中的監控部分，透過了解京東雲自己的企業級監控是怎麼來設計的，來更好地理解監控系統的樣貌。

監控目標

監控是運維的生命線，其目標是快速的發現問題、定位、止損（see->know->act），縮短異常MTTR，為了達到這個目標，期望監控系統具備：

• 豐富的資料採集能力，能對監控物件能進行深度觀測。

• 靈活的資料加工能力，比如把相關的資料匯聚起來，得到我們需要關注的核心資料。

• 異常檢測能力，從最簡單的閾值判斷到各種異常檢測演算法，教會機器看懂是不是出現異常了。其本質上也是一種對資料的加工能力。

• 收到異常之後，可以透過dashbord、趨勢圖進行問題定位，即資料的展示能力。

• 如果做的更加深入，可以有根因推薦平臺，把最近的變更、關聯的告警做一些推薦，加速定位的過程。

• 問題定位完成之後，期望把運維處理的經驗沉澱下來，這樣就形成了預案平臺，便於更加快速的止損。

• 當然，最重要的，一個好的監控系統需要具備高可靠性，本身監控系統就是為了發現異常，監控自身程式掛了，沒有

  人知曉肯定是不行的，這就引申出來了，監控系統的監控怎麼做的問題，可以當做一個發散的問題，大家考慮一下。

監控標準

介紹完監控目標和監控系統應該具備的功能點後，先不討論監控系統如何實現，首先回答一個問題，如何確認監控加全了？有沒有遺漏？

估計很多同學會遇到這樣的問題，為此，京東雲提出了一套監控標準，指導使用者新增監控，確保監控“加全”，避免遺漏，詳情如圖所示。

監控標準分為四層，從下往上看：

• 首先是 基礎監控，這一層主要解決機器、網路層面的問題，包括我們常見的cpu、記憶體，機器當機等問題

• 然後是 存活性監控，解決程式部署到機器上後，是否存活的問題，比如程式退出，埠傳送一個ping過去，沒有返回pang

• 再上一層，則是 效能監控，重點關注Google提出的四大黃金指標pv、平響，錯誤碼和容量等，解決分散式程式的定界問題（比如透過訪問MySQL的時間飆升知道是下游MySQL的問題）

• 最上層是 業務監控，模擬使用者進行訪問，解決服務在使用者側的表現是什麼
  有了標準，設計的監控系統按照標準來落地，可以給出一些資料化的運營指標，推動監控的完善。

典型監控系統設計

瞭解了監控目標和定義了監控標準，相當於對解決的問題域有了一些背景知識了，下面就大概介紹下典型的監控系統包含哪些功能模組，本文只是做一個大概的介紹，後續會對不同模組方向有一些專門的介紹。

上圖還是分為四層，從下往上我們依次來介紹：

最底層叫 資料抽象層，大家可能看到了比較熟悉的詞語是CMDB，這一層把資源視角抽象為運維&運營視角，比如你搭建了一個賣書的網站，用了nginx、mysql等程式，在資源視角，這是一臺臺機器執行在互聯的idc環境上，但可以抽象成這是一個賣書的產品，有mysql、nginx等應用，這樣你的監控資料自然可以附加這種屬性（標籤），最終在後續資料處理的時候可以發揮作用

有了資料抽象層，統一了我們對監控實體的認知，基於這個抽象；上一層就是 資料採集層，這裡列舉了眾多采集方式，包括程式、日誌、自定義、介面pull、產生資料主動push等，整個資料採集，就是一個標準化的過程，把觀測物件的資料透過各種手段收集上來，轉換為我們監控系統定義的資料格式。

資料採集後，就是 加工的過程，我們再回憶一下，監控的目標是發現、定位、解決問題；那麼必須對資料做加工，這就又可以分為以下處理流：

• 左邊這條進行了資料加工（聚合計算），比如把10臺nginx的pv累加起來；而且可以按照各種維度（標籤）累加，常見的需求包括監控項自身的標籤（比如pv的狀態碼為5xx的聚合）；也包括監控物件的標籤（比如某個機房的pv累加起來），監控系統需要具備這種靈活的資料加工能力。

• 中間的一路進行了資料儲存，便於趨勢圖、dashbord能夠檢視到；有很多問題，還是需要靠人工經驗去做判斷。這裡面會要求儲存具備各種查詢的能力，比如sum、max、min、avg、topN、分位值等。

• 右邊一路則是報警通路，進行異常檢測，教會機器怎麼看圖，辨別出哪些指標有異常；一般是先做運算，比如發現某臺機器的記憶體低於閾值了，然後會有一個模組去做收斂以及一些干預（比如遮蔽/升級等），最後確定要通知人員處理了，對接不同的告警方式（郵件、簡訊、微信）。

• 當然還有一些離線挖掘，根因推薦，這些資料處理最終的目標還是能夠讓機器識別更多的異常、透過經驗/演算法，找到‘根因’

資料處理之後，最終是讓人去使用的，最上層就是資料的 展示層，要展示對使用者有效的資料，使用者透過資料能快速發現定位問題，並透過資料分析及時做出止損操作。也就是要讓資料更好的服務使用者。

綜上，我們可以瞭解到，監控系統是以資料為中心，在資料之上擴充套件其處理能力的一個系統；後續我們會對各個方向再進行深入的介紹，歡迎和各位進行交流。

IDC中國企業軟體市場高階分析師王楠認為：“京東雲DevOps能力源於自身業務實踐，是京東技術能力輸出的重要組成部分，儘管推出相對較晚，但發展速度快、成熟度高，工具鏈和平臺功能已基本涵蓋DevOps的主要流程階段。同時，京東雲DevOps平臺還與公有云平臺深度整合，不僅極大提升了服務交付效率和穩定性，還能高效助力使用者的自動研發和運維。”