一種基于流媒體壓縮算法的高性能集群監(jiān)控系統(tǒng)

樊書華 王 鵬 汪 衛(wèi)

1(復(fù)旦大學(xué)軟件學(xué)院 上海 201203)2(復(fù)旦大學(xué)計算機(jī)科學(xué)技術(shù)學(xué)院 上海 200433)

0 引 言

隨著互聯(lián)網(wǎng)的蓬勃發(fā)展，計算機(jī)集群系統(tǒng)已應(yīng)用在人們生活的各個方面。集群的主要作用是對系統(tǒng)中各個節(jié)點的使用情況進(jìn)行實時的管理和掌握[1]，集群監(jiān)控系統(tǒng)也隨之應(yīng)運而生[2-4]。通過對集群的各項數(shù)據(jù)，包括應(yīng)用負(fù)載、CPU利用率、磁盤、網(wǎng)絡(luò)流量、內(nèi)存、應(yīng)用心跳等系統(tǒng)指標(biāo)，分別進(jìn)行收集存儲，并在處理分析后做出相應(yīng)判斷，當(dāng)發(fā)生異常情況時對系統(tǒng)管理員發(fā)送通知，從而達(dá)到實時監(jiān)控的效果。但是以人工的方式對集群進(jìn)行監(jiān)控管理存在著各種各樣的問題，比如效率過低、對系統(tǒng)異常的捕獲不夠及時等，因此集群監(jiān)控系統(tǒng)的實現(xiàn)程度將直接決定集群系統(tǒng)是否能夠平穩(wěn)運行。

然而隨著實際生產(chǎn)環(huán)境中業(yè)務(wù)的增加，集群規(guī)模逐漸擴(kuò)大，服務(wù)器收到密集的高負(fù)荷請求，現(xiàn)有的集群監(jiān)控系統(tǒng)如針對openstack開發(fā)的Ceilometer[5-6]、層次化監(jiān)控系統(tǒng)Ganglia[7-9]、企業(yè)級開源系統(tǒng)Zabbix[10]等，在性能表現(xiàn)方面容易產(chǎn)生瓶頸。以目前應(yīng)用較為廣泛的主流系統(tǒng)為例，Ceilometer在開源集群監(jiān)控系統(tǒng)中相對于其他幾個監(jiān)控系統(tǒng)，在完整性、輕量性等幾個方面很有優(yōu)勢[11]。但由于其使用單層的客戶端服務(wù)器模式來搭建監(jiān)控系統(tǒng)，當(dāng)集群規(guī)模擴(kuò)大時，數(shù)據(jù)的種類和規(guī)模都會擴(kuò)大，這樣數(shù)據(jù)采集、存儲就容易遇到瓶頸。

針對目前集群監(jiān)控系統(tǒng)存在的性能問題，本文旨在設(shè)計并實現(xiàn)一種基于流媒體壓縮算法的高性能集群監(jiān)控系統(tǒng)。首先，對性能問題的表現(xiàn)和問題產(chǎn)生的原因進(jìn)行介紹，包括監(jiān)控數(shù)據(jù)量的組成分析以及監(jiān)控數(shù)據(jù)幀的時間和空間冗余性分析；其次，對系統(tǒng)架構(gòu)以及對應(yīng)的功能模塊進(jìn)行描述；再次，分別從數(shù)據(jù)幀冗余性優(yōu)化、系數(shù)量化處理等模塊對系統(tǒng)高性能進(jìn)行設(shè)計與實現(xiàn)；最后結(jié)合系統(tǒng)實驗，給出性能提升具體結(jié)果與評估。

1 相關(guān)工作

當(dāng)前常用的壓縮算法包括LZ4、Brotli、LZF、Snappy等，接下來首先對這幾種算法進(jìn)行簡單介紹。

LZ4算法來源于LZ77，由Yann Collet在2011年發(fā)明。該算法采用滑動窗口的原理，通過哈希表對字典進(jìn)行存儲，從而對匹配的字符串進(jìn)行查找。其中哈希表的key值代表字符串的二進(jìn)制值，value值代表字符串在文件中對應(yīng)的位置。主要優(yōu)勢為壓縮效率高，當(dāng)需要壓縮的數(shù)據(jù)中出現(xiàn)的重復(fù)項越多時，壓縮效果越好。

