苑舒斌，宗曉萌，于俊濤

中海油信息科技有限公司北京分公司，北京，100010

0 引言

隨著信息化程度的日益加深，以及對信息安全和技術(shù)資產(chǎn)的日益重視，越來越多的企業(yè)將保護核心的數(shù)據(jù)資產(chǎn)和防范企業(yè)核心業(yè)務(wù)數(shù)據(jù)泄漏提上日程。對此，一種可行的解決思路為推進云辦公，實現(xiàn)重要數(shù)據(jù)的隔離、備份和流轉(zhuǎn)審計。在此場景下，可能涉及大量的物理服務(wù)器和虛擬主機，需要進行監(jiān)控，以及時發(fā)現(xiàn)系統(tǒng)問題，復(fù)盤歷史故障[1]。因此需要一種高度可擴展、可配置的監(jiān)控報警平臺，實現(xiàn)對服務(wù)器系統(tǒng)的在線監(jiān)控報警。平臺應(yīng)當可定制被監(jiān)控的數(shù)據(jù)種類，必要時隨時通過擴展模塊增加新數(shù)據(jù)。采集來的數(shù)據(jù)需匯總到平臺集中存儲，并集中進行分析報警。針對報警功能，應(yīng)允許用戶便利地定制報警規(guī)則，基于采集到的數(shù)據(jù)按需報警。同時，平臺中的數(shù)據(jù)采集模塊可能運行在服務(wù)器本身以及虛擬主機上，因此采集模塊必須輕量化，減少不必要的開銷，并在采集架構(gòu)設(shè)計上實現(xiàn)必要的彈性，可輕松應(yīng)對不同規(guī)模的系統(tǒng)。

現(xiàn)有的服務(wù)器監(jiān)控平臺，如Zabbix、Ganglia、Nagios等，他們各具特色，但在集群構(gòu)建、報警規(guī)則定義、規(guī)模橫向擴展能力、二次開發(fā)能力、監(jiān)控目標擴展能力、故障容錯能力等方面各自有一定的缺陷[1]。本文設(shè)計的平臺依托已有集群環(huán)境中的服務(wù)組件構(gòu)建，設(shè)計上側(cè)重于規(guī)則模板的靈活構(gòu)建和可編程性。

1 平臺架構(gòu)

基于以上考慮，平臺架構(gòu)設(shè)計將側(cè)重于分布式、可擴展、可配置和輕量化等方面。

圖1所示為系統(tǒng)的整體功能框圖。在被監(jiān)控的服務(wù)器、虛擬主機等設(shè)備中安裝采集程序，負責(zé)對終端數(shù)據(jù)的初步收集。然后通過采集程序的接口模塊進行整理，變?yōu)闃藴氏?nèi)容，發(fā)送到消息隊列。根據(jù)系統(tǒng)規(guī)模不同，消息隊列可組建為集群模式。作為消息隊列的消費者，入庫程序也可根據(jù)處理負載情況動態(tài)增減。最終，入庫程序?qū)⒈O(jiān)控數(shù)據(jù)保存到時序數(shù)據(jù)庫中，供用戶做歷史數(shù)據(jù)查詢時展示使用，并可作為復(fù)雜報警功能的判斷條件。報警程序的數(shù)據(jù)來源可以是數(shù)據(jù)庫，但是數(shù)據(jù)庫本身可靠性較低，尤其是系統(tǒng)發(fā)生故障的情況下，難以保證數(shù)據(jù)庫系統(tǒng)仍可以正常運行。因此，報警判斷依賴的原始數(shù)據(jù)必須可由入庫程序直接提供。

圖1 系統(tǒng)整體框圖

運行于主機中的采集程序負責(zé)定時獲取對象的運行狀態(tài)數(shù)據(jù)，如CPU、內(nèi)存、硬盤、網(wǎng)絡(luò)、IPMI等硬件運行狀態(tài)，以及運行于其上的關(guān)鍵進程、數(shù)據(jù)庫、消息隊列、虛擬機、Docker服務(wù)等軟件運行狀態(tài)[2]。因為采集程序需要運行在大量主機上，所以首先要考慮其運行效率，需以最小的資源占用實現(xiàn)采集需求；同時，也要便于擴展，能便利地加入新的監(jiān)控對象采集需求，甚至可以由用戶定制需求。

