多场景云资源池监控技术和方案研究

刘 寒，张 奎，赵以爽，康 凯（.中讯邮电咨询设计院有限公司郑州分公司，河南郑州 450007；.中国联合网络通信集团有限公司，北京 00033）

0 前言

随着云计算技术不断演进，市场蓬勃发展，针对不同业务场景，各公司推出差异化云计算产品，如大数据云、行业云、通用IT 云和通信云等。各个云资源池安全稳定运行是业务发展的基本条件，在出现故障时能及时处理，在性能达到瓶颈时能及时扩容，同时云资源池资源利用率是重要的运营衡量标准，这些都需要云池监控数据的支撑和分析，监控方式的差异、数据采集的效果以及对监控数据的展现都会影响故障处理和数据分析的效率和准确性。因此，针对多业务场景云资源池的监控数据采集方式和统一展现的研究是非常重要且有意义的。

1 不同方式采集云资源数据的原理与差异

随着云计算技术的演进，云计算涉及的功能组件也越来越多，这些功能组件可能是不同团队使用不同编程语言开发实现的，同时云计算的分布式架构涉及到的物理计算、网络、存储设备可能有成千上万台，横跨多个不同数据中心。

随着业务的发展，云资源池规模还在不断扩大，资源池上承载的业务类型和容量也在不断地增加。业务的频繁调整使资源池也需要频繁调整。这就带一系列的问题：如何判断故障产生原因？如何界定故障所影响的范围？如何分析性能使用情况？如何确定容量使用情况从而进行后期建设规划？

解决上述问题需要监控数据进行支撑，目前主流监控方式分为带内监控和带外监控。

1.1 云资源池带内监控原理

监控数据与业务数据在同一物理通道上传输，即为带内监控。带内监控是目前的主流监控方式，分布式探针监控系统则是带内监控中常见的监控系统，其系统的主要功能模块有展示模块、采集模块、发送模块、收集模块和存储模块。

采集模块将收集到的监控信息通过发送模块传递至收集模块，收集模块进行存储，最终由前端展示模块进行展示和查询，流程如图1所示。

图1 分布式探针监控流程图

除上述流程外，对于带内监控还有以下几点基本技术要求。

a）带内探针系统的性能消耗：探针组件的影响应当做到足够小，本身探针在采集监控数据时会消耗主机性能，所以需要对数据采集的方式和频率周期进行配置优化，以保证业务的正常运行。在一些高度敏感和易受环境波动影响的云计算组件或业务组件中，即使轻微损耗波动也会对系统造成可见影响，会迫使维护团队关闭或删除探针软件。

b）监控的侵入性：监控组件作为云计算组件的一部分，应尽可能少入侵或不入侵其他组件或承载业务系统，同时作为业务使用方不需要知道或发现监控探针的存在。

c）可扩展性：一个完备的监控系统必须支持分布式部署，具有良好的可扩展性。

d）数据分析：数据分析系统必须尽快分析采集到的监控数据，并且分析的维度也要尽可能的多。监控系统需要尽快反馈信息，这样就可以对生产环境下的故障或异常现象及时响应。

1.2 云资源池带外监控原理

监控系统通过单独的物理链路对已使用管理接口联网的物理设备采集监控数据，这种监控方式被称为带外监控，带外监控除了能采集到硬件设备的配置信息、部分性能信息和健康状态外，在带内网络故障或主机操作系统故障，导致SSH、VNC等通过带内方式连接无法使用时，可以通过带外通路远程登录带外管理模块，查看、控制设备状态，处理故障等。

目前业界都是通过适配的接口协议对硬件设备进行监控和管理，主流的协议有IPMI 协议（Intellgent Platform Management Interface）、Redfish 协议、MCTP 协议（Management Component Transport Protocol）、带外管理标准协议（Desktop and mobile Architecture for Sys⁃tem Hardware）等。

