智能運維｜揭開監(jiān)控系統(tǒng)神經(jīng)中樞的神秘面紗

原標(biāo)題：智能運維｜揭開監(jiān)控系統(tǒng)神經(jīng)中樞的神秘面紗

隨著軟件系統(tǒng)的發(fā)展，監(jiān)控目標(biāo)場景越來越廣泛，對監(jiān)控系統(tǒng)的能力要求也越來越高。對于監(jiān)控系統(tǒng)來說，從能力上看基本可以劃分為數(shù)據(jù)采集、數(shù)據(jù)計算、數(shù)據(jù)存儲、異常檢測、報警處理以及監(jiān)控可視化六塊。

為了更好應(yīng)對大規(guī)模、復(fù)雜化的監(jiān)控業(yè)務(wù)場景，我們不僅僅需要在具體監(jiān)控能力上做深、做強，還需要建立對應(yīng)機制來統(tǒng)籌這些能力一起良好協(xié)作。今天的這篇文章就為大家介紹監(jiān)控系統(tǒng)的神經(jīng)中樞——配置管理與分發(fā)系統(tǒng)，讓我們一起揭開它神秘的面紗吧!

需求

在業(yè)務(wù)系統(tǒng)發(fā)展的初期，由于場景簡單，對監(jiān)控的需求也比較簡單，比如僅采集默認的機器監(jiān)控數(shù)據(jù)，不需要進行進程、日志等監(jiān)控能力。同時監(jiān)控的規(guī)模也相對較小，用戶的配置數(shù)量一般在百或千級別，這時只需定期讀取數(shù)據(jù)庫中的配置就可以很好的工作。

隨著業(yè)務(wù)系統(tǒng)的快速發(fā)展，業(yè)務(wù)體量越來越大，業(yè)務(wù)復(fù)雜度越來越高，對監(jiān)控的需求也越來越高。傳統(tǒng)的簡單讀取數(shù)據(jù)庫配置在業(yè)務(wù)擴展性和性能上遇到了挑戰(zhàn)。

1、支持不同類型的配置管理

監(jiān)控指標(biāo)采集、計算、報警等方面的配置種類越來越多。如物理機的機器資源類指標(biāo)、應(yīng)用程序的進程和日志指標(biāo)的采集配置、站點的連通性采集配置、服務(wù)器的宕機檢測任務(wù)配置、多個實例間指標(biāo)的計算任務(wù)配置、指標(biāo)數(shù)據(jù)的異常檢測配置、報警信息發(fā)送配置等。

2、支持不同場景的配置分發(fā)

• 高并發(fā)配置下載場景：監(jiān)控系統(tǒng)中每個物理機部署一個Agent用于對部署在該機器上的應(yīng)用程序相關(guān)指標(biāo)進行采集。Agent需要下載與主機關(guān)聯(lián)的采集配置，在大規(guī)模的監(jiān)控系統(tǒng)中，Agent的數(shù)量達到百萬級別，采集配置的更新周期為10s，配置分發(fā)系統(tǒng)需要應(yīng)對高并發(fā)查詢的壓力。

• 一致性配置下載場景：為了應(yīng)對高可用、大規(guī)模的數(shù)據(jù)計算及報警場景，各個子系統(tǒng)往往使用集群化部署。以報警集群為例，同一機器的數(shù)據(jù)可能會由報警集群的不同實例進行判斷，若配置在集群內(nèi)不一致，那么報警系統(tǒng)的行為就會變得不可預(yù)期。

3、支持故障快速恢復(fù)

配置分發(fā)系統(tǒng)作為監(jiān)控的樞紐，關(guān)聯(lián)的模塊比較多，系統(tǒng)故障會影響采集、計算、報警子系統(tǒng)工作的正確性以及用戶新加監(jiān)控配置不生效，所以需要相應(yīng)的方案來保障監(jiān)控系統(tǒng)的快速恢復(fù)或重建能力，來保障監(jiān)控系統(tǒng)的可用。

圖1 配置管理&分發(fā)系統(tǒng)交互流程圖

方案

理完問題、需求，接下來就要針對這些問題進行相應(yīng)的改造升級。下面我們從技術(shù)的角度介紹下如何解決這些問題吧！

1、支持配置可擴展性

復(fù)雜的監(jiān)控能力意味著監(jiān)控系統(tǒng)的配置種類靈活多樣。如果直接將配置分發(fā)模型與業(yè)務(wù)模型對接，意味著業(yè)務(wù)上的每次改動都需要配置下發(fā)系統(tǒng)進行對應(yīng)的變更。那么如何統(tǒng)一配置的多樣性，做到配置下發(fā)對上層業(yè)務(wù)透明呢？答案是：歸類+抽象。

