一种PaaS系统的数据监控平台的设计方案*

樊伟钰 ，朱晓民

（1 北京邮电大学网络与交换技术国家重点实验室，北京 100876；2 东信北邮信息技术有限公司，北京 100191）

1 引言

伴随着互联网技术的快速发展，尤其是移动互联网快速兴起和发展，各种各样的PaaS（Platform as a Service，平台即服务）平台随之出现，业界比较著名的有Sina App Engine （SAE，新浪公司Web开发PaaS平台）、Google App Engine（GAE，谷歌Web应用程序开发和托管平台）、Cloud Foundry（CF，VMware公司推出的开源PaaS平台）等，除此之外还有众多的企业内部的私有PaaS平台。

PaaS系统的出现及发展，在为Web应用开发提供巨大便利的同时，其系统本身、以及其中部署的应用和服务的监控任务也开始面临巨大的挑战，如何处理及展示大量非结构的数据成为一项重要的内容[1,2]。

2 PaaS系统数据监控现状

2.1 PaaS平台数据监控的必要性

作为云计算的3种服务模型中的一种，PaaS具有云计算所有的特征，其中最重要的两点，一是极大的节约计算机资源，二是使用户更多的关注自己的业务实现，而不必过多考虑硬件资源的管理。为了满足以上的需求，PaaS平台一般具有以下几个特征：自主 的（autonomous）， 协 作 的（cooperative）， 自 适应的（situational），可进化的（evolvable），应急的（emergent），可信赖的（trustworthy）[3～5]。为了满足以上几个特征，PaaS平台需要具有自我管理的能力，而自我的监控则是其中一项最基本的能力。

对于PaaS服务的提供者，需要实时了解PaaS平台的运行状态，每个系统组件的负荷，系统容量以及负载，并从监控数据分析系统的性能瓶颈，从而不断的优化系统性能。对于PaaS平台本身，为了能够满足自主、自适应等特性，需要实时获取系统各组件的运行状态、负载，从而实现故障组件的自动重启，高负载组件自动扩容以及多余组件的自动关闭，实现资源的自动缩放。而对于PaaS服务的使用者，即应用开发者，监控功能也是一项必须要提供的功能。开发者需要随时了解所托管的应用运行状态，资源占用情况，以及是否需要增加或减少所购买的资源等。由此可见，监控功能对于PaaS平台自身以及各个层次的用户都是必要的。

2.2 PaaS平台数据监控所面临的问题

实际的PaaS系统监控中却面临着各种各样的困难。首先，PaaS系统中组件的多样性以及组件之间异构的特性决定不能使用统一的数据采集及存储方案，必须为各个组件定制单一的数据监控方案[5]。其次，相比传统的软件监控，PaaS系统中各组件分布式的特征以及组件实例个数和运行位置的动态性，为监控提出了新的挑战[6,7]。最后，系统获取的原始数据过于庞杂，可读性差，对于各层次的用户无法起到监控和管理系统和应用的作用，从而需要对大量复杂的原始数据进行有效的加工组织。

为了应对这些在PaaS系统监控中面临的问题，本文提出了一种全新的解决方案。通过分布式的代理，以及各组件内置的异构化的数据采集模块，采集原始数据，这样就有效的解决了异构数据的收集问题。通过综合代理采集的数据和组件数据采集模块提交的数据，系统能够及时发现新增组件及丢失的组件。此外，通过对数据的进一步关联、综合，就能够形成系统总体的拓扑结构，同时为不同层级的用户展示权限范围内的监控视图。

3 PaaS系统

3.1 PaaS系统结构

为了更好的理解PaaS监控系统所要完成的工作，首先需要介绍一下PaaS的总体架构。不同的IT公司和组织都提供了自己的PaaS平台，而且各个PaaS平台的系统架构、实现技术等也各不相同，为了方便同时又不失一般性，我们将PaaS平台从逻辑上抽象为以下几个组件：Router（路由器），Controller（控制器），User Auth（用户鉴权），App Container（应用运行容器），Services（服务组件），Message Bus（消息总线）以及Monitor（监控器）等[3]。如图1所示，各组件的功能如下。

图1 PaaS系统的组成

Router:路由组件，负责将外部的请求转发到PaaS内部的指定地址。如将应用使用者的请求转发到应用实例所在的应用运行容器，将PaaS用户的请求转发到控制器或用户鉴权组件。此外该组件还负责应用的不同实例之间的负载均衡。