無損壓縮算法Brotli在2015年由Google提出，通過哈夫曼編碼以及變種的LZ77算法等方式對數(shù)據(jù)進(jìn)行壓縮，主要用于處理順序數(shù)據(jù)流。該算法不僅包含常見的滑動窗口字典，也對常見字符串字典進(jìn)行了預(yù)定義，從而增強(qiáng)壓縮效果。Brotli算法已受到絕大多數(shù)主流瀏覽器的支持，達(dá)到加快傳輸速度的效果。

LZF算法對字符串通過LZ77及LZSS的混合編碼進(jìn)行壓縮，由入口文件、壓縮和解壓縮文件、配置及接口文件組成。LZF算法較為輕量，Redis中默認(rèn)采用該算法，在數(shù)據(jù)存儲至本地時進(jìn)行壓縮處理。

Snappy算法在2011年開源，來自于Zippy并由C++語言實現(xiàn)，該算法以壓縮率和兼容性為一定代價，實現(xiàn)較高壓縮速度以及壓縮比的目標(biāo)，壓縮速度達(dá)到250 MB/s甚至更高。Snappy算法在Google很多內(nèi)部項目諸如MapReduce以及BigTable中得到了廣泛使用。

但在這些傳統(tǒng)的數(shù)據(jù)壓縮算法中，通過字符串匹配和哈希字典等方式進(jìn)行壓縮，雖然在單個時間片單個數(shù)據(jù)幀上效果很好，但沒有考慮到集群監(jiān)控系統(tǒng)中數(shù)據(jù)幀在時間軸上的冗余性。此外，這些壓縮算法還需要在主從兩個節(jié)點之間同步字典數(shù)據(jù)，這會帶來額外的網(wǎng)絡(luò)帶寬開銷。因此本文旨在設(shè)計一種新的基于流媒體壓縮的算法用于集群監(jiān)控系統(tǒng)中，從而對系統(tǒng)性能進(jìn)行有效提升。

2 問題分析

集群監(jiān)控系統(tǒng)的性能瓶頸主要表現(xiàn)如下，以ceilometer監(jiān)控系統(tǒng)為例：在其余參數(shù)恒定的條件下，服務(wù)器端(即時序數(shù)據(jù)庫gnocchi)單位時間內(nèi)可以處理的數(shù)據(jù)量會隨客戶端(數(shù)據(jù)采集器collectd)的緩沖區(qū)大小(單個restful請求包含的數(shù)據(jù)量)的變化而呈線性增長，即：當(dāng)緩沖區(qū)大小為100條時，單位時間可以處理的restful請求為600條，單位時間可以處理的數(shù)據(jù)量為6萬條；緩沖區(qū)大小為500條時，單位時間可以處理的 restful 請求為533條，單位時間可以處理的數(shù)據(jù)量為27萬條。

根據(jù)目前配置，當(dāng)客戶端緩沖區(qū)的大小為200條時，服務(wù)器端時序數(shù)據(jù)庫在單位時間內(nèi)能夠處理的restful請求大概在500條，其中包括的數(shù)據(jù)條目大概為10萬條。以單個被監(jiān)控節(jié)點一次輪詢的6 000條數(shù)據(jù)為基準(zhǔn)，假如被監(jiān)控節(jié)點數(shù)目為200臺(在不考慮客戶端相同數(shù)據(jù)重發(fā)的狀態(tài)下，實際上隨著寫線程數(shù)量的增長，數(shù)據(jù)采集器緩沖隊列里的內(nèi)容被重發(fā)的概率也越高)，在單次輪詢時間10秒內(nèi)會產(chǎn)生120萬條數(shù)據(jù)，這樣會使得數(shù)據(jù)庫阻塞，隨著寫線程的增多，不到200臺主機(jī)就會使得數(shù)據(jù)庫發(fā)生阻塞。當(dāng)然按照網(wǎng)絡(luò)流量數(shù)據(jù)，200臺主機(jī)的網(wǎng)絡(luò)流量為100 MB/s，達(dá)到了百兆網(wǎng)卡極限，也是千兆網(wǎng)卡的10%，會給網(wǎng)絡(luò)流量產(chǎn)生很大壓力。

接下來，對目前集群監(jiān)控系統(tǒng)中存在的性能方面的問題原因，分別對監(jiān)控數(shù)據(jù)量以及數(shù)據(jù)幀在時間和空間上的冗余性進(jìn)行分析。

2.1 數(shù)據(jù)量分析

