[持續交付實踐] 多維一體化監控平臺實踐

前言

咱們的研發協做平臺包括了應用生命週期管理、研發代碼管理、雲計算資源管理、流水線管理、發佈交付管理、一體化監控管理、質效度量管理、智能運維管理、測試自動化管理等版圖，跨越開發、測試、運維、安全多個領域，部分能力已經比較成熟，部分能力苦於資源不足暫未深刻開展，這些基礎技術的設施每一個板塊都有大量的痛點值得挖掘，建設完善的話均可以深度提高整個技術團隊的研發效能和質量。
這裏監控平臺是咱們發力比較多的一個版塊，應用監控、運維監控、業務監控、安全監控陸續成熟並有序聚合，爲整個技術團隊提供了一套多維一體化的監控平臺，價值比較明顯，因此有必要先重點介紹下該平臺的一些設計思路和實踐。

監控平臺的根本之道

每一個公司或多或少都有一些自動化監控手段，在各個技術社區裏也能看到大量關於監控技術的討論。但在討論監控系統時，大多數都是集中在單維度監控技術的討論，針對監控體系的概念目前也幾乎沒有通用的術語，各個職能團隊每每會專一於各自職能領域的監控，好比運維團隊關注服務器和網絡資源，安全團隊關注網絡攻防和業務風控，開發團隊關注應用可用性和鏈路性能，測試團隊更多關注業務故障和用戶輿情等等。
單維度的監控平臺主要反映的是單個業務或技術層面的運行狀態，缺乏能反應整個「業務域」上下游總體運行情況的全局視角；線上出現問題時因爲各職能團隊掌握的信息片面並且不共享，不少時候都須要開發/測試/運維/DBA/安全等多個團隊參與排查，問題緣由定位難，沒法快速響應和解決故障；另外由於各監控平臺都是獨立建設，每每存在監控方式和標準不統一，報警訊息的格式混亂等問題。
線上出現重大故障後召集一堆人卻沒法有效定位到問題，或者半夜收到一堆莫名奇妙的報警短信殊不知道報警來源在哪裏，相似這樣的問題只有經歷過的技術人員才能深深體會到那份痛苦和絕望。
結論：單維度監控效果有限，多維度立體化監控纔是監控平臺的根本之道。

監控平臺的分類和設計

隨着微服務架構與容器虛擬化技術的發展，DevOps 和敏捷文化已經深刻人心，開發、測試和運維等職能團隊的邊界逐漸被淡化並打通。在監控領域複用各維度的監控資產實現信息共享，構建多維監控一體化平臺，實現開發、測試、生產運維階段的全生命監測管理，是 DevOps 研發協做平臺建設的重要組成部分。
依照監控層次的維度，監管管理平臺的監控能力大體分爲幾類：
應用層面的監控
• 監控範圍：包括服務的可用性、請求量、鏈路狀態等，APP 端的 Crash 率 / 卡頓等
• 核心技術：接口 / 頁面撥測、分佈式鏈路分析、客戶端 APM
運維層面的監控
• 監控範圍：包括主機資源、網絡吞吐的狀況，以及服務器上的各種中間件運行情況等
• 核心技術：Zabbix、Prometheus、Grafana 等
業務層面的監控
• 監控範圍：包括核心的業務指標，用戶行爲，以及用戶輿情等
• 核心技術：大數據採集、大數據分析
安全層面的監控
• 監控範圍：如安全態勢感知，用戶行爲風控等
• 核心技術：威脅情報、入侵檢測、大數據風控等

 

 

監控平臺研發實踐

各個維度的監控能力採用不一樣的技術棧研發，構建一套一體化的監控平臺上並非生硬的聚合，關鍵是要須要依據統一的監控標準抽象出公共能力。
經過一些公共的監控組件，咱們實現了監控標準和報警方式的統一；提供了公共的監控大盤頁（包括移動端頁面），核心的監控指標以及告警訊息在一個dashboard頁面直觀展示；同時還提供了統一的監控度量標準,各業務應用可橫向進行系統可用性對比。

 

• 監控大盤-一眼看盡平臺健康度

 

• 移動端監控-在家裏/在路上均可關注監控報警狀況。

 

• 監控度量-橫向系統可用性對比

 

• 分級告警-以應用爲核心的告警機制

 

 

目前微醫整個技術團隊都使用這套一體化監控平臺，每個月輸出1000+次的故障預警，具有了包括可用性指標、運營指標、性能指標、安全指標、基礎資源指標等多維度全方位的監控能力，提供了包括短信、郵件、釘釘、微信等在內的分級告警能力，技術團隊針對線上故障的預警、協同和處理能力都獲得大幅度的提高。

下一步的技術發展提高方向和思路

在具有相對全面的故障監控能力之後，設計和提高系統的故障自愈能力是下一步技術發展的重點。雲計算和容器技術賦予了監控平臺更多的想象空間，好比在監控到某應用的資源瓶頸時，如何與雲計算資源調度平臺協做，利用彈性伸縮技術自動調整資源，這些都是值得進一步深刻探索的領域。
另外，右側的監控平臺也能夠與左側的CI/CD平臺有效集合，在發佈環節依靠高度智能化的監控平臺能力，有效檢測對比發佈先後的監控指標併科學設計發佈質量門，從而提高發布交付環節的穩定性，這也是咱們正在作的事情。

結語

停更比較久了，實踐須要修煉，等成熟了再總結會更飽滿一些，MTSC2019會嘗試詳細分享下該主題的實踐細節。