面向有限带宽环境下的分布式系统监控技术

蒋鸣远 粟勇 梁璟

中国电子科技集团公司第二十九研究所 四川 成都 610036

引言

分布式系统如今广泛存在于如金融、制造、医疗、交通等不同行业，这些系统一般都有多个独立的子系统集成所得，子系统使用的开发技术和使用方式往往存在很大的差异，甚至于它们需要运行在异构的网络节点之上[1]。系统监控是分布式系统配置和管理的基础设施，管理员需要掌握系统中的可用资源，感知系统部署情况。良好的系统监控技术是对分布式系统有效管理的前提条件[2]。

本文针对某特定网络有限带宽环境，实现了一个对所属分布式系统的系统监控原型软件，补足了用户在使用过程中无法掌握系统整体状态的能力欠缺。本文先分析了目标环境，再结合监控需求设计出系统监控的架构，然后阐述了本文分布式系统监控的几个关键技术，最后按照前文设计思路实现了面向有限带宽环境分布式系统监控技术的原型软件，并给出了模拟环境下监控的界面截图。

1 目标环境

本文面向某专用网络环境，网络节点之间的传输有效带宽限制为2Mbps，而在实际使用中，监控数据传输所能占用的网络带宽只会更少；并且节点之间的数据传输因底层限制不能随意使用端口和传输协议，各节点监控数据的汇集上报只能通过特定的数据传输服务完成；同时，监控需求不仅仅是单个席位的硬件使用状态，还包括对网络节点间的通信链路、系统内的数据存储服务等进行监控，因此要求系统监控具有良好的可扩展性。

业界常用的开源监控软件有Nagios、Ganglia：Nagios[3]是一种企业级的开源监控系统，具有监控服务的运行状态和网络信息等的能力，其功能侧重于监控服务的可用性，但是Nagios对监控需求的可扩展性和使用的便捷性不能满足本项目的需求。

Ganglia是一套跨平台的、可扩展的分布式开源监控系统，它基于分层设计，具有可视化界面显示，适合于对集群系统的自动化监控。但是Ganglia没有报警机制，出现问题不能够及时报警。

所以上述两款开源软件都不适用于目标环境，本项目在此目标环境中提出了一种分布式系统监控技术：针对特定有限带宽环境，在每个网络节点内部署一个相同的节点监控中心，采用微服务架构采集监控数据，实现了对所属系统中的节点状态、通信链路、数据存储进行有效监控；在网络节点之间监控中心通过专用的数据传输服务对汇总的监控数据进行策略性上报，实现了满足有限带宽条件下的跨广域网的分布式系统监控。

2 方案设计

本项目从广域网整体出发，将接入系统的每个单位看作一个网络节点，在节点内部部署一个节点监控中心负责汇总采集的监控数据，并负责跨广域专用网络的监视数据及控制指令的传输。系统内各个节点监控中心在专用网络环境下的连接关系如图1所示：

图1 专网中节点监控中心连接关系图

每个节点监控中心都留有接收下级节点上报监控数据的接口，同时还有自己的监控数据库，用于存储收集的监控数据并供给用户交互界面展示。每个节点监控中心在汇集了本节点及下级节点的监控数据后，精简监控数据并调用特定的专网数据传输服务向上级节点的监控中心进行点对点的数据传输，监控数据就能汇集于上级节点的监控中心；同理上级节点监控中心在收到用户监控指令后也通过专网数据传输服务向下级监控中心传达指令，至此也就实现了上级节点对下级节点的监视与控制。

微服务架构在复杂度控制、服务并发性、系统容错性以及扩展能力方面都具有一定的优势[4]。单个网络节点内部的系统监控采用微服务架构，部署的节点监控中心包含代理管理服务、数据接收服务、日志服务、Web实时通信服务、数据上报服务，分别负责管理与各席位上的监控代理的服务双向调用连接及指令转达、将收到的监控数据存入本地监控数据库、维护管理系统日志、在Web上主动向用户推送数据、将监控数据选择性跨专网上报至上级；各席位上的监控代理提供接收监控指令的SOA接口，负责执行下达的监控指令、向监控中心进行上线注册、将采集席位状态并上传至监控中心，节点内逻辑架构设计如图2所示。

图2 节点内部逻辑架构图

3 关键技术

3.1 针对有限带宽环境的监控数据上报策略

本项目所在系统日常运行时，在单个网络节点内会有大量监控数据产生，而目标环境会有多个节点同时接入，监控数据量将会成倍增长，由于网络带宽资源有限，目标环境不足以支撑下级节点将所有的监控数据上报给上级节点，本项目将采用以下策略在保证上级节点能够有效监控下级节点的同时尽量减少网络带宽的负担：