一方面，消息隊列實現(xiàn)了橫向擴展需求。依靠隊列提供的集群功能、消息路由和負載均衡功能，可快速配置適應(yīng)不同規(guī)模的接入主機數(shù)量，并可隨時增減作為消息消費者的入庫程序模塊。另一方面，消息隊列提供了數(shù)據(jù)緩存和持久化功能[3]。當網(wǎng)絡(luò)抖動或其他意外導(dǎo)致系統(tǒng)負載波動時，消息隊列可為系統(tǒng)提供必要的緩沖；入庫程序和數(shù)據(jù)庫本身發(fā)生故障，也可為待處理的數(shù)據(jù)提供持久化功能，保證已采集的數(shù)據(jù)不因平臺故障而丟失。

入庫程序消費消息隊列數(shù)據(jù)，包括數(shù)據(jù)預(yù)處理、摘要數(shù)據(jù)生成、數(shù)據(jù)入庫、數(shù)據(jù)自動分表和過期數(shù)據(jù)清理等功能模塊，如圖2所示。來自消息隊列的原始采集數(shù)據(jù)可能具有不同的數(shù)據(jù)命名方式，或者數(shù)據(jù)單位。同時，一部分需入庫的數(shù)據(jù)可能需要通過收集到的原始數(shù)據(jù)計算后才能得到。因此，首先需對收到的數(shù)據(jù)進行預(yù)處理，之后將這些數(shù)據(jù)轉(zhuǎn)換為對應(yīng)數(shù)據(jù)庫的入庫語句存入數(shù)據(jù)庫。這里考慮到數(shù)據(jù)庫存入可能失敗，批量處理失敗的數(shù)據(jù)應(yīng)退回到消息隊列，等待后續(xù)處理，如圖2中虛線所示。故障診斷及數(shù)據(jù)展示過程中，會需要系統(tǒng)能提供較長時間范圍內(nèi)原始數(shù)據(jù)的統(tǒng)計信息，如最大值、最小值、平均值等，因此入庫程序還需提供數(shù)據(jù)摘要服務(wù)，計算原始數(shù)據(jù)若干時間范圍內(nèi)等級的統(tǒng)計結(jié)果，并存入數(shù)據(jù)庫以供查詢。常見的時序數(shù)據(jù)庫也支持持續(xù)查詢等摘要生成功能，但基于數(shù)據(jù)庫本身功能的摘要生成就缺乏靈活性，且對各種異常情況缺乏容錯能力，因此由程序?qū)崿F(xiàn)該功能。另外，出于數(shù)據(jù)庫查詢性能和數(shù)據(jù)量控制的考慮，程序還應(yīng)提供自動分庫分表和過期數(shù)據(jù)清理功能。為了實現(xiàn)分布式數(shù)據(jù)存儲的一致性，并保證分布式程序有一致的分表命名邏輯，分表按照固定的UTC時間間隔進行。程序入庫的數(shù)據(jù)也會同時創(chuàng)建一份緩存數(shù)據(jù)，供故障診斷模塊跳過數(shù)據(jù)庫直接訪問使用。緩存數(shù)據(jù)應(yīng)按照入庫時間戳進行組織，根據(jù)實際診斷需求，緩存多個不同時間點的數(shù)據(jù)。通常進行故障判斷時，需要對相鄰多個時間點的數(shù)據(jù)進行分析計算。

圖2 入庫程序功能框圖

報警程序首先讀取數(shù)據(jù)緩存中的數(shù)據(jù)進行分析，判斷是否滿足報警條件。如果數(shù)據(jù)不存在，再嘗試到數(shù)據(jù)庫中查詢。通常報警分析都需要利用近期采集的多個數(shù)據(jù)進行判斷，而其中某些部分在下次分析中也需要用到。緩存可以減少對數(shù)據(jù)庫的訪問壓力，也可以保證當數(shù)據(jù)庫不可用時，僅依賴近期數(shù)據(jù)的簡單報警分析便可正常進行。

報警程序的規(guī)則配置接口直接面向用戶，其設(shè)計的關(guān)鍵是如何使用戶能高效便捷地創(chuàng)建自定義報警規(guī)則，輸出自定義的報警通知信息。為了給用戶最大的規(guī)則定制空間，需要接口支持數(shù)學(xué)計算、字符串處理、條件判斷、循環(huán)控制等功能[1]。接口中，提供用戶獲取指定時間點采集數(shù)據(jù)的能力。基于以上考慮，系統(tǒng)選取字符串模板引擎作為報警功能判斷分析過程實現(xiàn)的核心。

