CTS2消息中间件监控与告警系统的设计与实现

唐维尧，白铁男，李从英，谭海波，金石声

(贵州省气象信息中心，贵州 贵阳 550002)

0 引言

消息是消息队列中最小的概念，是应用程序之间传递的信息载体[1]。消息可以非常简单，比如只包含文本字符串、XML、JSON等；也可以非常复杂，比如图片、BUFR(Binary universal form for representation of meteorological data)编码的二进制文件。消息队列(Message queue，MQ)也可以称为消息队列中间件或消息中间件，它是一种利用高效可靠的消息传输机制进行与搭建平台无关的数据交流方式。消息队列传输数据有着很明显的优点，特别是解耦和异步，前者可以使得上游和下游业务互不影响，后者大大缩短了各程序的响应时间。目前市场上的消息中间件有很多，比较主流的消息队列有RabbitMQ、ActiveMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ等。综合考虑传输效率、持久化消息、综合技术实现和高并发等几个方面因素，中国气象局选择了RabbitMQ作为消息中间件部署CTS2，国内气象通信软件系统第二版)中的消息传输系统[2]。

气象系统的监控与告警有多种实现方式，例如李四维等[3]基于编程语言和数据接口实现气象数据传输监控，但这种方式可扩展性较差，配置较为复杂，推广应用较为困难。Zabbix是一个企业级分布式开源监控平台，该平台能够监控网络参数和服务器的健康度、完整性，告警机制灵活，允许用户为任何事件配置告警，这样用户可以快速响应服务器问题。白铁男等[4]通过搭建Zabbix对贵州省实时气象数据的传输进行了有效监控，并得到推广应用。杨立苑等[5]基于Zabbix开发了江西省气象云监控运维系统，极大提高了运维效率。谭海波等[6]基于Zabbix开发了贵州省气象区域站的全流程监控与告警系统，凸显了Zabbix在颗粒级监控的优势。目前国家气象局推广使用的监控系统“天镜”可以对RabbitMQ队列进行监控，但只是对队列的传输概况进行简单监控，没有精细化到数据类型和具体队列，无法满足当下的监控业务需求。

本文通过开源监控平台设计并实现消息队列的监控和告警，提高消息类气象数据的监控精度和气象数据传输服务与保障能力，减轻业务人员的运维压力。

1 RabbitMQ在CTS2中的应用

RabbitMQ是由erlang语言开发，基于AMQP(Advanced Message Queue 高级消息队列协议)协议实现的消息队列。图1展示的是RabbitMQ的主要构件。

图1 RabbitMQ的主要构件

图1中Broker是指消息队列服务进程，此进程包括2个部分，分别是Exchange和Queue。Exchange是指消息队列交换机，按一定的规则将消息路由转发到某个队列，对消息进行过滤；Queue是指消息队列，存储消息的队列，消息到达队列并通过Channel(通道)转发给指定的消费者；Producer：消息生产者，即生产方客户端，生产方客户端将消息发送；Consumer：消息消费者，接收RabbitMQ转发的消息。消费者消费是指消费者从消息队列中取走数据的过程。

为了精细化监控消息队列中的关键数据，需要掌握消息队列在CTS2中所扮演的角色。目前，除雷达流数据，贵州省90%以上的气象数据收发都需要通过RabbitMQ队列，其中主要分为文件类数据和消息类数据，下面将详细介绍。

1.1 基于Redis调度的消息传输

CTS2在现有系统基础上新增消息传输、流传输模式，并以Redis任务队列为核心的交换控制系统替换现有的调度系统，大幅度提升了文件类气象数据实时传输效率[2]。任务队列机制中包含2种角色，一个是任务生产者，一个是任务消费者，而任务队列是两者之间的纽带，图2是CTS2系统中文件类气象数据的收发流程。表现在任务队列中的运行流程如图3所示。

从图2和图3可以看出，任务队列的整体运行流程是：首先调度程序结合收发策略中的目录收集策略、文件名模板策略等生成收集消息，之后发到交换器X_CTS_BABJ_COLL_TASK中，该交换器绑定了队列Q_CTS_BABJ_COLL_TASK，因为收集消息就会放到该队列中，收集进程将会取出消费，消费的过程包括收集分类、原始文件存档等；之后生成处理消息放到交换器X_CTS_BABJ_PROC_TASK中，该交换器绑定了Q_CTS_BABJ_PROC_TASK，因此处理消息就会放到该队列中，处理进程将会取出该消息进行消费，消费过程包括文件名检查、时效检查、格式检查等；之后生成分发消息放到交换器X_CTS_BABJ_DIST_TASK，该交换器绑定了Q_CTS_BABJ_DIST_TASK，因此分发消息就会放到该队列中，分发进程将会取出进行消费，消费的过程包括文件存档、记录消息等。整个过程中消息体并没有包括数据，消息以任务的形式流转，而文件类气象数据是在收集目录、处理目录、分发目录之间流转，任务和数据之间相互独立。简而言之，任务生产者把任务放进队列，实际就是把任务的关键信息存储起来，这里会用到Redis数据存储工具；而任务消费者不断地从数据库中取出任务信息，逐一执行。而3个进程的处理日志信息被传到X_CTS_BABJ_COMM_SQL交换器中，该交换器绑定了队列Q_CTS_BABJ_COMM_SQL。