Controller：控制器是PaaS平台的控制中心，负责处理应用开发者管理应用和服务的请求，同时对系统出现的各种异常情况进行处理。

User Auth：该组件负责PaaS平台用户体系的管理，用户接入的鉴权等。

App Container：该组件是应用运行的环境，包括操作系统、必须的语言及框架环境等。

Service：该组件为PaaS平台提供商为应用开发者提供的为支持应用正常运行的服务，如定时任务服务、数据库服务、邮件服务等。该组件最能体现不同PaaS提供商的特性。

Message Bus：该组件是系统运行的总线，各组件之间的信息交流都是通过该组件进行的。

Monitor：负责采集各个虚拟机、组件、应用和服务的运行数据，对出现的异常发出报告，同时为系统管理员、PaaS使用者等提供查看系统及应用运行状态的Web界面。

3.2 监控数据

采用自顶向下的方法，可以通过划分PaaS平台各种用户的类型，然后根据不同用户的不同需求，决定需要监控哪些内容。PaaS平台的用户一般可分为以下3个角色。

管理员：PaaS平台的提供者。该角色关心整个PaaS平台及基础设施的运行情况，包括虚拟机的配置、运行状态以及PaaS系统各个组件的拓扑结构和部署运行情况。

服务提供商：PaaS平台中所支持的各种服务的提供者。该角色关心自身服务的运行情况及开发者对服务的购买使用情况等。

开发者：PaaS平台的使用者，也是应用的开发者。该角色关心自己应用的运行情况、应用流量、访问量以及所购买的资源服务的使用情况等。

综合以上3种用户的需求，可以将需要获取的监控信息分为以下几个类型。

基础设施信息：主要是指虚拟机的部署及配置信息，包括虚拟机的CPU、内存、磁盘及网络配置情况，还包括一些动态信息，比如进程的所占用的系统资源信息等。通过这些信息可以了解该虚拟机的负载情况，虚拟机上各个进程的负载情况等。

PaaS组件信息：主要是指PaaS平台中各个组件所运行的位置，性能数据，组件内部一些运行数据，如APP Container中的应用信息，Router中各个应用实例的流量及访问量信息、路由表信息等。通过这些信息可以构建PaaS平台的拓扑结构。

服务信息：包括两方面的内容，一是PaaS平台中所能提供的各种服务信息，包括服务的类型、服务的容量、服务的使用情况；二是应用开发者所申请的服务实例的信息，包括服务实例的容量参数，使用量，流量信息等。这些信息可以用于服务的计费，应用开发者对购买的服务的管理等。

应用信息：包括应用的语言架构，应用的实例个数及运行情况，应用的访问量等信息。PaaS平台的使用者可以实时了解系统中应用的个数及运行状态，应用的开发者可以了解自己托管应用的运行状态等信息。

用户信息：是PaaS平台的一个重要内容，用户信息涉及到用户鉴权、计费管理、资源配额管理等。

4 监控系统的设计实现

4.1 总体设计

PaaS平台监控系统总体如图2所示。

系统主要分为3个部分，数据采集、数据处理以及数据的展示。通过这样的层次划分，可以将本系统的3大功能区分开，减少相互之间的耦合度，便于之后各模块独立的更改和升级。

4.2 原始数据的采集

之前已经介绍了需要采集的监控数据的类别，按照这些监控数据的采集来源，可以将监控数据分为以下3个数据源。

图2 PaaS系统数据监控平台的总体设计图

4.2.1 PaaS平台数据库

PaaS系统中的一些关键数据都是持久化到数据库中，这部分数据主要包括应用开发者信息，应用和服务的部分配置信息，如应用和服务的绑定信息、应用和域名的绑定信息等。通过只读的方式访问这些数据表，可以快速直观的得到这些原始数据。

4.2.2 PaaS组件的Web接口

每个PaaS组件都会实现一个名为VARZ的Web接口，所有组件都会将自己的配置信息、运行信息以及自身所执行功能的数据放到该接口中，并定时更新，这样外部就可以在获取该VARZ接口地址后，方便的采集到该组件的信息。

4.2.3 数据采集代理

数据采集代理部署在每一个虚拟机中，采集每个虚拟机的配置信息、性能数据（CPU数据、网络数据、内存数据、磁盘负载等），以及虚拟机上的进程信息。

