總篇95篇 2020年 第19篇

前言

汽車之家監控系統已歷經2代建設，第1代技術方案是分佈式部署Zabbix，以“能用”爲主；第2代是圍繞運維需求，基於小米開源監控項目Open-Falcon的二次開發，以“可用”爲主；第3代，我們憑藉之家在監控領域的技術實力與知識儲備，跳脫固化思維、獨立思考，立志爲用戶提供“好用”的監控。

背景

步入2020年，汽車之家在研發效能提升、技術持續突破、業務轉型升級上的需求極其迫切，當我們在規劃下一代監控系統時，以下因素是我們必須要面對的：

下一代監控系統如何能幫助之家進一步提升研發效能？

大多數研發人員的日常工作就是擼代碼、查故障。如今之家已有90%線上業務部署在容器裏，容器因爲具備極好的伸縮與自愈能力，研發人員排查源站故障的耗時已大幅降低。排障耗時的基數已然降低，還有哪些低效空間可以擠壓並消滅呢

技術不僅能實現業務意圖更能通過技術突破釋放技術紅利賦能業務，下一代監控系統的技術突破點在哪？

各個互聯網公司都有自己的監控系統，這些系統各有技術特色。之家的應用運維架構已經步入雲原生生態，下一代監控系統必然繞不開雲原生生態，我們該怎麼利用雲原生突破呢

之家將向汽車生態圈供給雲計算能力，下一代監控系統如何脫穎而出？

目前，汽車之家利用AI人工智能、Bigdata大數據、Cloud雲計算，以流量、銷售線索、內容及數據等賦能汽車生態系統中各個參與方，加速邁向智能平臺3.0時代。監控系統做爲雲計算必備功能之一，面對的是一片紅海，我們該如何在衆多廠商中體現自身價值呢

策略

基於上述大背景的思考，AutoCMP進行了應對升級：

研發效能提升方面：移動至上，告警隨時查看、故障隨手處理

我們發現在開會、外出、居家等場景下，很多故障從告警接收到處理完畢的用時遠長於用戶在電腦前處理用時。過去這些場景，我們只是給告警接收人的手機發送短信或釘釘通知，但受限於短信和釘釘通知的格式與字數限制，告警接收人難以快速掌握故障覆蓋範圍和處理進展，一般情況仍需撥通VPN連接PC端訪問雲監控查看。因此，我們在之家移動辦公平臺“汽車人”裏推出“掌上監控”，讓用戶能通過手機，全面掌握URL、應用、源站等各維度健康狀態

技術持續突破方面：融合雲原生時代和分佈式時代最流行的技術棧

之前經典主機監控使用小米開源的open-falcon，用戶自定義、容器應用監控使用SoundCloud開源的prometheus，每增加同一需求功能時，都得用open-falcon與prometheus各實現一次。第3代架構以prometheus爲核心，同時將經典主機的數據通過改造open-falcon的tranfer組件將數據打到prometheus中，實現時序數據存儲的統一，並在此基礎上二次開發告警組件（judge）、數據轉發組件（gateway）、圖形數據查詢組件（query)等

業務轉型升級方面：大道至簡，主要圍繞研發角色視角而非運維角色視角

複雜很簡單、簡單卻並不簡單，當業內幾乎所有監控系統都在堆棧、堆功能的時候，我們認爲大道至簡，再精尖的技術，對用戶而言需要得到的只是應該自己關心的告警和該告警的故障點。所以我們 建設了以應用爲中心的全方位監控 ，所有告警對象都與應用及部署環境緊密關聯，且應用監控配置自動化，應用發佈即完成配置， 無接入成本 。同時考慮到之前兩代監控裏大量默認基礎監控都是運維定義的，實際上研發無需關注，爲此我們減少了大量的默認基礎監控項

實現

1.以移動化爲核心的研發效能提升方面

雲監控的移動化，產品上依託於雲平臺整體的移動化，技術上依託於之家移動辦公平臺“汽車人”的小程序架構。用戶可以在“汽車人”裏一鍵撥VPN查看告警詳情，並且可以關聯其他雲服務的移動化，進行上下負載、源站擴容等排障操作

2.以雲原生技術爲核心的技術突破和以研發視角爲核心的業務轉型升級方面

2.1 設計監控系統時序數據庫prometheus多副本存儲架構，保障存儲系統的穩定性

生產中某些公司使用prometheus引入“聯邦”解決多副本存儲，從而保證系統存儲的穩定性，之家前期也是採用聯邦的形式(prometheus->prometheus)，後來業務數據增長過快，聯邦多副本存儲架構處理能力不再能滿足生產環境，例如：第一個prometheus數據量爲600萬/min，則第二個prometheus每分鐘定時通過http一次性拉取600萬數據。原因：數據量過大，拉取數據超時，單機某點處理數據能力故障，造成數據中斷，告警異常等線上故障

我們的設計採用gateway->雙prometheus不僅解決多副本存儲架構，還解決了由pormetheus->prometheus單機數據同步異常的問題，從而保證存儲系統的穩定性，例如：10個gateway 60萬--->rpc持續傳輸---->兩個prometheus，數據上傳時間分散在每分鐘內，降低某一時刻數據處理壓力），通過所有數據時間戳在gateway生成、prometheus不再生成數據時間戳，解決多副本存儲時間的一致性

2.2 引入遠端存儲組件influxDB，保障近一年內的監控數據可查

prometheus設計初衷實時數據，其自帶的時序數據庫將數據保存到本地磁盤，但本地存儲的容量畢竟有限，所以引入遠端存儲組件influxdb。保障近一年內的監控數據可查

2.3 時序數據庫prometheus副本節點上容器，目前運行穩定

目前prometheus採用的雙節點模式爲（物理機節點+容器節點)，通過容器組相關技術人員支持，使用有狀態時序數據庫prometheus副本作爲一個pod在k8s集羣中運行，目前運行相對穩定

效果

AutoCMP上線後，已經接入之家全部應用監控，大幅降低了非現場排障時間、應用配置時間，增加了監控信息可查詢時間，使得故障更易發現和定位

後續

1.排障線索的基礎數據關聯不足，需要與監控系統的上游系統共同努力，豐富基礎數據

2.AI在監控中使用還有巨大潛力，大多數容器故障並不影響業務，我們希望通過AI進行降噪並定位故障