图2 CTS2文件类气象数据的收发流程

图3 任务队列的运行流程

1.2 国家站BUFR消息传输

目前在贵州省部署了84个国家级站点，台站将观测数据封装成消息类型资料再传输到省级，省级通过CTS2中的RabbitMQ进行数据入库和上行中国气象局。图4是具体的国家站BUFR数据传输流程，这里主要以小时BUFR数据为例。

图4 国家站BUFR数据在RabbitMQ中的传输流程

由图4可知，首先台站会通过5672端口将BUFR数据传到交换器X.OBS中，X.OBS一方面把数据传到队列Q.OBS.TO.Monitor后原始文件落盘；一方面传到队列Q.OBS.TO.BABJ，该队列将通过Shovel(RabbitMQ的一个插件，可以把源节点消息发送到目标节点)的方式上行中国气象局；一方面，传到队列Q.OBS.TO.Server，之后通过Shovel的方式传到5680端口的X.OBS，该交换器绑定了队列Q.OBS.PQC；快速质控程序将会从队列Q.OBS.PQC中取到数据，经过处理后把数据传到交换器X.OBS.PQC中。该交换器绑定了4个队列，分别是Q.OBS.PQC.TO.BABJ(之后Shovel到中国气象局)、Q.OBS_PQC.CMADAAS(DPC解码消费)、Q.OBS_PQC_MDOS(MDOS消费)、 Q.OBS.Monitor(文件落盘，是指文件存档在服务器的缓冲目录中)、Q.OBS_PQC.TO.BCGZ(之后Shovel到广州)。

1.3 区域站BUFR消息传输

目前贵州省有3000多个区域站站点，其中国家级考核站点有1400多个。数据从台站上传到省信息中心再到中国气象局的总体流程与国家站几乎一致，但在RabbitMQ中的具体流程完全不同，图5给出了区域站BUFR数据传输流程。

图5 区域站BUFR数据在RabbitMQ中的传输流程

从图5可以看出：首先台站将数据传到SMOS中心站，之后将分为2路进行数据传输，一路通过5680端口传到交换器X.OBS_REG_KH，一路通过5672端口传到交换器X_OBS_REG。X.OBS_REG_KH绑定了Q.OBS_REG_KH_PQC，快速质控程序2将在该队列中取数据，处理之后把数据传到X.OBS_REG_KH.PQC，该队列绑定了Q.OBS_REG_KH.PQC.TO_BABJ，之后将通过Shovel的方式传到中国气象局；而另一路的X_OBS_REG绑定了2个队列，分别是Q.OBS.Monitor和Q.OBS_REG.TO.Server。前者进行质控前文件落盘，后者通过Shovel的方式传到5680端口的X.OBS_REG交换器中，该交换器绑定了Q.OBS_REG.PQC，而快速质控程序1将去该队列中取到数据处理后又放到交换器X.OBS.REG.PQC中，该交换器绑定了3个服务队列，分别是Q.OBS.Monitor(质控后文件落盘)、Q.OBS_REG_PQC.CMADAAS(DPC解码)、Q.OBS_REG_PQC.TO_BCGZ(之后Shovel到广州)。快速质控程序1和快速质控程序2并没有差别，只是部署在不同的服务器中。

从以上可以看出，文件类数据和消息类数据都通过RabbitMQ队列来完成数据的收发业务，因此对关键的RabbitMQ队列进行监控就实现了气象资料传输业务的精准监控。

2 消息队列监控与告警系统的设计与实现

对中国气象局推广的“天镜”监控系统进行调研发现，“天镜”系统仅仅是对队列的总体情况监控，即是RabbitMQ的Overview(总体概况，包括所有队列)进行监控，但无法从Overview监控中准确定位气象数据收发故障的具体原因，这并不能满足业务需求。因此本文基于Zabbix这个开源监控平台，搭建了消息队列的监控与告警系统，以此实现CTS2中消息队列的精细化监控，从而达到对气象数据传输全流程保障。

2.1 Zabbix部署

Zabbix是开源监控平台，通过官网介绍的搭建方式，就可自主搭建在服务器中。而单机监控系统已经不能满足海量数据监控需要，使用HA集群架构并结合Zabbix平台非常有必要。本文搭建和部署Zabbix监控集群平台，包括2个数据库节点、2个服务器节点和2个前端节点，以及多个监控代理，对于每个集群，配置HA高可用性，设置1个虚拟IP显示节点的活动状态，如果基本资源连接失败，节点将自动切换。图6展示的是Zabbix高可用集群架构。当有告警发生时，Zabbix监控系统仪表板页面将有告警弹出并伴有声音告警。