最后，發(fā)現(xiàn)系統(tǒng)報警后需要對歷史數(shù)據(jù)進行分析、明確問題原因，所以采集數(shù)據(jù)的圖形化展示是必不可少的功能。因為數(shù)據(jù)存儲部分依賴時序數(shù)據(jù)庫實現(xiàn)，因此該功能可簡單地通過數(shù)據(jù)庫支持的數(shù)據(jù)可視化工具實現(xiàn)。

2 平臺實現(xiàn)

本研究針對平臺架構(gòu)中涉及的關(guān)鍵部分實現(xiàn)進行詳細介紹。

2.1 數(shù)據(jù)采集

數(shù)據(jù)采集部分側(cè)重輕量化和可擴展性?；谥鳈C狀態(tài)監(jiān)控的基本需求，對CPU、內(nèi)存、硬盤、網(wǎng)絡(luò)、IPMI等硬件運行狀態(tài)的采集是必要功能。通過對現(xiàn)有解決方案的篩選，找到符合平臺需求的開源項目Collectd。

Collectd程序本身以C語言編寫，運行時占用的CPU和內(nèi)存資源都很少。其通過模塊擴展的方式，默認支持對常見硬件數(shù)據(jù)、關(guān)鍵進程數(shù)據(jù)、常用服務(wù)器組件數(shù)據(jù)、虛擬機和容器數(shù)據(jù)的采集功能[5]。同時以Python腳本形式，可以方便地編寫自定義擴展模塊。程序還提供了網(wǎng)絡(luò)協(xié)議、AQMP隊列協(xié)議、服務(wù)器文件輸出等多種采集數(shù)據(jù)輸出方式?；谄銾DP網(wǎng)絡(luò)傳輸協(xié)議，甚至可以將多個Collectd采集程序的實例級聯(lián)，實現(xiàn)分級的數(shù)據(jù)收集，也可以直接將數(shù)據(jù)輸出到InfluxDB時序數(shù)據(jù)庫。此處，基于系統(tǒng)橫向擴展和數(shù)據(jù)可靠性的考慮，我們選擇用RabbitMQ消息隊列作為數(shù)據(jù)處理的中間件。因此，Collectd在平臺中將利用AQMP協(xié)議的輸出方式連接到中心消息隊列。程序的功能框圖如圖3所示。

圖3 Collectd功能框圖

采集數(shù)據(jù)具有如下屬性：采樣時間、主機名、采集模塊、模塊實例、數(shù)據(jù)名稱、數(shù)據(jù)值，分別表示數(shù)據(jù)采樣的實際時間、采樣發(fā)生的主機名稱、執(zhí)行采樣的功能模塊、采樣的目標對象和采樣參數(shù)的名稱。因此，采集到的數(shù)據(jù)都可用五元組（時間，主機，模塊，實例，名稱）唯一標識。例如在時間點1000對主機H1的CPU狀態(tài)采樣，得到的結(jié)果為各個CPU核心的空閑時間、等待時間等數(shù)據(jù)。因此，表示核心2 IDLE比例的數(shù)據(jù)可用五元組（1000，H1，CPU，2，IDLE）進行標識。

應(yīng)用中，發(fā)現(xiàn)Collectd自帶的AQMP隊列協(xié)議輸出模塊每收到一條輸入數(shù)據(jù)即發(fā)送一條MQ消息。此舉可能導(dǎo)致網(wǎng)絡(luò)中有大量短TCP報文傳送，影響網(wǎng)絡(luò)性能。因此對模塊進行修正，實現(xiàn)單條MQ消息中批量發(fā)送采集數(shù)據(jù)。

2.2 數(shù)據(jù)存儲

因為持續(xù)監(jiān)控產(chǎn)生的數(shù)據(jù)量很大，而對其查詢的條件主要為數(shù)據(jù)產(chǎn)生時間，因此適合使用時序數(shù)據(jù)庫進行保存。常見的開源選擇包括Elasticsearch、InfluxDB等。

因為不同種類采集數(shù)據(jù)的內(nèi)容相差很大，而同類數(shù)據(jù)基本有相同的數(shù)據(jù)項，實踐中選擇將來自不同采集模塊的數(shù)據(jù)單獨保存到不同的數(shù)據(jù)表中。不考慮定期分表的影響，每個采集模塊的數(shù)據(jù)存到同一表中。表中除時間列外，另有主機名、采集模塊名、數(shù)據(jù)實例名等索引字段，而每個數(shù)據(jù)的名稱作為表的數(shù)據(jù)列，與采集數(shù)據(jù)唯一標識的五元組對應(yīng)。同時，為了便于數(shù)據(jù)查詢，規(guī)定所有數(shù)據(jù)時間需整理到規(guī)定的整數(shù)倍采樣時間的間隔時點。