3.1.1 监控数据分级。将采集到的监控数据根据紧急程度进行分级，优先保障情况紧急的监控信息如性能告警、资源负荷紧张等第一时间从下级节点上传至上级监控中心，而紧急程度不高的监控数据如显示席位运行状态正常的数据将批量压缩后再跨专网进行汇总。

3.1.2 监控数据压缩。在没有紧急程度高的监控数据出现的情况下，将相邻几个采集周期所收集的监控数据取均值上报以描述一个较长时间内的系统运行状态，减少了上报的监控数据量，延长了上报时间间隔，从而减少网络带宽占用量。

3.1.3 监控数据按需上报。平时下级节点的监控中心仅会定时上报汇总处理后的各项监控摘要信息，若上级节点用户需要查看某项监控数据的全集，则会向下级节点发出请求，下级节点在收到请求后才会按需将全集数据上报给上级节点的监控中心并推送显示。

3.2 面向服务的监控数据汇集技术

在节点内，监控中心提供监控数据上报的服务化接口，使得监控代理与节点监控中心呈松耦合关系，便于节点内监控代理部署数量的扩展，并且监控代理无论运行在何种平台，只要符合接口规范的定义，均能够将席位状态发送至节点监控中心；同样，节点监控中心也可以快速获取异构网络环境下数据共享服务以及通信服务的状态。

3.3 基于ICE的分布式日志管理技术

ICE是由ZeroC公司推出的一种新的高性能的对象中间件平台。本文将系统内产生的日志数据从广泛的监控数据中剥离出来单独维护管理，建立了一套基于ICE的分布式日志管理方法。

首先，本文拟定了可扩展日志内容文本规则，日志数据必须满足此规则才能被系统管理起来；其次，监控代理会定期扫描本地的日志数据并为它们建立日志索引，并将索引上传至节点监控中心，而原始的日志数据依旧存储在各席位上，从而分摊了存储压力，实现了日志数据的分布式存储，日志索引的集中式管理；然后，节点监控中心仅将汇总的日志索引进行跨专网上报，减少了在日常运行过程中，日志数据传输对带宽的占用；最后系统将日志索引呈现给用户，并提供一定的统计数据，用户也可以通过索引反向检索查看原始日志数据。

3.4 基于ICE的web实时通信技术

在日常运行过程中，系统会产生告警、通知等消息需要推送至Web前端的用户，由于http协议的原因，若想要获取这些消息，传统的做法是采用Ajax轮询的方法，这样无疑会带来不必要的网络流量，本文提出了一种基于ICE的Web实时通信方案，能够将系统产生的消息主动推送至Web前端。在节点监控中间建立一个Web实时通信服务，通过ICE与Web前端用户建立双向连接，并负责维护一张用户的消息订阅列表，当这个Web实时通信服务受到某条消息时，就会去查看消息订阅列表并将消息通过之前建立的双线连接分发给订阅了的Web前端用户，从而实现了消息从后台服务主动推送至Web前端的方法。

4 实现与效果

4.1 实现

根据前文所述设计及项目需求，本文按如下图3所示的物理结构图搭建了原型软件。每一个节点内都有独立的Web应用为用户提供操作界面，后端采用ThinkPHP框架搭建Web应用，快速获取前端请求的监控数据库中的数据并推送给前端；Web应用的前端通过Ajax访问异步访问后端获取监控数据，也可以通过ICE与监控中心直接建立双向连接并订阅相应主题直接从监控中心获取监控数据，Web前端融入了Bootstrap的UI风格，通过丰富的ECharts图形控件展示获取到的各类监控数据。

图3 物理架构图

监控代理是基于Electron开发的跨平台桌面应用，使用Node.js原生模块收集所在的席位运行状态数据并进行本地化展示。监控代理通过ICE向监控中心注册并建立双向连接，并通过此连接上传监控数据，接受并执行上级下达的监控指令。监控代理平时以托盘形式运行于后台，也可以通过托盘调出本地化界面进行查看。

4.2 效果

本文模拟了由节点A和B组成的专用网络环境，在节点A内部署了节点监控中心，两个节点的若干席位上部署了监控代理，同时将两节点之间的传输带宽限制为2Mbps。本文将所实现的原型系统运行至模拟环境中，实现对数据存储服务、通信链路的监控，最后通过web前端对系统状态进行实时的展示。

节点B中某一席位的监控代理运行界面如图4所示，从节点A中远程查看节点B所有席位的运行状态界面如图5所示。此外节点A的Web前端还提供了对数据共享服务和节点间通信链路的状态的监控能力，具体包括了包括数据共享服务各个节点的存储负荷、余量，各个节点之间的通信链路通连状态、吞吐量等。

图4 监控代理原型示意图

图5 节点内状态监视原型示意图