监控系统通过带外管理接口不仅可以获得设备资产信息，还可以通过SNMP 接口监听方式对设备硬件告警进行监控。相较带内监控方式，带外管理接口获取的硬件告警信息更加详细，故障点更为精确。

1.3 带内、带外监控的差异

如表1 所示，带内、带外监控定位不同，带内监控主要获取操作系统层级以上的监控数据，而带外监控主要获取资产信息和硬件监控信息，因此带内、带外监控并不是二选一，而是1+1 互补的关系。云资源池同时具备带内、带外监控的情况下，采集到的监控数据会更加全面，故障定位会更加迅速，数据分析也更加全面。

表1 带内带外监控差异

2 不同云池场景采集方案

根据所承载业务不同，云资源分为多种产品，如承载IT 系统的IT 云、承载大数据业务的大数据云、承载网络能力虚拟化的通信云等，不同类型的云也需要不同的云资源监控方案，以下列举2 类典型场景的监控方式。

2.1 IT/大数据云资源监控

目前行业内IT 云资源池常用的监控手段是带内监控为主，带外监控为辅的监控方案。现在主流的带内监控产品有很多，如zabbix、Prometheus、Span等。通过带内监控对主机操作系统、网络设备性能等进行监控，可以采集主机资源实时利用情况、操作系统健康状态等，同时通过带外管理接口采集硬件的资产信息、健康状态以及设备的功耗、进风口温度等信息，同时也可以通过端口监听的方式获取设备的故障告警信息。

以Prometheus 监控为例，如图2 所示，Prometheus从主机上部署的2种exporter 获取监控数据，带内监控通过部署在主机操作系统上的Node-exporter 获取操作系统数据，带外监控则通过IPMI-exporter 获取带外管理接口中的数据，另外由于Prometheus 并没有传递告警信息的能力，带外告警是IPMI接口发出硬件告警信息并推送至kafka进行存储转发，带内告警则是由汇聚节点通过带内监控数据计算出告警并推送至kafka进行存储转发。

图2 IT云监控架构示意图

2.2 通信云资源监控

通信云即为承载运营商网络能力虚拟化（NFV）能力的云资源，由于运营商业务的特殊性，通信业务对云资源的可靠性、可用性和安全性有着极高的要求。由于通信业务的极致可靠性要求，一般第三方监控软件探针的安全性和性能在未长时间全方位验证测试的情况下，是不允许部署在业务运行的虚拟机和宿主机上的，因此IT云监控方案不易套用在通信云上。

根据业务特性，通信云监控分为小闭环和大闭环。如图3所示，单个资源池建议采用小闭环，资源池拥有二级平台对自身进行管理、监控、故障维护处理等能力的逻辑闭环，监控范围涵盖带内带外所有网络；多DC 多资源池建议形成大闭环，由一级平台向小闭环的二级平台采集资源池的监控、告警等信息，一级平台建设数据采集层，制定统一资源模型以消除不同厂家间北向上报的数据差异，各资源池间打通链路形成分布式的运维能力，在上层构建智能化的数据分析能力平台，增强运维能力，提高故障处理效率。

图3 通信云一级监控架构示意图

3 多场景多方案采集统一展示

为了消除不同云资源之间的差异，实现一点看全、全局监控，运营商需要在用户侧建设一个统一的云资源监控门户对不同类型云资源进行汇总和分类展示，提高可视化能力，提供多种场景的运维管理窗口，同时对不同角色的用户设置不同的展示窗口和浏览范围。

不同云资源监控数据格式不同，无法合理进行统一展示，这种情况就需要制定各云资源上报数据格式的统一规范，对各类数据进行规范化要求，对通用和核心关键指标进行集中展示，而对各类型业务云资源差异化的指标则可以分不同场景窗口进行分类展示。

4 结束语

本文通过分析云资源监控的特点，总结了带内和带外监控的各自特点，深入研究云资源池的监控方式，并给出2类典型业务场景的监控方案，为不同业务云资源池监控提供重要参考，从而有效提高云资源池运维能力。