采集到的监控数据需要通过某种方式统一的提交到数据分析处理模块。由于监控数据的采集使用了3种完全异构的方式，为了提供统一的对外接口，采用了基于消息订阅Message组件，数据采集模块的每个部分都按照预定义的消息主题发布消息，数据分析处理模块可以通过订阅相应的消息主题获得采集到的数据。

4.3 原始数据处理

数据分析处理模块的主要功能是将采集到的碎片化的监控数据，综合整理，形成结构化的数据，有些需要持久化的数据会存储到数据库中，而其他数据则只需要保存在内存中不断更新即可。原始数据采集模块采集的数据过于庞杂和繁琐，不能直接提供给不同类型的用户，需要将各方面采集的数据进行有效的整理综合，形成结构化的、可读的数据。

原始数据的处理主要包含以下几个功能。

4.3.1 构建PaaS系统的拓扑结构

通过分析服务器节点信息和组件的一些信息，可以定位出PaaS各个组件与服务器节点的对应关系，从而构建出PaaS系统的拓扑结构图，直观的展示系统的部署情况。

4.3.2 应用实例的分布状况

在应用程序部署的过程中，应用程序实例所运行的实际位置（具体的哪个App Container及哪个服务器）由PaaS系统根据一定的策略做出选择，所以外界无法直观的感知。通过对应用信息的分析结合PaaS组件的信息，可以定位每个应用实例实时的位置。

4.3.3 统计应用的流量、访问量及负载信息

通过对Router组件路由信息的统计整理，可以计算出每一个应用实例的访问量、数据流量及其运行的性能数据，通过这些数据可以实时的对应用实例的个数进行增减，以确保应用运行在最佳状态同时避免资源的浪费。

4.3.4 发现系统运行瓶颈

综合服务器节点及PaaS各组件的负载情况，可以实时了解每个服务器节点及PaaS组件的运行状态，发现高负荷的服务器节点和组件，及时对系统的相应部分进行扩容。同时发现故障节点，将其移除系统。

4.3.5 数据存储

将一些有价值的历史数据存储到数据库中进行持久化，其他数据则存放在内存中，并向监控数据展示模块提供数据接口。

4.4 监控数据的展示

然后根据不同类型用户的需求形成不同的监控视图。按照查看监控数据的用户的类别，监控数据的展示分为以下3类型。

4.4.1 系统管理员视图

系统管理员是PaaS系统的提供者。该角色关心整个PaaS系统及基础设施的运行情况，包括虚拟机的配置、运行状态以及PaaS系统各个组件的拓扑结构和部署运行情况。系统管理员可以看到系统中几乎全部监控数据，内容比较多，主要分为两大类，一是PaaS系统的全局信息，二是PaaS系统运行的详细信息。

4.4.2 服务提供商视图

服务提供商PaaS系统中所支持的各种服务的提供者。该角色关心自身服务的运行情况及开发者对服务的购买使用情况等。针对服务提供商，信息的展示主要是服务实例的信息，每个服务实例的详细情况包括服务的实例的容量、使用量、及接口流量等数据。目前PaaS系统中提供的服务主要有两大类：数据库服务和短彩服务，针对不同的服务类型，展示的内容会有所差异。

4.4.3 应用开发者视图

应用开发者是PaaS系统的使用者，也是应用的开发者。该角色关心自己应用的运行情况、应用流量、访问量以及所购买的资源服务的使用情况等。

应用开发者视图主要展示用户创建的应用信息，申请的服务实例信息等。应用信息详情则包含应用实例的个数、应用的访问量、应用的负载信息等；服务实例信息包含服务资源的使用量，及其他与应用类型相关的信息。

5 结论及未来工作

PaaS系统数据监控平台能够有效的解决PaaS系统中大量异构化的数据的分析及展示问题，此外系统的设计考虑到不同PaaS平台的差异性，所有功能的设计都针对抽象的PaaS平台，因而具有较高的移植性。

目前关于这部分的工作仅停留在数据的采集、整理及展示方面，未来的工作将着重关注数据的监控告警方面，从而实现通过数据采集监控工作，自动化的实现系统异常的监控和告警功能。

[1] 沈青，董波，肖德宝. 基于服务器集群的云监控系统设计与实现[J]. 计算机科学与工程, 2012,34（10）: 73-77.

[2] 赵京华. 应用服务器集群管理系统的设计与实现[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平台的局域网与监控系统的分析与实现[D].武汉：华中科技大学. 2011.

[7] 谭鹏，黄红伟. Web集群远程监控策略[J].计算机系统应用,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.