為了便于后續(xù)進行數(shù)據(jù)展示和報警規(guī)則編寫，入庫程序同時還會對入庫數(shù)據(jù)進行摘要計算，將摘要結(jié)果同樣寫入數(shù)據(jù)庫。對于一種原始數(shù)據(jù)表，根據(jù)需要可設(shè)置多個不同等級的摘要表。摘要表中，每個原始數(shù)據(jù)對應(yīng)其最大值、最小值、累加和、平方和、有效數(shù)據(jù)個數(shù)等5個摘要數(shù)據(jù)。實際期望得到的統(tǒng)計數(shù)據(jù)是原始數(shù)據(jù)在摘要時間間隔中的最大值、最小值、平均值和標準差，設(shè)置摘要數(shù)據(jù)是為了屏蔽摘要過程意外中斷、數(shù)據(jù)丟失、進程重啟等意外情況對摘要結(jié)果精度的影響。

如圖4所示為摘要過程的計算原理，展示了兩個低等級摘要數(shù)據(jù)如何計算對應(yīng)的高等級摘要數(shù)據(jù)。對于原始采樣數(shù)據(jù)，可認為其最大值、最小值、累加和都是其自身，平方和是自身平方。后續(xù)摘要時，下一摘要等級應(yīng)記錄的最大值、最小值、累加和、平方和，則分別是上一摘要等級中對應(yīng)時間范圍內(nèi)所有數(shù)據(jù)的最大值、最小值、累加和、平方和。可以認為每個采樣間隔中各個摘要結(jié)果的數(shù)量級大致相同，因此該摘要過程不會導(dǎo)致數(shù)值誤差積累。最終，摘要等級的一個時間間隔，記錄了對應(yīng)所有原始采樣點數(shù)據(jù)的摘要值。根據(jù)記錄中的有效數(shù)據(jù)數(shù)量、累加和、平方和，即可獲得摘要時間區(qū)間內(nèi)精確的平均值和標準差。

圖4 摘要計算圖示

數(shù)據(jù)庫中保存的數(shù)據(jù)除原始數(shù)據(jù)外，還有各級摘要。因此訪問數(shù)據(jù)庫的數(shù)據(jù)時，需使用六元組（時間，主機，模塊，摘要等級，實例，名稱），且名稱中需以后綴的方式表示期望數(shù)據(jù)的摘要類型。

2.3 報警規(guī)則

報警規(guī)則設(shè)置應(yīng)當靈活、便捷，用戶可對特定范圍內(nèi)的設(shè)備進行指定報警監(jiān)控，報警規(guī)則編寫時能便捷地獲取監(jiān)控數(shù)據(jù)，并有編寫復(fù)雜邏輯的能力。

獲取監(jiān)控數(shù)據(jù)的便捷性體現(xiàn)為以下幾點。第一，用戶報警規(guī)則中獲取監(jiān)控數(shù)據(jù)時，可便捷地指定數(shù)據(jù)六元組的內(nèi)容，以精確地獲取數(shù)據(jù)。第二，六元組中的部分內(nèi)容，如主機名、實例名，可指定通配符，或者給定預(yù)定義列表。第三，六元組中的各項應(yīng)當具有合理的默認值，常規(guī)數(shù)據(jù)訪問必須提供的項只有時間和名稱。第四，時間參數(shù)應(yīng)采用相對值，且具有容錯性，指定時間應(yīng)自動取整到相應(yīng)數(shù)據(jù)摘要間隔的整數(shù)倍時點。第五，規(guī)則定義參數(shù)化，普通用戶不需要修改規(guī)則腳本，直接改變規(guī)則參數(shù)即可變更規(guī)則行為。

為實現(xiàn)以上目標，為報警規(guī)則腳本提供get函數(shù)原型如下：

def get(tsOffset: float, itemName: string,metric: string = None, summary: string = None,host: string = None, inst: string = None)