當(dāng)集群規(guī)模擴(kuò)大時，服務(wù)器收到的請求密度變大，此時容易產(chǎn)生阻塞現(xiàn)象。以單臺宿主機(jī)為例，在單位時間內(nèi)需要向服務(wù)器發(fā)送高達(dá)0.5～1 MB的時序數(shù)據(jù)集(包括物理機(jī)信息，虛擬機(jī)信息和docker信息)。以單次輪詢來看，一次性需要收集的數(shù)據(jù)就達(dá)到了幾千條，當(dāng)宿主機(jī)規(guī)模達(dá)到一定量以后，監(jiān)控整體系統(tǒng)性能將會受到嚴(yán)重阻塞，影響監(jiān)控效率。

針對采集到的監(jiān)控指標(biāo)，數(shù)據(jù)類型可以分為以下幾個部分，包括中央處理器、進(jìn)程、網(wǎng)絡(luò)、內(nèi)存、硬盤等。針對單臺物理計算節(jié)點而言，監(jiān)控數(shù)據(jù)量具有兩個主要規(guī)律：

? 橫向增長：針對單臺物理計算節(jié)點而言，隨著主機(jī)上搭載的虛擬機(jī)數(shù)目增加，對應(yīng)的虛擬機(jī)指標(biāo)，主機(jī)全體指標(biāo)將隨之增長；

? 縱向增長：物理機(jī)中隨著CPU核數(shù)的增長，對應(yīng)的各項監(jiān)控數(shù)據(jù)指標(biāo)，包括總使用量、steal百分比、空閑百分比、IO等待百分比、用戶百分比等也呈線性增長趨勢，這一規(guī)律對網(wǎng)卡、進(jìn)程、磁盤也有效。

綜上，對于集群監(jiān)控系統(tǒng)來說，單個節(jié)點需要采集的數(shù)據(jù)指標(biāo)就已非?？捎^，若對多個節(jié)點監(jiān)控指標(biāo)同時采集，數(shù)量集將是非常龐大的，并且隨著監(jiān)控節(jié)點數(shù)的增加數(shù)據(jù)量也會成倍增加，這無疑會給集群監(jiān)控系統(tǒng)性能方面的表現(xiàn)造成影響。

2.2 數(shù)據(jù)幀冗余性分析

數(shù)據(jù)幀主要具有時間和空間兩方面的冗余性。采集到的數(shù)據(jù)幀以哈希表(python字典)的形式進(jìn)行存儲，例如[{′df-sys-fs-cgroup@precent_bytes-free′: {′Timestamp′: 1546498760.7887914, ′Value′: 100.0}}]，如表1所示，時空冗余性主要體現(xiàn)在如下兩個方面：

? 空間冗余性方面，在某一個時間點t1上，所有數(shù)據(jù)項的時間戳在小數(shù)點之前(即秒級單位)都是相同的，小數(shù)點之后的差別可以忽略不計，故只保留一個時間戳即可。同時形如′Timestamp′和′Value′這樣重復(fù)的鍵值也是產(chǎn)生空間冗余的原因。

? 時間冗余性方面，在兩個時間點t1和t2上，兩幀數(shù)據(jù)的表項名稱都是相同的。因此每隔一定時間對監(jiān)控數(shù)據(jù)進(jìn)行采集時，總會對各個監(jiān)控項的子條目名稱進(jìn)行高覆蓋率的重復(fù)收集，這是時間冗余數(shù)據(jù)產(chǎn)生的原因。

續(xù)表1

3 總體架構(gòu)與環(huán)境搭建

3.1 系統(tǒng)架構(gòu)

在本文實現(xiàn)的基于流媒體壓縮算法的高性能集群監(jiān)控系統(tǒng)架構(gòu)中，如圖1所示，以數(shù)據(jù)收集、數(shù)據(jù)存儲、數(shù)據(jù)分析為基本層級，之后將分析處理后的數(shù)據(jù)實現(xiàn)展示、報警以及自適應(yīng)等功能。在數(shù)據(jù)收集層，通過給各個數(shù)據(jù)采集器collectd節(jié)點添加插件(主機(jī)監(jiān)控插件，libvirt插件以及docker插件)，從而定期地對系統(tǒng)和程序中各個指標(biāo)進(jìn)行收集。

圖1 集群監(jiān)控系統(tǒng)架構(gòu)

