一種PaaS系統(tǒng)的數(shù)據(jù)監(jiān)控平臺的設計方案*

樊偉鈺 ，朱曉民

（1 北京郵電大學網絡與交換技術國家重點實驗室，北京 100876；2 東信北郵信息技術有限公司，北京 100191）

1 引言

伴隨著互聯(lián)網技術的快速發(fā)展，尤其是移動互聯(lián)網快速興起和發(fā)展，各種各樣的PaaS（Platform as a Service，平臺即服務）平臺隨之出現(xiàn)，業(yè)界比較著名的有Sina App Engine （SAE，新浪公司Web開發(fā)PaaS平臺）、Google App Engine（GAE，谷歌Web應用程序開發(fā)和托管平臺）、Cloud Foundry（CF，VMware公司推出的開源PaaS平臺）等，除此之外還有眾多的企業(yè)內部的私有PaaS平臺。

PaaS系統(tǒng)的出現(xiàn)及發(fā)展，在為Web應用開發(fā)提供巨大便利的同時，其系統(tǒng)本身、以及其中部署的應用和服務的監(jiān)控任務也開始面臨巨大的挑戰(zhàn)，如何處理及展示大量非結構的數(shù)據(jù)成為一項重要的內容[1,2]。

2 PaaS系統(tǒng)數(shù)據(jù)監(jiān)控現(xiàn)狀

2.1 PaaS平臺數(shù)據(jù)監(jiān)控的必要性

作為云計算的3種服務模型中的一種，PaaS具有云計算所有的特征，其中最重要的兩點，一是極大的節(jié)約計算機資源，二是使用戶更多的關注自己的業(yè)務實現(xiàn)，而不必過多考慮硬件資源的管理。為了滿足以上的需求，PaaS平臺一般具有以下幾個特征：自主 的（autonomous）， 協(xié) 作 的（cooperative）， 自 適應的（situational），可進化的（evolvable），應急的（emergent），可信賴的（trustworthy）[3～5]。為了滿足以上幾個特征，PaaS平臺需要具有自我管理的能力，而自我的監(jiān)控則是其中一項最基本的能力。

對于PaaS服務的提供者，需要實時了解PaaS平臺的運行狀態(tài)，每個系統(tǒng)組件的負荷，系統(tǒng)容量以及負載，并從監(jiān)控數(shù)據(jù)分析系統(tǒng)的性能瓶頸，從而不斷的優(yōu)化系統(tǒng)性能。對于PaaS平臺本身，為了能夠滿足自主、自適應等特性，需要實時獲取系統(tǒng)各組件的運行狀態(tài)、負載，從而實現(xiàn)故障組件的自動重啟，高負載組件自動擴容以及多余組件的自動關閉，實現(xiàn)資源的自動縮放。而對于PaaS服務的使用者，即應用開發(fā)者，監(jiān)控功能也是一項必須要提供的功能。開發(fā)者需要隨時了解所托管的應用運行狀態(tài)，資源占用情況，以及是否需要增加或減少所購買的資源等。由此可見，監(jiān)控功能對于PaaS平臺自身以及各個層次的用戶都是必要的。

2.2 PaaS平臺數(shù)據(jù)監(jiān)控所面臨的問題

實際的PaaS系統(tǒng)監(jiān)控中卻面臨著各種各樣的困難。首先，PaaS系統(tǒng)中組件的多樣性以及組件之間異構的特性決定不能使用統(tǒng)一的數(shù)據(jù)采集及存儲方案，必須為各個組件定制單一的數(shù)據(jù)監(jiān)控方案[5]。其次，相比傳統(tǒng)的軟件監(jiān)控，PaaS系統(tǒng)中各組件分布式的特征以及組件實例個數(shù)和運行位置的動態(tài)性，為監(jiān)控提出了新的挑戰(zhàn)[6,7]。最后，系統(tǒng)獲取的原始數(shù)據(jù)過于龐雜，可讀性差，對于各層次的用戶無法起到監(jiān)控和管理系統(tǒng)和應用的作用，從而需要對大量復雜的原始數(shù)據(jù)進行有效的加工組織。

為了應對這些在PaaS系統(tǒng)監(jiān)控中面臨的問題，本文提出了一種全新的解決方案。通過分布式的代理，以及各組件內置的異構化的數(shù)據(jù)采集模塊，采集原始數(shù)據(jù)，這樣就有效的解決了異構數(shù)據(jù)的收集問題。通過綜合代理采集的數(shù)據(jù)和組件數(shù)據(jù)采集模塊提交的數(shù)據(jù)，系統(tǒng)能夠及時發(fā)現(xiàn)新增組件及丟失的組件。此外，通過對數(shù)據(jù)的進一步關聯(lián)、綜合，就能夠形成系統(tǒng)總體的拓撲結構，同時為不同層級的用戶展示權限范圍內的監(jiān)控視圖。

