走近監控系統的神經中樞

本文做者:AIOps智能運維數據庫

做者簡介服務器

四金    百度高級研發工程師架構

 

負責百度智能運維(Noah)監控平臺的設計和研發工做,在監控系統的配置管理方向有普遍實踐經驗。併發

 

乾貨概覽運維

隨着軟件系統的發展,監控目標場景愈來愈普遍,對監控系統的能力要求也愈來愈高。對於監控系統來講,從能力上看基本能夠劃分爲數據採集、數據計算、數據存儲、異常檢測、報警處理以及監控可視化六塊。爲了更好應對大規模、複雜化的監控業務場景,咱們不只僅須要在具體監控能力上作深、作強,還須要創建對應機制來統籌這些能力一塊兒良好協做。今天的這篇文章就爲你們介紹監控系統的神經中樞——配置管理與分發系統,讓咱們一塊兒揭開它神祕的面紗吧! 高併發

需求性能

在業務系統發展的初期,因爲場景簡單,對監控的需求也比較簡單,好比僅採集默認的機器監控數據,不須要進行進程、日誌等監控能力。同時監控的規模也相對較小,用戶的配置數量通常在百或千級別,這時只需按期讀取數據庫中的配置就能夠很好的工做。設計

隨着業務系統的快速發展,業務體量愈來愈大,業務複雜度愈來愈高,對監控的需求也愈來愈高。傳統的簡單讀取數據庫配置在業務擴展性性能上遇到了挑戰。日誌

1支持不一樣類型的配置管理blog

監控指標採集、計算、報警等方面的配置種類愈來愈多。如物理機的機器資源類指標、應用程序的進程和日誌指標的採集配置、站點的連通性採集配置、服務器的宕機檢測任務配置、多個實例間指標的計算任務配置、指標數據的異常檢測配置、告警信息發送配置等。

2支持不一樣場景的配置分發

  • 高併發配置下載場景:監控系統中每一個物理機部署一個Agent用於對部署在該機器上的應用程序相關指標進行採集。Agent須要下載與主機關聯的採集配置,在大規模的監控系統中,Agent的數量達到百萬級別,採集配置的更新週期爲10s,配置分發系統須要應對高併發查詢的壓力。

  • 一致性配置下載場景:爲了應對高可用、大規模的數據計算及報警場景,各個子系統每每使用集羣化部署。以報警集羣爲例,同一機器的數據可能會由報警集羣的不一樣實例進行判斷,若配置在集羣內不一致,那麼報警系統的行爲就會變得不可預期。

3支持故障快速恢復

配置分發系統做爲監控的樞紐,關聯的模塊比較多,系統故障會影響採集、計算、報警子系統工做的正確性以及用戶新加監控配置不生效,因此須要相應的方案來保障監控系統的快速恢復或重建能力,來保障監控系統的可用。

圖1  配置管理&分發系統交互流程圖

方案

梳理完問題、需求,接下來就要針對這些問題進行相應的改造升級。下面咱們從技術的角度介紹下如何解決這些問題吧!

1、支持配置可擴展性

複雜的監控能力意味着監控系統的配置種類靈活多樣。若是直接將配置分發模型與業務模型對接,意味着業務上的每次改動都須要配置下發系統進行對應的變動。那麼如何統一配置的多樣性,作到配置下發對上層業務透明呢?答案是:歸類+抽象

  1. 將不一樣的配置按照「目錄」進行分類管理,實現統一的配置管理需求。

  2. 文件做爲載體,全部配置都以文件的形式進行管理。不一樣的文件內容格式表明着不一樣類型的配置,原有格式的升級以及新類型的添加統一抽象爲文件處理,加強了系統的擴展能力。

  3. 經過代碼管理系統管理文件的方式,實現變動歷史追蹤。經過對文件系統的定時備份與構建快速故障恢復機制提高系統的可用性與可靠性。

圖2  配置歸類&抽象

在歸類方面,因爲不一樣的能力須要的配置形式不一樣,咱們以此爲依據進行分類。對應到實現中則經過目錄表達分類的含義,經過子目錄來表達配置的層級與歸屬等關係。這裏咱們將配置目錄的層級分爲監控功能層級->用戶層級->應用層級三層,在應用目錄下將具體配置(如進程監控配置、日誌監控配置)寫入文件中。

2、確保一致下發

經過對配置管理方式的抽象與歸類整理,配置的一致性下發能夠經過構建配置文件內容的一致性機制解決。咱們使用「版本」做爲文件內容一致性機制的核心。當用戶變動配置時,配置管理系統會生成一個全局惟一的版本描述這次配置變動操做,版本中包含這次變動操做對應的配置文件變動詳情。

配置下發時,在各個子系統會按期檢測配置版本差別並更新本地配置至最新版本,從而保證配置在每一個更新週期內保持一致。

3、應對高併發壓力

大規模的壓力則主要體如今採集Agent的配置下發部分。因爲Agent只需拿到部署主機所需的監控配置,所以將配置文件按照監控的最小單元進行拆分,並按照規範進行打包。

圖3  Agent配置拆分&下載流程

當前的業務部署每每採用混布方式,同一主機中會部署多個不一樣類型的應用程序。爲了支持這種監控場景,主機上部署的採集Agent會查找主機上部署的應用並下載對應的多個應用配置。當業務規模增大時,物理機增多,配置下載請求也會成倍增加,因配置存儲的Server端很容易達到性能瓶頸。經過可水平擴展的靜態文件下載服務來應對高併發下載壓力,經過ETag方式檢測文件是否變動,只針對變動的配置文件才進行傳輸以減小下載流量,最終知足了百萬級主機、千萬級實例的配置下發需求。

4、故障快速恢復

考慮到配置在監控系統中的重要程度,爲了保障業務的可用性,就須要構建監控系統的快速故障恢復機制。

同時,因爲監控系統配置集中管理,隨着系統的發展,配置的體積也在不斷增加,配置文件體積達到數十GB級別,而且所有由小文件組成,文件個數也達到了數百萬級別。爲了減輕系統壓力,在系統中加入「快照」機制,每隔一段時間便生成當前全量配置的快照,當出現大量更新時,先經過「快照」減小更新量,再經過對應同步機制進行少許的文件更新。

總  結

通過不斷的努力和屢次改造,目前的配置管理及分發能夠知足監控系統的需求。因爲可以靈活管理多種配置,而且快速、一致地送至各個系統。在面對故障場景時候,也能夠及時撤回配置,避免更大的損失。然而隨着監控業務的發展,系統架構的變遷,起着中樞做用的配置管理與分發系統將會面臨新的挑戰。路漫漫其修遠兮,吾將上下而求索!

原文連接地址:https://developer.baidu.com/topic/show/290323

相關文章
相關標籤/搜索