針對時序數(shù)據(jù)庫，實現(xiàn)對物理機(jī)、虛擬機(jī)以及容器的同時監(jiān)控。數(shù)據(jù)采集之后采用過濾器連接Gnocchi服務(wù)，采用最新的流式壓縮算法實現(xiàn)高效的數(shù)據(jù)存儲和傳輸機(jī)制，從而實現(xiàn)數(shù)據(jù)存儲層要求。此外，數(shù)據(jù)展示層是與用戶最相近的一層，對Grafana組件進(jìn)行定制，以集中統(tǒng)一的方式實現(xiàn)數(shù)據(jù)的展示，給系統(tǒng)管理員帶來便捷。

3.2 模塊功能

本文實現(xiàn)的集群監(jiān)控系統(tǒng)中包括數(shù)據(jù)收集、數(shù)據(jù)存儲、數(shù)據(jù)處理等在內(nèi)的各個功能。

在資源采集方面，數(shù)據(jù)采集階段引入Collectd守護(hù)進(jìn)程[13]，并以在Collectd上實現(xiàn)插件的形式，完成對系統(tǒng)以及系統(tǒng)中應(yīng)用程序的各類性能指標(biāo)進(jìn)行定期的收集任務(wù)。同時，面對海量的數(shù)據(jù)收集過程，本文在數(shù)據(jù)采集器的性能方面進(jìn)行了有效的提升。首先，對Collectd所采集的大批量數(shù)據(jù)進(jìn)行精簡化，其次，采用壓縮數(shù)據(jù)的方法，減小了網(wǎng)絡(luò)中的帶寬壓力。最后，通過調(diào)整數(shù)據(jù)采集器的發(fā)送流程，當(dāng)阻塞的時間超過提前設(shè)定的閾值時，對該數(shù)據(jù)進(jìn)行丟棄處理。

在高效的數(shù)據(jù)傳輸和存儲方面，采用了Gnocchi這一款開源的時序數(shù)據(jù)庫。Gnocchi專門為處理大規(guī)模時序數(shù)據(jù)的存儲和索引而設(shè)計，在數(shù)據(jù)存入之前就對相應(yīng)數(shù)據(jù)進(jìn)行了聚合操作，從而提高了數(shù)據(jù)訪問效率。

在系統(tǒng)界面方面，隨著系統(tǒng)中業(yè)務(wù)發(fā)展的日益復(fù)雜化，若對集群監(jiān)控的過程中隨時對系統(tǒng)中的運行情況進(jìn)行掌握，監(jiān)控數(shù)據(jù)的可視化展示部分是集群監(jiān)控系統(tǒng)必不可少的組件。在與用戶主要交互的數(shù)據(jù)展示層，本文通過對Grafana的組件和模板采用定制的方式，對所需要監(jiān)控的集群來進(jìn)行整齊統(tǒng)一的管理。

3.3 環(huán)境搭建

本文實現(xiàn)的集群監(jiān)控系統(tǒng)整體環(huán)境為：通過Kolla Ansible對OpenStack進(jìn)行部署。其中，Ansible本身是專門為分布式集群安裝程序的框架，Kolla是Ansible的子項目，以Ansible為基礎(chǔ)，專門為OpenStack提供服務(wù)。Docker作為一個開源的應(yīng)用容器引擎，目標(biāo)在于為操作系統(tǒng)的虛擬化提供輕量級的解決方案，相當(dāng)于小的封閉式操作系統(tǒng)環(huán)境，同時具有快速的部署和交付能力，以及良好的擴(kuò)容性和資源利用率。如表2所示，集群搭建的機(jī)器環(huán)境包括服務(wù)器端和客戶端。

表2 集群監(jiān)控環(huán)境

對監(jiān)控環(huán)境Collectd以及Gnocchi來說，服務(wù)器端(數(shù)據(jù)采集端)配置與客戶端(數(shù)據(jù)發(fā)送端)配置如表3所示。

表3 集群服務(wù)配置

4 系統(tǒng)設(shè)計與實現(xiàn)

針對高密度的數(shù)據(jù)請求容易產(chǎn)生的阻塞現(xiàn)象這一問題，如圖2所示，本文的主要解決思路為：通過引入流式數(shù)據(jù)壓縮，對傳輸?shù)臄?shù)據(jù)進(jìn)行壓縮處理。在H.264編碼算法中，主要分為正在編碼的幀和參考幀，參考幀即為已經(jīng)編碼且經(jīng)過了重新解碼。根據(jù)正在編碼的幀得到當(dāng)前宏塊，同時結(jié)合參考幀進(jìn)行預(yù)測，從而得到預(yù)測宏塊。預(yù)測宏塊作用于當(dāng)前宏塊獲得殘差宏塊，并進(jìn)行變換和量化處理，隨后的過程主要分為兩部分：變換和量化后進(jìn)行熵編碼，獲取編碼后的比特流；通過反變換和反量化產(chǎn)生解碼殘差宏塊，進(jìn)而獲得參考幀。