3 PaaS系統(tǒng)

3.1 PaaS系統(tǒng)結構

為了更好的理解PaaS監(jiān)控系統(tǒng)所要完成的工作，首先需要介紹一下PaaS的總體架構。不同的IT公司和組織都提供了自己的PaaS平臺，而且各個PaaS平臺的系統(tǒng)架構、實現(xiàn)技術等也各不相同，為了方便同時又不失一般性，我們將PaaS平臺從邏輯上抽象為以下幾個組件：Router（路由器），Controller（控制器），User Auth（用戶鑒權），App Container（應用運行容器），Services（服務組件），Message Bus（消息總線）以及Monitor（監(jiān)控器）等[3]。如圖1所示，各組件的功能如下。

圖1 PaaS系統(tǒng)的組成

Router:路由組件，負責將外部的請求轉發(fā)到PaaS內部的指定地址。如將應用使用者的請求轉發(fā)到應用實例所在的應用運行容器，將PaaS用戶的請求轉發(fā)到控制器或用戶鑒權組件。此外該組件還負責應用的不同實例之間的負載均衡。

Controller：控制器是PaaS平臺的控制中心，負責處理應用開發(fā)者管理應用和服務的請求，同時對系統(tǒng)出現(xiàn)的各種異常情況進行處理。

User Auth：該組件負責PaaS平臺用戶體系的管理，用戶接入的鑒權等。

App Container：該組件是應用運行的環(huán)境，包括操作系統(tǒng)、必須的語言及框架環(huán)境等。

Service：該組件為PaaS平臺提供商為應用開發(fā)者提供的為支持應用正常運行的服務，如定時任務服務、數(shù)據(jù)庫服務、郵件服務等。該組件最能體現(xiàn)不同PaaS提供商的特性。

Message Bus：該組件是系統(tǒng)運行的總線，各組件之間的信息交流都是通過該組件進行的。

Monitor：負責采集各個虛擬機、組件、應用和服務的運行數(shù)據(jù)，對出現(xiàn)的異常發(fā)出報告，同時為系統(tǒng)管理員、PaaS使用者等提供查看系統(tǒng)及應用運行狀態(tài)的Web界面。

3.2 監(jiān)控數(shù)據(jù)

采用自頂向下的方法，可以通過劃分PaaS平臺各種用戶的類型，然后根據(jù)不同用戶的不同需求，決定需要監(jiān)控哪些內容。PaaS平臺的用戶一般可分為以下3個角色。

管理員：PaaS平臺的提供者。該角色關心整個PaaS平臺及基礎設施的運行情況，包括虛擬機的配置、運行狀態(tài)以及PaaS系統(tǒng)各個組件的拓撲結構和部署運行情況。

服務提供商：PaaS平臺中所支持的各種服務的提供者。該角色關心自身服務的運行情況及開發(fā)者對服務的購買使用情況等。

開發(fā)者：PaaS平臺的使用者，也是應用的開發(fā)者。該角色關心自己應用的運行情況、應用流量、訪問量以及所購買的資源服務的使用情況等。

綜合以上3種用戶的需求，可以將需要獲取的監(jiān)控信息分為以下幾個類型。

基礎設施信息：主要是指虛擬機的部署及配置信息，包括虛擬機的CPU、內存、磁盤及網絡配置情況，還包括一些動態(tài)信息，比如進程的所占用的系統(tǒng)資源信息等。通過這些信息可以了解該虛擬機的負載情況，虛擬機上各個進程的負載情況等。

PaaS組件信息：主要是指PaaS平臺中各個組件所運行的位置，性能數(shù)據(jù)，組件內部一些運行數(shù)據(jù)，如APP Container中的應用信息，Router中各個應用實例的流量及訪問量信息、路由表信息等。通過這些信息可以構建PaaS平臺的拓撲結構。

服務信息：包括兩方面的內容，一是PaaS平臺中所能提供的各種服務信息，包括服務的類型、服務的容量、服務的使用情況；二是應用開發(fā)者所申請的服務實例的信息，包括服務實例的容量參數(shù)，使用量，流量信息等。這些信息可以用于服務的計費，應用開發(fā)者對購買的服務的管理等。

應用信息：包括應用的語言架構，應用的實例個數(shù)及運行情況，應用的訪問量等信息。PaaS平臺的使用者可以實時了解系統(tǒng)中應用的個數(shù)及運行狀態(tài)，應用的開發(fā)者可以了解自己托管應用的運行狀態(tài)等信息。

用戶信息：是PaaS平臺的一個重要內容，用戶信息涉及到用戶鑒權、計費管理、資源配額管理等。