其中只有相對時間tsOffset和變量名稱itemName為必選項；其他參數(shù)中模塊名稱metric和摘要等級summary在規(guī)則編寫時提供了默認值，因此可以省略；主機名host和模塊實例inst提供了通配符和列表語法。對于一條報警規(guī)則，在實際運行前會根據(jù)通配符到系統(tǒng)中確認實際可能的主機名和模塊實例列表，或者直接使用用戶給定的列表，然后對所有可能的組合都執(zhí)行一次規(guī)則判斷。因此，每次規(guī)則執(zhí)行，主機名和模塊實例的默認值都不相同，實現(xiàn)了模板化報警規(guī)則的功能，可指定規(guī)則執(zhí)行的目標列表，也實現(xiàn)了對特定范圍內(nèi)的設(shè)備進行指定報警的功能。

編寫復(fù)雜報警邏輯，指用戶在編寫報警規(guī)則時，可進行變量定義、數(shù)學(xué)計算、字符串處理、條件判斷、循環(huán)控制等操作。同時，基于安全考慮，用戶編寫的腳本還需要在沙箱環(huán)境中隔離運行。Python作為一種使用簡單的腳本語言，且較多運維人員都有應(yīng)用經(jīng)驗，適合作為報警規(guī)則腳本的基礎(chǔ)。Python環(huán)境下，Jinja模板語言具有類似Python的語法，且可以利用Python本身的函數(shù)功能，運行環(huán)境也有沙箱保證，適用于本平臺報警規(guī)則腳本編寫的基本需求。通過模板語言語法編寫報警規(guī)則，還可便利地格式化輸出報警提示信息[6]。實踐中，我們是基于Jinja模板語言提供的功能實現(xiàn)報警規(guī)則執(zhí)行。將定義的get函數(shù)映射到模板語言函數(shù)中，供用戶獲取數(shù)據(jù)。

為了使用戶在報警規(guī)則執(zhí)行、報警消息生成時可以獲取更完整的信息，也將get函數(shù)使用的默認參數(shù)和規(guī)則定義時填寫的規(guī)則名稱等作為附加信息映射到模板語言環(huán)境中，供用戶使用。

2.4 數(shù)據(jù)展示

對于常見的時序數(shù)據(jù)庫，有Grafana作為開箱可用的數(shù)據(jù)展示組件[7]。因為所有數(shù)據(jù)保存到數(shù)據(jù)庫，也可便捷地集成到現(xiàn)有的應(yīng)用環(huán)境界面中。

如圖5所示為平臺數(shù)據(jù)展示示例。Grafana提供了基礎(chǔ)的數(shù)據(jù)源連接、變量配置、時間縮放功能。平臺配置了4個變量，分別為模塊名稱列表、主機列表、模塊實例列表和變量名稱列表，分別表示在選定的展示時間區(qū)間內(nèi)，可用的數(shù)據(jù)采集模塊名稱、選定采集模塊收集的主機名稱、選定主機上該模塊的實例列表和模塊的采集變量列表。其中，除模塊名稱外均支持多選。選擇完成后，將對每個采集參數(shù)顯示一個獨立圖表，圖表中對每個主機名稱和模塊實例名稱的組合均顯示一條折線，表征變化趨勢。圖中選定的采集模塊是CPU模塊，它采集了每個CPU核心的系統(tǒng)使用率、用戶使用率、中斷使用率、等待時間比例等數(shù)據(jù)。根據(jù)配置，顯示了某主機上第0、第1核心的系統(tǒng)使用率和用戶使用率變化。

圖5 Grafana數(shù)據(jù)展示

3 報警配置實例

3.1 CPU占用報警

現(xiàn)通過實例展示系統(tǒng)中如何配置檢查特定CPU核心的使用情況，如果負荷持續(xù)超標則進行報警。

系統(tǒng)監(jiān)控的主機中有若干名稱以“ZS-”開頭，其CPU核心20-29運行特定負載，如果CPU空閑時間持續(xù)半小時低于10%，則應(yīng)報警。對于該場景，可按照表1內(nèi)容配置報警規(guī)則。規(guī)則指出，該規(guī)則會使用CPU模塊采集到的5分鐘等級摘要數(shù)據(jù)，監(jiān)控的主機名稱可用通配符“HOST-*”進行匹配，監(jiān)控的CPU實例可用正則表達式“/2[0-9]{1}/”進行匹配。對于匹配到的CPU核心，連續(xù)獲取其最近30分鐘idle_avg數(shù)據(jù)，判斷是否低于閾值。如果所有時點都低于閾值，則說明CPU空閑時間持續(xù)偏低，應(yīng)進行報警。這里用到兩個用戶定義的參數(shù)var.low和var.cnt，分別表示idle的檢測閾值和連續(xù)獲取的5分鐘摘要數(shù)據(jù)時點數(shù)量。表中定義idle的低閾值為10%，采樣時點數(shù)量是6，對應(yīng)30分鐘時長。報警規(guī)則的最后一行是判斷語句，如果結(jié)果是真，則應(yīng)當報警，報警內(nèi)容由輸出模板格式化后給定。