圖2 流式數(shù)據(jù)壓縮H.264編碼算法

在具體分析如何對系統(tǒng)性能進(jìn)行提升之前，首先需要對系統(tǒng)中對數(shù)據(jù)的收集過程進(jìn)行了解。本文采用數(shù)據(jù)采集器Collectd及相應(yīng)插件對集群系統(tǒng)的監(jiān)控指標(biāo)進(jìn)行收集之后，通過Redis寫入Gnocchi數(shù)據(jù)庫。

如圖3所示，數(shù)據(jù)采集器Collectd收集到的數(shù)據(jù)以列表的形式進(jìn)行存儲。每臺主機(jī)上采集到的數(shù)據(jù)格式包括接口、內(nèi)存、進(jìn)程、網(wǎng)絡(luò)等監(jiān)控項，每類監(jiān)控項又包含數(shù)個子條目。列表中的每個元素都包含監(jiān)測數(shù)據(jù)項與標(biāo)簽兩個部分，標(biāo)簽以0和1進(jìn)行區(qū)分，0代表該項未被線程讀，1則代表已讀。系統(tǒng)中存在n個讀線程read_thread worker，首先確認(rèn)列表中元素的標(biāo)簽值，若標(biāo)簽為0則進(jìn)行讀取，并寫入到隊列write_queue_s的隊尾處。隊列write_queue_s遵循先入先出的規(guī)則，因此對于寫線程write_thread worker，依照從隊列頭部讀取數(shù)據(jù)的順序通過write-http請求寫入數(shù)據(jù)庫。

圖3 集群數(shù)據(jù)讀寫

4.1 數(shù)據(jù)幀冗余性優(yōu)化算法

在數(shù)據(jù)幀時空冗余性方面，結(jié)合第2節(jié)問題分析中的冗余性詳解，優(yōu)化主要分為以下步驟：

? 對采集到的監(jiān)控數(shù)據(jù)項來說，列表中每個元素的時間戳屬性都非常接近，因此采取將時間戳規(guī)整到同一個值的方法，并歸并到數(shù)據(jù)幀外達(dá)到有效壓縮的效果，從而大大減少同一次收集的數(shù)據(jù)幀中時間戳出現(xiàn)的頻率。

? 在數(shù)據(jù)集的Value項中，未經(jīng)優(yōu)化的值小數(shù)點后取到了十幾位以上。因此本文通過對較低位，即無效位數(shù)進(jìn)行裁剪，達(dá)到對系統(tǒng)性能實現(xiàn)優(yōu)化的目標(biāo)。

在數(shù)據(jù)幀的時間冗余性優(yōu)化方面，首先數(shù)據(jù)采集器Collectd對節(jié)點采集監(jiān)控指標(biāo)數(shù)據(jù)，同時對不同的時間點來說，采集到的兩段計算資源的數(shù)據(jù)項名稱大部分時間都是相同的。如磁盤的子條目包括df_complext_reserved、df_complex_used，CPU的子條目為percent system、percent interrupt。因此，每隔一定時間對監(jiān)控數(shù)據(jù)進(jìn)行采集時，各個監(jiān)控項收集的相應(yīng)子條目名稱重復(fù)率也非常高。

為了提升系統(tǒng)性能，本文設(shè)計了運行在數(shù)據(jù)采集器Collect的與數(shù)據(jù)庫Gnocchi之間的數(shù)據(jù)幀同步協(xié)議(Datagram Synchronization Protocol)。數(shù)據(jù)采集器Collectd在對監(jiān)控數(shù)據(jù)處理進(jìn)入Gnocchi數(shù)據(jù)庫之前，使用Redis的緩存設(shè)計，在寫入Gnocchi之前，首先進(jìn)入Redis緩沖區(qū)，從而達(dá)到加快讀寫速度的效果。同時，采集到的監(jiān)控先將所有的監(jiān)控條目名記錄到緩存中，然后將壓縮后的值寫入到對應(yīng)條目的值中。

如圖4所示，數(shù)據(jù)庫Gnocchi與數(shù)據(jù)采集器Collectd之間的數(shù)據(jù)幀同步協(xié)議的整體流程為：

圖4 數(shù)據(jù)幀同步協(xié)議