4 監(jiān)控系統(tǒng)的設計實現(xiàn)

4.1 總體設計

PaaS平臺監(jiān)控系統(tǒng)總體如圖2所示。

系統(tǒng)主要分為3個部分，數(shù)據(jù)采集、數(shù)據(jù)處理以及數(shù)據(jù)的展示。通過這樣的層次劃分，可以將本系統(tǒng)的3大功能區(qū)分開，減少相互之間的耦合度，便于之后各模塊獨立的更改和升級。

4.2 原始數(shù)據(jù)的采集

之前已經介紹了需要采集的監(jiān)控數(shù)據(jù)的類別，按照這些監(jiān)控數(shù)據(jù)的采集來源，可以將監(jiān)控數(shù)據(jù)分為以下3個數(shù)據(jù)源。

圖2 PaaS系統(tǒng)數(shù)據(jù)監(jiān)控平臺的總體設計圖

4.2.1 PaaS平臺數(shù)據(jù)庫

PaaS系統(tǒng)中的一些關鍵數(shù)據(jù)都是持久化到數(shù)據(jù)庫中，這部分數(shù)據(jù)主要包括應用開發(fā)者信息，應用和服務的部分配置信息，如應用和服務的綁定信息、應用和域名的綁定信息等。通過只讀的方式訪問這些數(shù)據(jù)表，可以快速直觀的得到這些原始數(shù)據(jù)。

4.2.2 PaaS組件的Web接口

每個PaaS組件都會實現(xiàn)一個名為VARZ的Web接口，所有組件都會將自己的配置信息、運行信息以及自身所執(zhí)行功能的數(shù)據(jù)放到該接口中，并定時更新，這樣外部就可以在獲取該VARZ接口地址后，方便的采集到該組件的信息。

4.2.3 數(shù)據(jù)采集代理

數(shù)據(jù)采集代理部署在每一個虛擬機中，采集每個虛擬機的配置信息、性能數(shù)據(jù)（CPU數(shù)據(jù)、網絡數(shù)據(jù)、內存數(shù)據(jù)、磁盤負載等），以及虛擬機上的進程信息。

采集到的監(jiān)控數(shù)據(jù)需要通過某種方式統(tǒng)一的提交到數(shù)據(jù)分析處理模塊。由于監(jiān)控數(shù)據(jù)的采集使用了3種完全異構的方式，為了提供統(tǒng)一的對外接口，采用了基于消息訂閱Message組件，數(shù)據(jù)采集模塊的每個部分都按照預定義的消息主題發(fā)布消息，數(shù)據(jù)分析處理模塊可以通過訂閱相應的消息主題獲得采集到的數(shù)據(jù)。

4.3 原始數(shù)據(jù)處理

數(shù)據(jù)分析處理模塊的主要功能是將采集到的碎片化的監(jiān)控數(shù)據(jù)，綜合整理，形成結構化的數(shù)據(jù)，有些需要持久化的數(shù)據(jù)會存儲到數(shù)據(jù)庫中，而其他數(shù)據(jù)則只需要保存在內存中不斷更新即可。原始數(shù)據(jù)采集模塊采集的數(shù)據(jù)過于龐雜和繁瑣，不能直接提供給不同類型的用戶，需要將各方面采集的數(shù)據(jù)進行有效的整理綜合，形成結構化的、可讀的數(shù)據(jù)。

原始數(shù)據(jù)的處理主要包含以下幾個功能。

4.3.1 構建PaaS系統(tǒng)的拓撲結構

通過分析服務器節(jié)點信息和組件的一些信息，可以定位出PaaS各個組件與服務器節(jié)點的對應關系，從而構建出PaaS系統(tǒng)的拓撲結構圖，直觀的展示系統(tǒng)的部署情況。

4.3.2 應用實例的分布狀況

在應用程序部署的過程中，應用程序實例所運行的實際位置（具體的哪個App Container及哪個服務器）由PaaS系統(tǒng)根據(jù)一定的策略做出選擇，所以外界無法直觀的感知。通過對應用信息的分析結合PaaS組件的信息，可以定位每個應用實例實時的位置。

4.3.3 統(tǒng)計應用的流量、訪問量及負載信息

通過對Router組件路由信息的統(tǒng)計整理，可以計算出每一個應用實例的訪問量、數(shù)據(jù)流量及其運行的性能數(shù)據(jù)，通過這些數(shù)據(jù)可以實時的對應用實例的個數(shù)進行增減，以確保應用運行在最佳狀態(tài)同時避免資源的浪費。

4.3.4 發(fā)現(xiàn)系統(tǒng)運行瓶頸