由表1的配置樣例可以看出，平臺規(guī)則配置非常靈活，輸出內(nèi)容也可根據(jù)設(shè)定清晰地指出報警來源。編寫規(guī)則腳本需要一定的編程基礎(chǔ)，但通過用戶參數(shù)的形式，使普通用戶也能夠安全地按需修訂規(guī)則行為。

表1 報警配置實例

3.2 進程重啟報警

關(guān)鍵進程重啟也是服務(wù)器監(jiān)控平臺的一項重要工作內(nèi)容。通常的服務(wù)重啟監(jiān)控基于指定名稱進程的數(shù)量變化，或者進程啟動時間變化進行判斷。對于具有多實例的服務(wù)，常見監(jiān)控平臺往往難以有效定義報警規(guī)則。基于本平臺的擴展能力，可通過插入數(shù)據(jù)預(yù)處理模塊的方式直接獲得監(jiān)控進程的重啟事件，統(tǒng)計進程重啟次數(shù)。

如圖2所示，數(shù)據(jù)入庫程序具有數(shù)據(jù)預(yù)處理功能模塊。對于CPU、內(nèi)存、關(guān)鍵進程等系統(tǒng)已知的數(shù)據(jù)類別，均可注冊專用的數(shù)據(jù)處理模塊，進行數(shù)據(jù)預(yù)處理。預(yù)處理框架中，可實現(xiàn)對輸入數(shù)據(jù)的通用處理，如字段名改寫、單位轉(zhuǎn)換、有效性檢查等。之后將收到的數(shù)據(jù)緩存在臨時結(jié)構(gòu)中，等待模塊接收到完整的數(shù)據(jù)再統(tǒng)一進行后續(xù)處理，包括數(shù)據(jù)處理回調(diào)和實際入庫動作。

如圖6所示，針對進程重啟檢測功能，可在關(guān)鍵進程監(jiān)控模塊進行數(shù)據(jù)預(yù)處理時，插入數(shù)據(jù)處理回調(diào)函數(shù)。函數(shù)接收進程數(shù)據(jù)處理模塊緩存的進程名稱、進程PID等數(shù)據(jù)，與自身狀態(tài)字典保存的內(nèi)容進行對比，即可發(fā)現(xiàn)特定進程是否重啟。發(fā)現(xiàn)進程重啟后，重啟統(tǒng)計模塊將產(chǎn)生重啟數(shù)據(jù)，標記過去時間間隔內(nèi)某進程發(fā)生1次重啟。重啟統(tǒng)計模塊產(chǎn)生的數(shù)據(jù)與其他從主機輸入的模塊數(shù)據(jù)具有同等地位，在平臺中同等進行數(shù)據(jù)摘要、保存、展示、報警等后續(xù)訪問。期望的預(yù)處理數(shù)據(jù)復(fù)雜時，平臺也可以支持利用多個模塊數(shù)據(jù)進行分析生成[8]。

圖6 進程重啟統(tǒng)計實現(xiàn)框圖

此方案充分利用了平臺易于擴展的優(yōu)勢，高效完成進程重啟監(jiān)控任務(wù)。且進程重啟數(shù)據(jù)也被入庫、摘要，可隨時查看歷史記錄。

4 結(jié)語

本文針對大規(guī)模服務(wù)器集群和虛擬主機的應(yīng)用場景，給出了一種高度可配置的分布式狀態(tài)監(jiān)控和報警系統(tǒng)的基本架構(gòu)，包括數(shù)據(jù)采集、消息隊列、入庫程序、報警程序、數(shù)據(jù)展示等組成部分。平臺可適應(yīng)不同規(guī)模主機集群的監(jiān)控報警需求，報警規(guī)則支持模板化，編寫簡單，并可設(shè)置用戶自定義規(guī)則參數(shù)。

平臺功能目前都已實現(xiàn)，在實際工作場景中運行良好，規(guī)則腳本提供的靈活性完全可以滿足日常監(jiān)控報警功能擴展的需求。