? 首先數(shù)據(jù)采集器Collectd對需要監(jiān)控的指標(biāo)進(jìn)行數(shù)據(jù)收集，數(shù)據(jù)幀格式為包含哈希表的列表，即{監(jiān)控條目名: [時間戳，值]}。同時，一個寫線程write-thread對應(yīng)一個plugin-collectd-gnocchi。

? 進(jìn)入到數(shù)據(jù)緩沖區(qū)Data Buffer后，本文對監(jiān)控數(shù)據(jù)項使用字典結(jié)構(gòu)(Dictionary)，字典中的key存儲監(jiān)控項的名稱，value為該監(jiān)控項的對應(yīng)值。

? Redis緩沖區(qū)中含有Incoming Driver，其中包含各個目錄，如temp/dir1、temp/dir2等，之后每個目錄節(jié)點將各自由一個metricd worker進(jìn)行處理。Redis緩沖區(qū)中先存儲監(jiān)控條目名，即字典中的key，隨后每個條目名的對應(yīng)值等待下個步驟傳輸。

? 數(shù)據(jù)采集到服務(wù)器端，而數(shù)據(jù)的預(yù)處理過程放到客戶端進(jìn)行。在數(shù)據(jù)采集緩沖區(qū)中保留最新數(shù)據(jù)幀，當(dāng)產(chǎn)生新的數(shù)據(jù)幀時，與緩沖區(qū)中已有的數(shù)據(jù)幀作對比，檢測兩個數(shù)據(jù)幀是否高度相似，假如兩者數(shù)據(jù)相似度非常高，則不再進(jìn)行發(fā)送操作。

? 在本文提出的數(shù)據(jù)同步協(xié)議中，數(shù)據(jù)分為兩種類型，對于完整數(shù)據(jù)complete_data來說，以類型為0標(biāo)記，調(diào)用函數(shù)0寫入Redis緩存中對應(yīng)條目名的value值，對于壓縮數(shù)據(jù)compressed_data來說，以類型為1進(jìn)行標(biāo)記，通過函數(shù)1寫入Redis緩存。

? 兩個緩沖區(qū)中的內(nèi)容保持同步，假如發(fā)現(xiàn)了新的數(shù)據(jù)，在數(shù)據(jù)緩沖區(qū)Data Buffer與Incoming Driver兩個緩沖區(qū)都沒有保存，則認(rèn)為該數(shù)據(jù)為complete data，類型為0，發(fā)送完整數(shù)據(jù)包，并在緩沖區(qū)中生成對應(yīng)的數(shù)據(jù)幀；若發(fā)送的數(shù)據(jù)幀中條目比緩沖區(qū)中的條目少，則多出來的條目對應(yīng)值保持原始值不變。

下面對算法進(jìn)行定義：

算法1數(shù)據(jù)幀冗余性優(yōu)化算法

輸入：來自于單個數(shù)據(jù)采集節(jié)點的日志log={log_msgi|i=1,2,…,N}，其中單位子日志log_msgi以字典的形式進(jìn)行存儲，具體格式如下：log_msgi=[{Entryname:{Timestamp,Value}}]。

輸出：基于流媒體壓縮的日志數(shù)據(jù)。

1) 數(shù)據(jù)幀原有序列中的key值，即監(jiān)控項名稱，轉(zhuǎn)換為對應(yīng)序列號；

2) 合并數(shù)據(jù)幀中的時間戳，并抽取Timestamp中的公共部分進(jìn)行統(tǒng)一；

3) 消除數(shù)據(jù)幀條目中的冗余表項名；

4) 當(dāng)產(chǎn)生新數(shù)據(jù)時，與緩沖區(qū)已有數(shù)據(jù)作對比，檢測是否高度相似，若相似度較高則不再進(jìn)行操作。

4.2 系數(shù)量化處理

針對時序數(shù)據(jù)中因為數(shù)據(jù)過大而占資源過多的性能問題，本文對數(shù)據(jù)系數(shù)進(jìn)行了量化處理。找出一系列數(shù)據(jù)中盡可能接近的公因子進(jìn)行提取，從而使提取后的數(shù)據(jù)值變小，來達(dá)到減少傳輸數(shù)據(jù)量的目標(biāo)。