图6 Zabbix集群架构

2.2 Zabbix监控和触发器配置

Zabbix的HTTP代理数据采集方式可以不需要脚本，直接通过curl语句的方式获取队列信息。从图7可知，监控与告警系统首先是通过HTTP代理获取信息，之后创建监控项，在该监控项的基础上创建仪表盘依赖项，再通过配置依赖项的方式在采集到的信息上剥离出所需要的队列指标信息，在此基础上再配置触发器告警；在配置触发器时，通过count函数，将未确认的消息数连续几次采集均超标一定数值作为触发条件，这样就可以避免因为瞬时积压而造成的频繁告警。

图7 Zabbix监控与告警配置的技术路线

例如在配置Q_CTS_BABJ_COLL_TASK队列的监控告警中，首先需要在监控主机中创建监控项，然后在监控类型中选择HTTP代理，监控名称和监控键值相同即可，这里用的是“CTS_SCH_MQ_QUEUES”可自定义但不能有重复；之后URL的创建方式是“http://用户名:密码@IP:端口/api/queues”，这是采集该地址下的所有队列，然后再通过配置仪表盘依赖项，名称和键值为CTS_SCH_MQ_QUEUES_Q_CTS_BABJ_COLL_TASK_messages_unacknowledged(这里以message_unacknowledged，消息未确认数监控为例)，类型选择相关项目，主要项就是选择上述创建的监控项“CTS_SCH_MQ_QUEUES”，之后再配置进程，在第一步名称选择JSONPath，参数是“$.[?(@.name==′Q_CTS_BABJ_COLL_TASK')].messages_unacknowledged”。这个参数的意义就是从上述的监控项结果中取出关键字′Q.OBS_REG_KH.PQC.TO.BABJ'，之后取出关于该队列的messages_unacknowledged的实时参数，从而获取到了Q_CTS_BABJ_COLL_TASK的messages_unacknowledged实时参数值，达到监控该队列的消息未确认数的目的，其他参数值类似该配置流程；之后再创建告警触发器，名称自定义为“调度队列COLL积压”，严重性选择严重，问题表现形式为“{ CTS_SCH_MQ_QUEUES_Q_CTS_BABJ_COLL_TASK_messages_unacknowledged.count(3,100,ge)}>=2”，意思是当未确认的消息数连续3次采集均超过100将触发告警，告警内容为“调度队列COLL积压”，恢复表达式为与问题表现形式相反，将“>=”改成“<”即可，当触发器告警后，恢复表达式满足时，即可自动关闭告警并显示恢复。

2.3 Zabbix拓扑图

Zabbix可配置拓扑图，更加直观地展示传输流程，一旦触发告警，可从拓扑图中快速定位故障原因，使得运维更加高效以调度队列拓扑图为例(图8)。调度任务需要重点关注其收集、处理、分发以及数据库日志收集4个方面的数据收发业务，与之对应的就是收集队列Q_CTS_BABJ_COLL_TASK、处理队列Q_CTS_BABJ_PROC_TASK、分发队列Q_CTS_BABJ_DIST_TASK和日志收集队列Q_CTS_BABJ_COMM_SQL。图中所显示的数值是队列积压的关键指标：消息未确认数。对于消息类数据的队列， 国家站和区域站BUFR也可通过相同的方式在Zabbix中配置拓扑图来直观展示其传输流程。

图8 调度Redis队列的拓扑示意图

2.4 Zabbix-Grafana展示

Grafana是一个跨平台的开源的度量分析和可视化工具，可以通过查询采集到的数据进行可视化展示。它最大的特点是展示方式和数据源多样：有快速灵活的客户端图表，面板插件有许多不同方式的可视化指标和日志，官方库中具有丰富的仪表盘插件；可链接的数据源多达50多种。本研究把Zabbix作为数据源，可视化展示Zabbix的监控项，达到展示监控队列的目的。图9是以调度队列作为样例，通过加载不同的图表展示了Overview和每个队列的关键指标，例如ack_rate(消息确认速率)，publish_rate(消息发布速率)，deliver_rate(消息接收速率)，队列中的messages(消息总数)，messages_ready(准备发布的消息数)，messages_unacknowledged(消息未确认数)。

图9 调度Redis队列Grafana监控展示

3 结论

本文通过梳理2类重要数据：文件类和消息类，掌握CTS2中基于消息中间件的分发流程，设计并实现了消息中间件的监控与告警系统，从而提高气象数据传输保障能力。其中还实现了Zabbix监控拓扑图和Zabbix-grafana数据监控展示，自主开发订制并构建了一套从监控到告警，再到展示的消息队列传输全流程保障系统，实现了消息队列的精细化监控，高效准确地定位气象数据传输故障原因，大大减轻了业务人员的运维压力。