將不同的配置按照“目錄”進行分類管理，實現(xiàn)統(tǒng)一的配置管理需求。

以文件作為載體，所有配置都以文件的形式進行管理。不同的文件內(nèi)容格式代表著不同類型的配置，原有格式的升級以及新類型的添加統(tǒng)一抽象為文件處理，增強了系統(tǒng)的擴展能力。

通過代碼管理系統(tǒng)管理文件的方式，實現(xiàn)變更歷史追蹤。通過對文件系統(tǒng)的定時備份與構(gòu)建快速故障恢復(fù)機制提升系統(tǒng)的可用性與可靠性。

圖2 配置歸類&抽象

在歸類方面，由于不同的能力需要的配置形式不同，我們以此為依據(jù)進行分類。對應(yīng)到實現(xiàn)中則通過目錄表達分類的含義，通過子目錄來表達配置的層級與歸屬等關(guān)系。這里我們將配置目錄的層級分為監(jiān)控功能層級->用戶層級->應(yīng)用層級三層，在應(yīng)用目錄下將具體配置（如進程監(jiān)控配置、日志監(jiān)控配置）寫入文件中。

2、確保一致下發(fā)

通過對配置管理方式的抽象與歸類整理，配置的一致性下發(fā)可以通過構(gòu)建配置文件內(nèi)容的一致性機制解決。我們使用“版本”作為文件內(nèi)容一致性機制的核心。當(dāng)用戶變更配置時，配置管理系統(tǒng)會生成一個全局唯一的版本描述此次配置變更操作，版本中包含此次變更操作對應(yīng)的配置文件變更詳情。

配置下發(fā)時，在各個子系統(tǒng)會定期檢測配置版本差異并更新本地配置至最新版本，從而保證配置在每個更新周期內(nèi)保持一致。

3、應(yīng)對高并發(fā)壓力

大規(guī)模的壓力則主要體現(xiàn)在采集Agent的配置下發(fā)部分。由于Agent只需拿到部署主機所需的監(jiān)控配置，因此將配置文件按照監(jiān)控的最小單元進行拆分，并按照規(guī)范進行打包。

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

當(dāng)前的業(yè)務(wù)部署往往采用混布方式，同一主機中會部署多個不同類型的應(yīng)用程序。為了支持這種監(jiān)控場景，主機上部署的采集Agent會查找主機上部署的應(yīng)用并下載對應(yīng)的多個應(yīng)用配置。當(dāng)業(yè)務(wù)規(guī)模增大時，物理機增多，配置下載請求也會成倍增長，因配置存儲的Server端很容易達到性能瓶頸。通過可水平擴展的靜態(tài)文件下載服務(wù)來應(yīng)對高并發(fā)下載壓力，通過ETag方式檢測文件是否變更，只針對變更的配置文件才進行傳輸以減少下載流量，最終滿足了百萬級主機、千萬級實例的配置下發(fā)需求。

4、故障快速恢復(fù)

考慮到配置在監(jiān)控系統(tǒng)中的重要程度，為了保障業(yè)務(wù)的可用性，就需要構(gòu)建監(jiān)控系統(tǒng)的快速故障恢復(fù)機制。

同時，由于監(jiān)控系統(tǒng)配置集中管理，隨著系統(tǒng)的發(fā)展，配置的體積也在不斷增長，配置文件體積達到數(shù)十GB級別，并且全部由小文件組成，文件個數(shù)也達到了數(shù)百萬級別。為了減輕系統(tǒng)壓力，在系統(tǒng)中加入“快照”機制，每隔一段時間便生成當(dāng)前全量配置的快照，當(dāng)出現(xiàn)大量更新時，先通過“快照”減少更新量，再通過對應(yīng)同步機制進行少量的文件更新。

總 結(jié)

經(jīng)過不斷的努力和多次改造，目前的配置管理及分發(fā)可以滿足監(jiān)控系統(tǒng)的需求。由于能夠靈活管理多種配置，并且快速、一致地送至各個系統(tǒng)。在面對故障場景時候，也可以及時撤回配置，避免更大的損失。然而隨著監(jiān)控業(yè)務(wù)的發(fā)展，系統(tǒng)架構(gòu)的變遷，起著中樞作用的配置管理與分發(fā)系統(tǒng)將會面臨新的挑戰(zhàn)。路漫漫其修遠兮，吾將上下而求索！

了解更多，關(guān)注百度云微信公眾號

生成海報

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責(zé)任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。