系數(shù)量化之前，取原數(shù)據(jù)序列{18, 9, 46, 27, 35}中各個數(shù)據(jù)最為接近的公因子9作為公共系數(shù)，在提取該系數(shù)之后，產(chǎn)生新序列：9{2,1,5,3,4}。通過量化處理，能夠減少數(shù)據(jù)存放空間，對系統(tǒng)的表現(xiàn)性能產(chǎn)生優(yōu)化作用。為了還原原始數(shù)據(jù)，可以通過量化后的數(shù)據(jù)序列與系數(shù)結(jié)合，產(chǎn)生{18, 9, 45, 27, 36}。

4.3 系統(tǒng)實現(xiàn)

集群監(jiān)控系統(tǒng)中的數(shù)據(jù)收集依賴于各個Collectd節(jié)點，數(shù)據(jù)存儲結(jié)合Gnocchi服務(wù)。首先對以下幾個主要組件進(jìn)行說明。Collectd_gnocchi作為一種插件，幫助Collectd發(fā)送給Gnocchi的數(shù)據(jù)接口。Gnocchi_metricd是單獨的線程Thread Worker，從Gnocchi的前端Sack中取任務(wù)節(jié)點，并存儲到Gnocchi的后端數(shù)據(jù)。gnocchiClient為Collectd_gnocchi調(diào)用的發(fā)送數(shù)據(jù)包的接口。Gnocchi_api負(fù)責(zé)接受數(shù)據(jù)包。

數(shù)據(jù)壓縮與解壓縮流程如圖5所示。首先Collected_gnocchi將Collectd收集的數(shù)據(jù)發(fā)送到Gnocchi的數(shù)據(jù)接口Client，數(shù)據(jù)壓縮完畢之后通過網(wǎng)絡(luò)中的http請求與post請求，隨后數(shù)據(jù)進(jìn)行解壓縮后，Gnocchi_api負(fù)責(zé)接收數(shù)據(jù)包，Gnocchi_metricd中的線程將分別從Gnocchi的前端目錄中調(diào)取任務(wù)節(jié)點。

圖5 數(shù)據(jù)壓縮與解壓縮

客戶端和服務(wù)器端的部分代碼如下：

# 客戶端部分代碼

Def preparePost(self, typeV)

refreshCache(raw[‘key’])

if data[type] == 0

data[key] = cacheDictionary

else if data[type] == 1

data[key] = valueList

# 服務(wù)器端部分代碼

Def processData(request)

getType_Data_Hostname_Timestamp

# 從Redis緩存中提取對應(yīng)數(shù)據(jù)，然后還原數(shù)據(jù)幀

if data[type] == 1

myDictionary = loads(redisGet(HostName))

myDataList = loads(Data);

getResultDictionary

# 存入Redis緩存

else if data[type] == 0

redisSet(myHostName, myData)

客戶端的核心代碼實現(xiàn)思路為：

1) 初始化函數(shù)定義整體數(shù)據(jù)幀緩存，并定義處理后的數(shù)據(jù)列表；

2) 當(dāng)新數(shù)據(jù)產(chǎn)生時，通過refreshCache函數(shù)起到刷新數(shù)據(jù)幀的作用；

3) 根據(jù)最新數(shù)據(jù)幀，generateData函數(shù)提取數(shù)據(jù)，并保留兩位小數(shù)；

4) 當(dāng)數(shù)據(jù)類型為0時，發(fā)送完整數(shù)據(jù)幀，當(dāng)數(shù)據(jù)類型為1時，發(fā)送壓縮后的數(shù)據(jù)幀。

服務(wù)器端的核心代碼實現(xiàn)思路為，通過Process_data函數(shù)，對兩種數(shù)據(jù)類型分別進(jìn)行處理：

1) 針對壓縮過的數(shù)據(jù)幀，從Redis緩存中提取相應(yīng)的數(shù)據(jù)，然后還原數(shù)據(jù)幀；

2) 針對未壓縮的數(shù)據(jù)幀，直接存儲Redis緩存。

5 系統(tǒng)實驗與評估

5.1 實驗環(huán)境

系統(tǒng)實驗采用1臺物理機(jī)搭載18個虛擬機(jī)的形式，具體實驗配置如表4所示。

表4 集群監(jiān)控系統(tǒng)高性能實驗配置

5.2 實驗結(jié)果

在分別對采集的監(jiān)控指標(biāo)進(jìn)行時間冗余性數(shù)據(jù)壓縮、空間冗余性數(shù)據(jù)壓縮、量化數(shù)據(jù)壓縮等一系列步驟后，數(shù)據(jù)壓縮前后對比如表5所示。

