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

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

0 引 言

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

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

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

1 相關(guān)工作

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

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

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

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

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

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

2 問(wèn)題分析

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

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

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

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

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

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

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

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

綜上，對(duì)于集群監(jiān)控系統(tǒng)來(lái)說(shuō)，單個(gè)節(jié)點(diǎn)需要采集的數(shù)據(jù)指標(biāo)就已非常可觀，若對(duì)多個(gè)節(jié)點(diǎn)監(jiān)控指標(biāo)同時(shí)采集，數(shù)量集將是非常龐大的，并且隨著監(jiān)控節(jié)點(diǎn)數(shù)的增加數(shù)據(jù)量也會(huì)成倍增加，這無(wú)疑會(huì)給集群監(jiān)控系統(tǒng)性能方面的表現(xiàn)造成影響。

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

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

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

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

續(xù)表1

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

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

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

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

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

3.2 模塊功能

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

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

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

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

3.3 環(huán)境搭建

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2 系數(shù)量化處理

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

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

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

集群監(jiān)控系統(tǒng)中的數(shù)據(jù)收集依賴于各個(gè)Collectd節(jié)點(diǎn)，數(shù)據(jù)存儲(chǔ)結(jié)合Gnocchi服務(wù)。首先對(duì)以下幾個(gè)主要組件進(jìn)行說(shuō)明。Collectd_gnocchi作為一種插件，幫助Collectd發(fā)送給Gnocchi的數(shù)據(jù)接口。Gnocchi_metricd是單獨(dú)的線程Thread Worker，從Gnocchi的前端Sack中取任務(wù)節(jié)點(diǎn)，并存儲(chǔ)到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ù)壓縮完畢之后通過(guò)網(wǎng)絡(luò)中的http請(qǐng)求與post請(qǐng)求，隨后數(shù)據(jù)進(jìn)行解壓縮后，Gnocchi_api負(fù)責(zé)接收數(shù)據(jù)包，Gnocchi_metricd中的線程將分別從Gnocchi的前端目錄中調(diào)取任務(wù)節(jié)點(diǎn)。

圖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緩存中提取對(duì)應(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)

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

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

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

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

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

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

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

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

5 系統(tǒng)實(shí)驗(yàn)與評(píng)估

5.1 實(shí)驗(yàn)環(huán)境

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

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

5.2 實(shí)驗(yàn)結(jié)果

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

表5 監(jiān)控?cái)?shù)據(jù)壓縮前后對(duì)比

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

表6 監(jiān)控?cái)?shù)據(jù)各流程壓縮比

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

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

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

6 結(jié) 語(yǔ)

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

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