綜合服務器節(jié)點及PaaS各組件的負載情況，可以實時了解每個服務器節(jié)點及PaaS組件的運行狀態(tài)，發(fā)現(xiàn)高負荷的服務器節(jié)點和組件，及時對系統(tǒng)的相應部分進行擴容。同時發(fā)現(xiàn)故障節(jié)點，將其移除系統(tǒng)。

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

將一些有價值的歷史數(shù)據(jù)存儲到數(shù)據(jù)庫中進行持久化，其他數(shù)據(jù)則存放在內存中，并向監(jiān)控數(shù)據(jù)展示模塊提供數(shù)據(jù)接口。

4.4 監(jiān)控數(shù)據(jù)的展示

然后根據(jù)不同類型用戶的需求形成不同的監(jiān)控視圖。按照查看監(jiān)控數(shù)據(jù)的用戶的類別，監(jiān)控數(shù)據(jù)的展示分為以下3類型。

4.4.1 系統(tǒng)管理員視圖

系統(tǒng)管理員是PaaS系統(tǒng)的提供者。該角色關心整個PaaS系統(tǒng)及基礎設施的運行情況，包括虛擬機的配置、運行狀態(tài)以及PaaS系統(tǒng)各個組件的拓撲結構和部署運行情況。系統(tǒng)管理員可以看到系統(tǒng)中幾乎全部監(jiān)控數(shù)據(jù)，內容比較多，主要分為兩大類，一是PaaS系統(tǒng)的全局信息，二是PaaS系統(tǒng)運行的詳細信息。

4.4.2 服務提供商視圖

服務提供商PaaS系統(tǒng)中所支持的各種服務的提供者。該角色關心自身服務的運行情況及開發(fā)者對服務的購買使用情況等。針對服務提供商，信息的展示主要是服務實例的信息，每個服務實例的詳細情況包括服務的實例的容量、使用量、及接口流量等數(shù)據(jù)。目前PaaS系統(tǒng)中提供的服務主要有兩大類：數(shù)據(jù)庫服務和短彩服務，針對不同的服務類型，展示的內容會有所差異。

4.4.3 應用開發(fā)者視圖

應用開發(fā)者是PaaS系統(tǒng)的使用者，也是應用的開發(fā)者。該角色關心自己應用的運行情況、應用流量、訪問量以及所購買的資源服務的使用情況等。

應用開發(fā)者視圖主要展示用戶創(chuàng)建的應用信息，申請的服務實例信息等。應用信息詳情則包含應用實例的個數(shù)、應用的訪問量、應用的負載信息等；服務實例信息包含服務資源的使用量，及其他與應用類型相關的信息。

5 結論及未來工作

PaaS系統(tǒng)數(shù)據(jù)監(jiān)控平臺能夠有效的解決PaaS系統(tǒng)中大量異構化的數(shù)據(jù)的分析及展示問題，此外系統(tǒng)的設計考慮到不同PaaS平臺的差異性，所有功能的設計都針對抽象的PaaS平臺，因而具有較高的移植性。

目前關于這部分的工作僅停留在數(shù)據(jù)的采集、整理及展示方面，未來的工作將著重關注數(shù)據(jù)的監(jiān)控告警方面，從而實現(xiàn)通過數(shù)據(jù)采集監(jiān)控工作，自動化的實現(xiàn)系統(tǒng)異常的監(jiān)控和告警功能。

[1] 沈青，董波，肖德寶. 基于服務器集群的云監(jiān)控系統(tǒng)設計與實現(xiàn)[J]. 計算機科學與工程, 2012,34（10）: 73-77.

[2] 趙京華. 應用服務器集群管理系統(tǒng)的設計與實現(xiàn)[D]. 北京：北京郵電大學. 2010.

[3] Shao J, Wang Q X. A model-driven monitoring approach for internetware on Platform-as-a-Service(PaaS)[J]. Internetware '12 Proceedings of the Fourth Asia-Pacific Symposium on Internetware[C].2012.

[4] Lawton, G. Developing software online with platform-as-a-service technology[J]. Computer, 2008,41(6):13-15.

[5] Shao, Wei H,Wang Q, Mei H. A runtime model based monitoring approach for cloud[A]. 2010 IEEE 3rd International Conference on Cloud Computing[C], 2010:313-320.

[6] 李維東. 基于Linux平臺的局域網與監(jiān)控系統(tǒng)的分析與實現(xiàn)[D].武漢：華中科技大學. 2011.

[7] 譚鵬，黃紅偉. Web集群遠程監(jiān)控策略[J].計算機系統(tǒng)應用,2010,19(3):83-86.

[8] Katsaros G, Kbert R, Gallizo G. Building a service-oriented monitoring framework with REST and Nagios[A]. 2011 IEEE International Conference on Services Computing SCC[C]. 2011:426–431.