劉小磊,程偉華,章路進
(江蘇電力信息技術有限公司,江蘇南京 210000)
Prometheus 是以SoundCloud 開發軟件為基礎的開源型時序數據庫結構,同時融合了Go 語言與BorgMon 語言應用優勢,可在建立相同時序標簽文件的同時,在時間維度方面對連續數據信息進行集合狀存儲。時序標簽文件由名字、key/value 協議兩部分共同組成。一般來說,只有名字及標簽協議的定義形式完全相同,才能判定兩類時序數據的存儲形式完全相同[1-2]。在云計算環境中,Prometheus 數據庫主要負責對資源數據信息進行定向存儲與分析,再借助穩定的全鏈路應用環境,將信息參量傳輸至下級設備主機中。
由于資源傳輸環境的復雜性,云計算資源必須經過平臺主機的集中調度才能傳輸至下級應用設備之中。為適應上述應用需求,傳統云端網絡型監控系統借助OpenStack 組件,在虛擬機上布設與資源對象相關的服務器節點,再利用Ceilometer 模塊對所收集到的數據信息文件進行針對性分析。然而,該系統在單位時間內的動態資源統籌能力有限,并不能實現對云計算主機的全面監控與管理。
為解決此問題,設計基于Prometheus的云計算資源全鏈路監控系統,在滿足云資源數據收集需求的同時,完善Prometheus 數據庫的實際連接能力,再聯合云平臺架構,實現對監控信息的及時獲取與處理。
全鏈路監控系統的總體應用環境設計包含云平臺整體架構搭建、功能需求分析、性能需求分析三個處理環節,具體操作流程如下。
云平臺架構管理云計算資源全鏈路監控系統中的所有數據傳輸服務,由基礎設施層、虛擬化層、中間件管理層、用戶服務層四部分共同組成。基礎設施層包含計算資源、存儲資源、網絡資源三類應用架構,可將云資源信息整合成既定的數據包傳輸形式[3]。虛擬化層包含大量的VM 節點,且這些節點結構大體上滿足兩極化分布的形式,其中,一部分用于Xen 體系,另一部分用于形成Vmware 體系,但由于Prometheus 數據庫的存在,上述兩類模塊結構可對云計算資源信息進行分級整合與處理。中間件管理層總覽云平臺架構中的所有Web 服務,可在形成虛擬化應用模式的同時,對其他中間件的實際連接行為進行管理與調節[4-5]。其整體架構如圖1 所示。

圖1 云平臺整體架構示意圖
1)虛擬監控節點管理
功能描述:系統管理員具有直接添加虛擬監控節點的能力,可在修改云計算資源信息的同時,對數據文件進行增、刪、改、查處理。
2)虛擬節點的基本資源監控
功能描述:針對不同云計算主機的資源監控需求,通過綜合配置的方式,更改Prometheus 數據庫中存儲的資源信息,再分別從負載量、內存使用情況、CPU 使用率等多個角度,對現有的數據資源監控行為進行實時監控[6]。
3)云計算網絡服務監控
功能描述:在云計算監控系統的服務器端,確定Prometheus 數據庫主機中網絡服務的實際配置情況,再根據所顯示的虛擬節點進行配置量的設計,對資源數據監控服務的執行狀態進行集中監控。
4)對云網絡服務器進行監控
功能描述:根據云計算應用服務器的具體分布情況及與下級監控主機相關的指令需求,對Prometheus數據庫中的資源數據采集系數進行配置,并可根據監控服務器的狀態數據屬性,對云計算資源信息的細節情況進行準確地標注[7]。
5)存儲監控信息
功能描述:將各個云資源數據采集器中的信息參量整合成既定的傳輸與存儲形式。
6)顯示監控信息的傳輸情況
功能描述:將已存儲的云計算資源數據轉換成全鏈路監控系統所需的.txt文本形式。
云計算資源全鏈路監控系統的性能需求表現在動態性與實時性兩個方面:
在實際應用過程中,資源數據采集器每隔固定時長采集一次信息參量,并可在Prometheus 數據庫主機的作用下,實時將當前資源數據傳輸至下級監控服務器終端。由于全鏈路時間序列條件的存在,云計算資源數據并不能在系統數據庫主機中進行長時間存儲,這也是全鏈路監控系統中的數據信息參量只能保持快速傳輸行為的主要原因[8-9]。
設β代表云計算資源數據的定向采集系數,代表單位時間內的云計算資源數據采集特征值,聯立上述物理量,可將全鏈路監控系統的性能需求條件定義為:

其中,代表全鏈路環境下的云計算資源數據傳輸均值,μ代表Prometheus 數據庫主機中的全鏈路時間序列系數,代表云計算資源數據的動態量化條件。
按照全鏈路監控系統的總體設計需求,分別從數據收集、數據庫連接、信息獲取三個方面,完善云計算平臺的軟件執行環境,兩相結合完成新型監控系統的搭建與應用。
在云計算資源全鏈路監控系統環境中,Prometheus主機可以通過三種方式獲取數據測量值:
被監控資源主體把數據信息以通知消息的形式發送到主機,Prometheus 主機中的全鏈路感應設備會直接獲取與監控結果相關的資源信息,并從中獲取系統運行所必需的資源數據[10]。
Prometheus 主機中全鏈路感應設備可根據監控系統中云計算主機的配置情況,主動向已存儲文件提出API 申請指令,并可按照通信協議中被監控對象數據的消耗情況,分析資源數據所處的實時傳輸位置。
全鏈路監控系統的底層應用用戶可以通過調用Prometheus 主機中已存儲數據文件的方式,將已隱藏的資源信息全部讀出,并從中選取可供系統直接利用的資源信息,生成全新的傳輸與應用文檔[11]。
Prometheus 數據庫可將云計算資源由自由分布的形式轉化為滿足系統應用需求的監控信息文件,且在此過程中,所有數據信息都會經過全鏈路環境的多次過濾,直至將不滿足系統執行需求的信息參量全部返還于原始的云計算環境之中[12-13]。Prometheus主機作為數據庫環境中的核心應用設備,同時負責安排監控系統運行所需的數據過濾與資源信息收集指令,一方面可將完成篩查的數據資源反饋至全鏈路體系中,另一方面也可為云環境提供相對穩定的運行支撐條件[14]。簡單來說,Prometheus 數據庫作為云計算資源全鏈路監控系統的數據中轉設備,具有較強的信息統籌能力,可將待處理的信息參量全部轉化為傳輸數據的形式,并對其進行暫時存儲。其連接結構如圖2 所示。

圖2 Prometheus數據庫連接結構
在已知Prometheus 數據庫存儲能力的情況下,系統主機匹配的監控信息的獲取條件受到云計算資源數據收集形式的直接影響。一般來說,全鏈路監控系統中Prometheus 數據庫主機所具備的信息存儲能力始終保持定值存在狀態,而由于資源數據收集形式的不同,最終輸出的監控信息運行指令也有所不同,但基本上滿足輸入量越大,輸出量也越大的執行標準[15-16]。
設代表Prometheus 數據庫主機的額定資源量存儲條件,Mmax代表單位時間內的云計算資源數據傳輸最大值,聯立式(1),可將全鏈路監控系統的信息獲取結果表示為:

式中,λ代表云計算資源數據的定向收集系數,代表與Prometheus 數據庫相關的資源信息存儲量均值。
至此,完成各級軟硬件執行環境的搭建,在Prometheus 數據庫主機的支持下[17],實現云計算資源全鏈路監控系統的順利應用。
按照圖3 所示結構,布設監控系統執行環境,分別采用基于Prometheus 的云計算資源全鏈路監控系統、云端網絡型監控系統對用戶端的信息獲取行為進行干擾,其中,前者作為實驗組,后者作為對照組。監控系統的執行環境如圖3 所示。

圖3 監控系統執行環境
實驗過程中,Ceilometer Agent 主機負責輸入待處理的云計算資源數據,API Server 主機負責將已輸入的云計算資源數據整合成包狀傳輸形式,監控數據存儲主機負責對云計算資源數據進行暫時存儲,并可根據數據流的后續傳輸形式,確定監控指令所能到達的最遠傳輸位置。
動態資源統籌能力由云數據傳輸速率、監控指令運行時長兩部分共同組成,若不考慮其他干擾條件對實驗結果造成的影響,則可認為云數據傳輸速率越快、監控指令運行時長越短,動態云計算資源的統籌能力也就越強。
圖4 記錄了實驗組、對照組云數據傳輸速率的實際變化情況。

圖4 云數據傳輸速率變化曲線
分析圖4 可知,實驗組、對照組云數據傳輸速率均保持上升、下降交替出現的變化趨勢,但實驗組的差值水平明顯大于對照組。從極限值的角度來看,實驗組最大值為9.32 MB/s、最小值為5.63 MB/s,對照組最大值為6.51 MB/s、最小值為2.86 MB/s,分別對比可知,實驗組的實驗數值水平明顯高于對照組。
綜上可知,應用基于Prometheus 的全鏈路監控系統后,云數據資源的傳輸速率水平開始明顯升高,在增強動態云計算資源統籌能力方面具有一定的促進性作用。
表1 記錄了實驗組、對照組監控指令運行時長的實際變化情況。

表1 監控指令運行時長對比
分析表1 可知,實驗組、對照組的監控指令運行時長均隨云數據資源量的累積,呈現不斷增大的變化趨勢。從平均值角度來看,實驗組均值19.4 s 與對照組均值28.6 s 相比,下降了9.2 s。而從極限值角度來看,實驗組最大值22.2 s 與對照組最大值35.3 s 相比,下降了13.1 s。
綜上可知,在Prometheus 數據庫的作用下,云數據資源量監控指令運行時間的延長趨勢得到了有效控制,在一定程度上,提升了云計算資源統籌能力。
文中將云計算資源全鏈路監控系統與Prometheus數據庫聯合,對云平臺整體架構進行初步建設,再從功能需求與性能需求兩方面入手,收集并提取已存儲的云資源數據。在實用性方面,這種全鏈路型監控系統分別從數據傳輸速率、監控指令運行時間兩個方向,對云網絡的動態資源統籌能力進行提升,在實際應用過程中,能夠較好適應云計算環境的全方位調節與分配需求。