表5 監(jiān)控數(shù)據(jù)壓縮前后對比

本節(jié)對壓縮效果進(jìn)行了實驗測試，在時間間隔為10秒的前提下，每隔10秒對節(jié)點進(jìn)行監(jiān)控數(shù)據(jù)收集，為了比較多次實驗下相應(yīng)的壓縮效果，本文分別在時間軸10、20、30、40和50 s對節(jié)點取了5次監(jiān)控指標(biāo)數(shù)據(jù)，得到了數(shù)據(jù)在各個階段優(yōu)化后相應(yīng)壓縮結(jié)果。從表6中可以看出，壓縮的數(shù)據(jù)比例平均為原始數(shù)據(jù)的88.68%，壓縮后數(shù)據(jù)大小為原始數(shù)據(jù)的11.32%，其中時間冗余與空間冗余優(yōu)化的提升效果最為明顯，多次實驗平均優(yōu)化結(jié)果分別為35.33%和52.60%。

表6 監(jiān)控數(shù)據(jù)各流程壓縮比

同時本文將實現(xiàn)的流式高性能壓縮算法與當(dāng)前包括LZ4、Brotli、LZF、Snappy等在內(nèi)的主流日志壓縮算法進(jìn)行效果對比，具體結(jié)果如表7所示?？梢钥吹皆谶@些算法中，本文實現(xiàn)的流式算法達(dá)到了最好的壓縮效果，在兩組實驗測試數(shù)據(jù)中，壓縮后的數(shù)據(jù)對原始數(shù)據(jù)大小的比例分別為11.22%以及11.25%，其余四種傳統(tǒng)算法分別在14.86%到18.8%之間，說明本文設(shè)計的基于流媒體壓縮算法在實際數(shù)據(jù)采集中也有著可觀的性能表現(xiàn)。

表7 本文算法與LZ4、Brotli、LZF、Snappy算法效率對比

本文提出的基于流媒體壓縮算法在性能方面優(yōu)于其他主流壓縮算法的主要原因為：針對流式數(shù)據(jù)的時間冗余性與空間冗余性兩大特征，基于流媒體的壓縮算法通過信息同步的策略使得重復(fù)數(shù)據(jù)不再進(jìn)行傳輸；同時針對兩個時間節(jié)點來看，假如數(shù)值相近，本文減少一次信息的發(fā)送，從而進(jìn)一步減少信息的冗余。與傳統(tǒng)的數(shù)據(jù)壓縮算法相比，對數(shù)據(jù)幀在時間軸上的冗余性做出了良好的優(yōu)化。此外，這些壓縮算法會帶來額外網(wǎng)絡(luò)帶寬開銷的，本文算法計算大多分布在從屬節(jié)點上，因此不會對主節(jié)點帶來額外的計算開銷。

6 結(jié) 語

針對目前主流集群監(jiān)控系統(tǒng)在性能方面的問題，本文旨在對一種基于流媒體壓縮算法的高可用集群監(jiān)控系統(tǒng)進(jìn)行設(shè)計與實現(xiàn)。首先針對系統(tǒng)產(chǎn)生問題的原因，如監(jiān)控數(shù)據(jù)量在縱向?qū)用婧蜋M向?qū)用娴南鄳?yīng)增長規(guī)律，數(shù)據(jù)冗余性體現(xiàn)，結(jié)合從實際節(jié)點采集的數(shù)據(jù)幀格式進(jìn)行展示與分析。為了解決該問題，本文設(shè)計了運行在數(shù)據(jù)采集器Collect的與數(shù)據(jù)庫Gnocchi之間的新的數(shù)據(jù)幀同步協(xié)議，并先后從數(shù)據(jù)幀空間冗余性優(yōu)化、數(shù)據(jù)幀時間冗余性優(yōu)化、系數(shù)量化處理等步驟進(jìn)行實現(xiàn)。

在系統(tǒng)實驗中，每隔一段時間對實際節(jié)點進(jìn)行數(shù)據(jù)采集，經(jīng)過系統(tǒng)高性能設(shè)計與實現(xiàn)之后，數(shù)據(jù)優(yōu)化效果明顯，其中對數(shù)據(jù)幀的時間冗余性和空間冗余性的提升效果最為突出，壓縮比分別在35%與52%左右。從實驗結(jié)果可以看出，本文實現(xiàn)的高性能集群監(jiān)控系統(tǒng)在實際應(yīng)用場景中具有很大的發(fā)展?jié)摿Α?/p>