CN115134262B - RocketMQ监控方法及装置、存储介质及电子设备 - Google Patents

RocketMQ监控方法及装置、存储介质及电子设备 Download PDF

Info

Publication number
CN115134262B
CN115134262B CN202211053264.4A CN202211053264A CN115134262B CN 115134262 B CN115134262 B CN 115134262B CN 202211053264 A CN202211053264 A CN 202211053264A CN 115134262 B CN115134262 B CN 115134262B
Authority
CN
China
Prior art keywords
monitoring
consumption
production
dimension
early warning
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202211053264.4A
Other languages
English (en)
Other versions
CN115134262A (zh
Inventor
高永飞
王峰
张益军
王金明
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Feihu Information Technology Tianjin Co Ltd
Original Assignee
Feihu Information Technology Tianjin Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Feihu Information Technology Tianjin Co Ltd filed Critical Feihu Information Technology Tianjin Co Ltd
Priority to CN202211053264.4A priority Critical patent/CN115134262B/zh
Publication of CN115134262A publication Critical patent/CN115134262A/zh
Application granted granted Critical
Publication of CN115134262B publication Critical patent/CN115134262B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes

Abstract

本发明提供一种RocketMQ监控方法及装置、存储介质及电子设备，确定待监控的RocketMQ和监控配置信息，RocketMQ包含生产端、存储端和消费端，监控配置信息中包含生产端的各个生产监控维度、存储端的各个存储监控维度以及消费端的各个消费监控维度；基于生产端的各个生产监控维度，对生产端进行监控；基于存储端的各个存储监控维度，对存储端进行监控；基于消费端的各个消费监控维度，对消费端进行监控；在监控的过程中，对具有预警需求的监控维度进行预警分析，并在满足预警条件时生成预警信息。本发明全面的对RocketMQ进行监控，可得到全面的监控信息，并且可及时进行预警。

Description

RocketMQ监控方法及装置、存储介质及电子设备
技术领域
本发明涉及计算机技术领域，特别涉及一种RocketMQ监控方法及装置、存储介质及电子设备。
背景技术
RocketMQ作为一款纯java、分布式、队列模型的开源消息中间件，支持事务消息、顺序消息、批量消息、定时消息、消息回溯等。越来越多的项目采用RocketMQ分布式消息中间件处理应用耦合、异步消息等场景。
为了保证RocketMQ的正常运行，通常需要对RocketMQ的状态进行监控，目前对RocketMQ的监控方式通常是局部的，无法对RocketMQ进行全面的监控，导致无法及时得知RocketMQ的全面情况。
发明内容
有鉴于此，本发明提供一种RocketMQ监控方法及装置、存储介质及电子设备，应用本发明提供的监控方法可以全面的对RocketMQ进行监控，以便及时了解RocketMQ的情况。
为实现上述目的，本发明实施例提供如下技术方案：
一种RocketMQ监控方法，包括：
确定待监控的RocketMQ和监控配置信息，所述RocketMQ包含生产端、存储端和消费端，所述监控配置信息中包含所述生产端的各个生产监控维度、所述存储端的各个存储监控维度以及所述消费端的各个消费监控维度；
对于每个所述生产监控维度，对所述生产端进行监控，以获取所述生产端在所述生产监控维度的生产监控数据，当所述生产监控维度存在预警需求时，对生产监控数据进行预警分析，并当所述生产端满足所述生产监控维度的预警条件时，生成预警信息；
对于每个所述存储监控维度，对所述存储端进行监控，以获取所述存储端在所述存储监控维度的存储监控数据，当所述存储监控维度存在预警需求时，对所述存储监控数据进行预警分析，当所述存储端满足所述存储监控维度的预警条件时，生成预警信息；
对于每个所述消费监控维度，对所述消费端进行监控，以获取所述消费端在所述消费监控维度的消费监控数据，当所述消费监控维度存在预警需求时，对所述消费监控数据进行预警分析，当所述消费端满足所述消费监控维度的预警条件时，生成预警信息。
一种RocketMQ监控装置，包括：
确定单元，用于确定待监控的RocketMQ和监控配置信息，所述RocketMQ包含生产端、存储端和消费端，所述监控配置信息中包含所述生产端的各个生产监控维度、所述存储端的各个存储监控维度以及所述消费端的各个消费监控维度；
第一监控单元，用于对于每个所述生产监控维度，对所述生产端进行监控，以获取所述生产端在所述生产监控维度的生产监控数据，当所述生产监控维度存在预警需求时，对生产监控数据进行预警分析，并当所述生产端满足所述生产监控维度的预警条件时，生成预警信息；
第二监控单元，用于对于每个所述存储监控维度，对所述存储端进行监控，以获取所述存储端在所述存储监控维度的存储监控数据，当所述存储监控维度存在预警需求时，对所述存储监控数据进行预警分析，当所述存储端满足所述存储监控维度的预警条件时，生成预警信息；
第三监控单元，用于对于每个所述消费监控维度，对所述消费端进行监控，以获取所述消费端在所述消费监控维度的消费监控数据，当所述消费监控维度存在预警需求时，对所述消费监控数据进行预警分析，当所述消费端满足所述消费监控维度的预警条件时，生成预警信息。
一种存储介质，所述存储介质包括存储的指令，其中，在所述指令运行时控制所述存储介质所在的设备执行如上所述的RocketMQ监控方法。
一种电子设备，包括存储器，以及一个或者一个以上的指令，其中一个或者一个以上指令存储于存储器中，且经配置以由一个或者一个以上处理器执行如上所述的RocketMQ监控方法。
与现有技术相比，本发明具有以下优点：
本发明提供一种RocketMQ监控方法及装置、存储介质及电子设备，确定待监控的RocketMQ和监控配置信息，RocketMQ包含生产端、存储端和消费端，监控配置信息中包含生产端的各个生产监控维度、存储端的各个存储监控维度以及消费端的各个消费监控维度；基于生产端的各个生产监控维度，对生产端进行监控；基于存储端的各个存储监控维度，对存储端进行监控；基于消费端的各个消费监控维度，对消费端进行监控；在监控的过程中，对具有预警需求的监控维度进行预警分析，并在满足预警条件时生成预警信息。本发明全面的对RocketMQ进行监控，可得到全面的监控信息，并且可及时进行预警。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本发明实施例提供的一种RocketMQ监控方法的方法流程图；
图2为本发明实施例提供的在生产端的生产流量监控维度的监控流程图；
图3为本发明实施例提供的生产端的生产耗时监控维度的监控流程图；
图4为本发明实施例提供的在生产端的生产失败监控维度的监控流程图；
图5为本发明实施例提供的存储端的主从同步状态监控维度的监控流程图；
图6为本发明实施例提供的在存储端的消息存储状态监控维度的监控流程图；
图7为本发明实施例提供的在存储端的服务器状态监控维度的监控流程图；
图8为本发明实施例提供的在存储端的Broker/NameServer存活状态监控维度的监控流程图；
图9为本发明实施例提供的在消费端的消费堆积监控维度的监控流程图；
图10为本发明实施例提供的在消费端的消费堵塞监控维度的监控流程图；
图11为本发明实施例提供的在消费端的消费流量统计监控维度的监控流程图；
图12为本发明实施例提供的在消费端的消费落后监控维度的监控流程图；
图13为本发明实施例提供的在消费端的订阅状态监控维度的监控流程图；
图14为本发明实施例提供的在消费端的偏移量错误监控维度的监控流程图；
图15为本发明实施例提供的在消费端的死信消息监控维度的监控流程图；
图16为本发明实施例提供的一种RocketMQ监控方法的实现架构图；
图17为本发明实施例提供的一种通信扩展的类的示例图；
图18为本发明实施例提供的一种RocketMQ监控装置的结构示意图；
图19为本发明实施例提供的一种电子设备的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
术语解释：
RocketMQ：一种开源的分布式消息中间件；
生产者：往RocketMQ生产消息的客户端程序，优选的，生产者也称为生产端；
消费者：从RocketMQ消费消息的客户端程序，优选的，消费者也称为消费端；
Broker：RocketMQ的消息储存模块，主要负责消息存储和消息路由；
NameServer：RocketMQ注册中心，主要负责Broker注册服务和Client端路由查找；
nmon：用于Linux/Unix操作系统性能状况收集的开源工具；
Topic：标识一类消息的逻辑名字，消息的逻辑管理单位；
MQCloud：一种开源的RocketMQ监控运维平台。
RocketMQ逐渐应用在各种项目中，想查询RocketMQ实时状况时，需要通过mqadmin命令行工具进行实时查询，该操作需要在命令行进行操作，费时且安全系数较低。RocketMQ中未提供历史统计数据的查询，所以无法展示监控指标的变化趋势。
本发明可用于众多通用或专用的计算装置环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器装置、包括以上任何装置或设备的分布式计算环境等等。
本发明提供一种RocketMQ监控方法，该方法可用于MQCloud，应用本发明提供的方法，可以全面的对RocketMQ进行监控，可以及时得知RocketMQ在各个方面的情况。
参照图1，为本发明实施例提供的一种RocketMQ监控方法的方法流程图，具体说明如下所述。
S101、确定待监控的RocketMQ和监控配置信息，RocketMQ包含生产端、存储端和消费端，监控配置信息中包含生产端的各个生产监控维度、存储端的各个存储监控维度以及消费端的各个消费监控维度。
本发明实施例提供的方法中，监控配置信息可以是预先配置的。
当接收到用户发送的监控请求时，对该监控请求解析，获取监控信息，基于该监控信息可以确定待监控的RocketMQ。
需要说明的是，监控配置信息中包含生产端的各个生产监控维度、存储段的各个存储监控维度以及消费端的各个消费监控维度。
对RocketMQ的监控是从生产端、存储端以及消费端这三个方面进行监控的，并且，不同的监控方面均有多个监控维度，由此对RocketMQ的监控覆盖了RocketMQ的全链路，对RocketMQ的监控更加的全面。
S102、对于每个生产监控维度，对生产端进行监控，以获取生产端在生产监控维度的生产监控数据，当生产监控维度存在预警需求时，对生产监控数据进行预警分析，当生产端满足生产监控维度的预警条件时，生成预警信息。
优选的，生产端的各个生产监控维度包括生产流量监控维度、生产耗时监控维度以及生产失败监控维度。
需要说明的是，当生产监控维度存在预警需求时，可进行对应的预警分析，以便及时反馈预警信息，优选的，生产监控维度是否存在预警需求可预先进行设置，可为生产监控维度设置对应的预警条件，当生产监控维度不存在预警需求时，可以将生产监控数据进行保存、展示等处理。
生产端的这几个监控维度可以并行进行监控。
进一步的，生成的预警信息中包含对应的生产监控维度的信息，例如，在生产流量监控维度进行监控时生成了预警信息，则预警信息中包含了生产流量监控维度的信息，例如异常原因、维度信息等；由此，在将预警信息向用户反馈时可以准确的告知客户出现异常的具体维度，便于用户后续的维护。
对生产端的每个生产监控维度的监控过程逐一进行说明，具体内容如下所述。
（一）、生产流量监控维度的具体内容如下所述。
在生产流量监控维度的监控流程具体如：
当生产监控维度为生产流量监控维度时，定时从存储端的每个消息存储模块中采集生产流量统计数据，生产流量监控维度具有预警需求；
确定历史流量统计数据，对历史流量统计数据和生产流量统计数据进行分析，得到流量变化幅度，当流量变化幅度大于预设变化幅度时，确定生产端满足生产监控维度的预警条件。
优选的，存储端中预先设置了统计流程，该统计流程中包含计数器，不同的消息计数器用于统计不同消息Topic的流量数据，需要说明的是，Topic用于标识一类消息的逻辑名字，消息的逻辑管理单位，每个消息发送请求都会携带该消息所属的Topic。
消息存储模块用于保存每个计数器保存的流量数据，流量数据包括但不限于消息发送次数和消息发送量大小，在消息发送成功后，与该消息Topic对应的计数器会累加上该次发送次数和该次发送消息量大小。
优选的，生产流量统计数据中包含了当日的平均流量和最大流量，历史流量统计数据包含了在预设历史时间段的平均流量和最大流量，预设历史时间段可以根据实际需要进行设置，例如15天、30天，示例性的，预设历史时间段的平均流量和最大流量可以为前31天内的平均流量和最大流量。
生产流量统计数据中包含了当前的平均流量和最大流量，历史流量统计数据包含了在预设历史时间段的平均流量和最大流量可以确定流量变化幅度，将流量变化幅度与预设变化幅度进行对比，当流量变化幅度大于预设变化幅度时，确定生产端满足生产监控维度的预警条件，优选的，此处也可以确定生产端满足生产流量监控维度的预警条件。进一步的，当流量变化幅度不大于预设变化幅度时，确定生产端不满足生产监控维度的预警条件。
参照图2，为本发明实施例提供的在生产端的生产流量监控维度的监控流程图。
如图所示，监控流程分为两个部分，具体说明如下所述。
流程图中的①中包含的流程内容，具体为：Broker端内部统计流程，当消息发送成功后，消息Topic对应的计数器内部将会累加上该次发送次数和该次发送消息量大小，计数器将统计的数据保存在Broker端的存储模块中。
示例性的，当Broker接收到消息发送请求并成功持久化后，在JVM内存中记录下该次发送的状态，并按照Topic维度进行统计，其中，JVM表示Java虚拟机，英文全称为JavaVirtual Machine。进一步的，Broker的持久化由独立方法appendMessagesInner()执行，该方法的执行结果正常返回，就说明该消息的持久化已成功完成，后续的对消息流量的统计是基于该方法正常返回，也就是消息正常持久化。
流程图中的②中包含的流程内容，具体为：MQCloud内置数据采集任务，将定时采集每个存储模块中的统计数据，并进行分析处理，最后持久化至数据库中，并且定时分析采集的流量数据与历史数据进行比较，如果发现流量变化幅度超过设置的阈值，将发送预警邮件至绑定的责任人。
优选的，持久化的流量数据可以以曲线的方式在MQCloud的web端进行展现，并支持任意时间段的流量数据查询展示。优选的，在web端展示的流量数据可以是选中的数据，通过曲线可以体现出当日和昨日的瞬时最大峰值，累计发送的消息条数，累计发送的消息大小等内容，还可以实时展示当日的消息瞬时发送量曲线，消息瞬时发送大小曲线，除此之外，还可以展示昨日的全时段的消息量，消息大小发送曲线，且能与当日发送曲线重合展示，便于及时发现当前流量的异常点，且能一定程度预测后续的流量变化。优选的，本发明在展示流量数据时不局限于使用曲线的方式进行展示，还可以使用其他可以表示数据趋势的方式将流量数据展示。
进一步的，MQCloud会定期检测生产流量变化幅度，如果变化率超限，会确定流量异常，此时将会发送报警邮件。
参照表1，为MQCloud检测流量的具体示例表，具体如下：
Figure 772885DEST_PATH_IMAGE001
优选的，在发送报警邮件时，还可以将检测到异常的数据以表1的形式进行汇总后添加在报警邮件中进行报警。
（二）、生产耗时监控维度的具体内容如下所述。
参照图3，为本发明实施例提供的生产端的生产耗时监控维度的监控流程图。
如图所示，监控流程分为两个部分，具体说明如下所述。
流程图中的①中包含的流程内容，具体为：通过在生产者采用统计组件，对发送消息的进行耗时和次数统计，形成客户端统计数据，客户端将定时上传该统计数据至MQCloud中。
需要说明的是，生产端中内嵌统计组件，该统计组件可以表示为StatsHelper，在JVM内存中统计消息发送耗时及次数，并依据一定分类规则进行数据统计归类，定时上报该统计数据至MQCloud中，此处的耗时是指单次消息发送的耗时，次数是总次数。
进一步的，分类规则是指消息发送耗时的不同区间，示例性的，在MQCloud中拟定了0~10ms，10~15ms，……不同区间，峰值是3100ms。MQCloud会找出本次消息发送耗时对应的区间，例如本次耗时12ms，对应区间为10~15ms，进而找到该区间对应的计数器，增加该计数器计数，完成发送次数统计。
流程图中的②中包含的流程内容，具体为：MQCloud接收到统计数据后进行分析组装，持久化至数据库中，便于web端的数据查询展示。
优选的，MQCloud会定时对已上报的数据进行分析，统计单位时间内的变化幅度并对比设置的预警阈值，如果超限，则进行对绑定的责任人进行邮件预警。
优选的，还可以在MQCloud平台web端展示客户端的生产流量数据及历史趋势以及耗时数据等，优选的，在展示时，支持展示百分位数请求的耗时（如90%，99%），平均耗时，最大耗时，调用量等内容。
（三）生产失败监控维度的具体内容如下所述。
生产失败是发送消息过程中由于网络等原因无法成功发送消息的情况。
在生产失败监控维度的监控流程具体如：
当生产监控维度为生产失败监控维度时，定时接收生产端发送的异常累计数据，生产失败监控维度存在预警需求；
基于异常累计数据确定异常比例，当异常比例大于预设异常比例时，确定生产端满足生产监控维度的预警条件。
需要说明的是，异常累计数据中包含消息发送失败的累计数据。优选的，异常比例可以是在预设时间内发送失败的消息数占该预设时间内发送的消息总数的比值，预设时间可以是单位时间，可以根据实际需要进行设置，预设异常比例可以根据实际需要进行调整。
参照图4，为本发明实施例提供的在生产端的生产失败监控维度的监控流程图。
如图所示，监控流程分为两个部分，具体说明如下所述。
流程图中的①中包含的流程内容，具体为：为在生产者发送消息过程中，监控每次消息发送状态，如果发送失败，累加异常计数器，并定时向MQCloud上报异常统计数据。
优选的，生产者可以使用预先设置的异常统计助手统计在单位时间内消息发送失败的次数及异常信息，并定时将统计的异常数据上报至MQCloud。
流程图中的②中包含的流程内容，具体为：MQCloud接收到上报数据后，将数据持久化处理，内部定时任务将定时分析异常比例，对比设置的预警阈值，向绑定的责任人发送预警邮件。
优选的，MQCloud会定时扫描已上报的生产端数据，筛选异常信息，并对绑定的责任人进行邮件预警，进一步的，持久化的异常数据也以曲线的方式在MQCloud的web端进行展现，优选的，展现的异常数据可以为生产者发送消息时产生的异常数及异常类型，监控发送端的发送状态，便于及时发现问题，且支持任意时间段的异常曲线查询。
进一步的，参照表2，为本发明实施例提供的与生产失败监控维度相关的异常检测数据的数据示例表，具体内容如下所示：
Figure 221183DEST_PATH_IMAGE002
优选的，在发送报警邮件时，可以将表2作为预警结果添加在报警邮件中进行报警。需要说明的是，表中的producer表示生产者组名；ums-custom-group-test表示一个生产者组名，使用业务服务自定义，起到标识的作用；RemotingConnectExcption表示连接异常；RemotingTooMuchRequestExcption表示远程请求过多异常，两者均表示开发层面的异常，主要是为了方便业务开发人员定位异常位置。进一步的，表2中的异常仅为举例说明，本发明中与生产失败监控维度相关的异常不局限于表2中连接异常、远程请求过多异常，本发明中与生产失败监控维度相关的异常此处不再一一进行举例说明。
S103、对于每个存储监控维度，对存储端进行监控，以获取存储端在存储监控维度的存储监控数据，当存储监控维度存在预警需求时，对存储监控数据进行预警分析，当存储端满足存储监控维度的预警条件时，生成预警信息。
优选的，存储端的各个存储监控维度包括主从同步状态监控维度、消息存储状态监控维度、服务器状态监控维度以及Broker/NameServer存活状态监控维度；进一步的，在对存储端进行监控时，与存储端对应的各个存储监控维度可以并行监控。
进一步的，生成的预警信息中包含对应存储监控维度的信息，例如在消息存储状态监控维度进行监控时生成了预警信息，则预警信息中包含了消息存储状态监控维度的具体内容，例如异常原因、维度信息等；由此，在将预警信息向用户反馈时可以准确的告知客户出现异常的具体维度，便于用户后续的维护。
需要说明的是，当存储监控维度存在预警需求时，可进行对应的预警分析，以便及时反馈预警信息，优选的，存储监控维度是否存在预警需求可预先进行设置，可为存储监控维度设置对应的预警条件，当存储监控维度不存在预警需求时，可以将存储监控数据进行保存、展示等处理。
对存储端的每个存储监控维度的监控过程逐一进行说明，具体内容如下所述。
（一）、主从同步状态监控维度的具体内容如下所述。
主从同步是指Broker主从节点向从节点同步数据，优选的，RocketMQ集群配置的Broker节点分为主节点和从节点两种类型，一般对外提供服务的为主节点，从节点主要是在主节点宕机的情况下，对外提供服务。为此，主从节点上的数据一致性需要一定的保证，以免在发生主节点宕机从节点提供服务功能时，产生消息丢失情况。
参照图5为本发明实施例提供的存储端的主从同步状态监控维度的监控流程图。
如图所示，监控流程分为两个部分，具体说明如下所述。
流程图中①中包含的流程内容，具体为：Broker记录当前节点内部消息最大偏移量及从节点同步偏移量。
优选的，Broker端保存有最新的消息物理偏移量和从节点同步偏移量，该信息存储在内存中。
流程图中②中包含的流程内容，具体为：MQCloud定时采集主从同步状况信息，并根据采集的主从同步状态信息确定主从同步差异值，基于主从同步差异值和预先设置的差异预警阈值进行对比，如果主从同步差异值大于差异预警阈值，则向绑定的责任人发送预警邮件。其中，差异预警阈值可以根据实际需求进行设置。
主从同步状态信息中包含当前节点内部消息最大偏移量及从节点同步偏移量等信息。
需要说明的是，当主从节点存储进度差异太大，责任人就会收到预警邮件，优选的，预警邮件上表明了主从同步的集群和主节点。
参照表3，为本发明实施例提供了关于主从同步状态监控维度的监控数据示例数据表，具体如下所述：
Figure 905980DEST_PATH_IMAGE003
需要说明的是，表3中的落后量可以理解为上文中的主从同步差异值，阈值可以理解为差异预警阈值。
（二）、消息存储状态监控维度的具体内容如下所述。
Broker接收到消息发送请求后，会进行消息的持久化。如果消息的存储执行时间过长，势必会造成消息发送请求积压，造成Broker吞吐量急剧下降，影响整个集群性能。
在存储监控维度为消息存储状态监控维度的监控流程，具体如：
当存储监控维度为消息存储状态监控维度时，定时采集消息统计数据，消息存储状态监控维度具有预警需求；
对消息统计数据进行处理，得到第一分析数值和第二分析数值；
当第一分析数值大于预设的第一报警阈值，且第二分析数值大于预设的第二报警阈值时，确定存储端满足存储监控维度的预警条件。
需要说明的是，采集的消息统计数据中包括多个消息的耗时以及每个计数器的统计数据等，各个耗时均存在对应的时间区间，时间区间，是对存储耗时进行的时间段划分，例如0~10ms，10~15ms等，每个时间区间均存在对应的计数器，计数器用于进行计数操作。
优选的，第一分析数值可以为消息统计数据中的最大耗时，第二分析数值为从消息统计数据的各个耗时中选择的耗时，将该耗时作为目标耗时，优选的，在选择目标耗时时，目标耗时可以使得消息统计数据中小于或等于目标耗时的数量与耗时总数量的比值达到预设比值，进一步的，目标耗时还可以使得消息统计数据中大于或等于目标耗时的数量与耗时总数量的比值达到预设比值，优选的，预设比值可以为99%。
需要说明的是，第一报警阈值和第二报警阈值可以根据实际需求进行设置。
进一步的，当第一分析数值不大于预设的第一报警阈值，和/或第二分析数值不大于预设的第二报警阈值时，确定存储端不满足存储监控维度的预警条件。
参照图6，为本发明实施例提供的在存储端的消息存储状态监控维度的监控流程图。
如图所示，监控流程分为两个部分，具体说明如下所述。
流程图中的①中包含的流程内容，具体为：Broker消息持久化时，进行耗时和写入量统计，包括百分位数耗时统计，平均耗时，最大耗时等。
需要说明的是，Broker中嵌入消息存储统计组件，针对不同时间区间的平均耗时，最大耗时，百分位数耗时及调用量进行统计，时间区间为对存储耗时进行的时间段划分，例如0~10ms，10~15ms等，各个时间区间对应各自的计数器，存储成功后将依据存储时间找到对应区间，从而获取计数器，进行计数操作。
流程图中的②中包含的流程内容，具体为：MQCloud定时采集Broker的存储数据，进行持久化处理，并对比MQCloud设置的阈值，如果超限，将发送预警邮件至绑定的责任人。
需要说明的是，此处设置的阈值有两个，计算出来的阈值也有两个，先对设置的两个阈值进行说明，两个阈值均为预设的耗时，使用第一预设耗时和第二预设耗时进行区分。根据采集的耗时数据计算出来的阈值使用第一耗时和第二耗时进行区分，其中，第一耗时为采集的耗时数据中的最大耗时，第二耗时使得采集的耗时数据中大于或等于第二耗时的数量与耗时总数量的比值达到99%，或是使得采集的耗时数据中小于或等于第二耗时的数量与耗时总数量的比值达到99%；进一步的，第一耗时与第一预设耗时进行对比，第二耗时与第二预设耗时进行对比，当第一耗时大于第一预设耗时，且第二耗时大于第二预设耗时时，确定超限；否则，不超限。
示例性的，例如这次采集的最大耗时为560ms，99%的请求耗时为500ms，设置的最大耗时为510ms，设置的99%的请求耗时阀值为450ms，采集的数据中，两者都超限了，就会触发报警。
参照表4，为本发明实施例提供的发送报警邮件时邮件中基于采集到的数据生成的反馈的数据示例表，具体如下所示：
Figure 35610DEST_PATH_IMAGE004
需要说明的是，当Broker的消息写入速度过慢时，可以发送包含表4的内容的邮件，从而展示当前写入过慢的Broker地址、最大写入时间和各个区间的耗时分布，写入量。
（三）、服务器状态监控维度的具体内容如下所述。
在存储监控维度为服务器状态监控维度的监控流程，具体如：
当存储监控维度为服务器状态监控维度时，定时采集与服务器状态监控维度对应的各个服务器指标的指标数值，服务器状态监控维度具有预警需求；
基于每个服务器指标的指标数值和预设预警数值，确定各个服务器指标中是否存在超标的服务器指标；
当确定各个服务器指标中存在超标的服务器指标时，确定存储端满足存储监控维度的预警条件。
需要说明的是，各个服务器指标包括但不限于CPU使用、内存使用率、网络负载情况、磁盘负载情况等。
需要说明的是，服务器指标的预设预警数值可以根据实际情况进行调整，优选的，对于每个服务器指标，将该服务器指标的指标数值和预设预警数值进行对比，当指标数值大于预设预警数值时，确定该服务器指标为超标的服务器指标，当指标数值不大于预设预警数值是，确定该服务器指标不为超标的服务器指标。
参照图7，为本发明实施例提供的在存储端的服务器状态监控维度的监控流程图。
如图所示，MQCloud首先查找所有服务地址，采用nmon进行服务指标采集，并进行持久化处理。
MQCloud定时对采集的服务运行数据进行处理，分别在CPU负载，内存使用率，IO等多个预设的预警指标进行分析，与设置的预警阈值进行比较，如果超限，则发送预警邮件，需要说明的是，当前MQCloud中服务器状态的各个预警指标为：CPU使用率，内存使用率，网络负载情况，磁盘负载情况等，每个指标对应一个阀值，优选的，网络和磁盘中有多个小项，对应多个预警阀值。
需要说明的是，此处的预警指标可以理解为上文中的服务器指标。
进一步的，MQCloud端还可以将采集的服务运行数据将以曲线的形式在web端进行展示，并支持不同时间区间的曲线数据查询。
本发明可以将采集的服务运行数据进行展示，示例性的，MQCloud依据nmon定时采集的指标数据以曲线的形式展示当前的服务器CPU负载，内存使用率等信息，通过可视化展示，便于用户观察指标的变化趋势，用户还可以在展示页面选择展示的时间区间或是查看历史时间的数据曲线等。
优选的，如果发生服务器指标超限，就会发送报警邮件，报警邮件中包含报警类别为超限的监控指标，示例性的，参照表5，表5为本发明实施例提供的超限的监控指标的数据示例表，具体如下所示：
Figure 381141DEST_PATH_IMAGE005
需要说明的是，本发明包含的超限的监控指标不局限于表5所示的内容。
（四）、Broker/NameServer存活状态监控维度的具体内容如下所述。
对RocketMQ进行Broker/NameServer存活状态监控维度的监控可以快速发现集群组件异常状态，便于对故障机器排查重启。
参照图8，为本发明实施例提供的在存储端的Broker/NameServer存活状态监控维度的监控流程图。
在监控的过程中，MQCloud会对已注册的集群中的各个组件进行定时发送探活请求，以判断各个组件的存活状态，如果请求能正常返回，则说明该组件的服务状态正常，能正常提供服务，如果未正常响应探活请求，则判定为该组件的服务状态异常，将发送报警邮件至绑定的责任人，需要说明的是，任意一个组件未正常响应探话请求，就说明当前集群不健康，需要重启组件；最后，可以在MQCloud平台的web端显示各个组件的存活状态，在各个组件的存活状态发生改变时，在web端也要更新各个组件的改变后的存活状态。
需要说明的是，已注册的集群中的各个组件可以为Broker或NameServer节点，进一步的，可以循环发送探活请求。
进一步的，可以将Broker组件的探活状态进行展示，展示页面存在展示Broker组件的探活状态的状态栏，当Broker组件可以正常响应探活请求时，状态栏中显示正常，如果Broker组件不能响应探活请求，则状态栏中显示异常。
需要说明的是，当Broker探活请求未收到正常响应，MQCloud就会发送预设格式的报警邮件，报警邮件中包含使用异常的Broker节点的信息，以及包含探活失败的异常详细信息。
进一步的，MQCloud将对探活的NameServer组件进行监控并展示其当前状态，展示页面存在展示NameServer组件的状态信息的状态栏，状态栏显示正常表示NameServer组件探活成功，状态栏显示异常表示NameServer组件探活失败；优选的，展示页面还可以展示NameServer组件的监控时间、创建时间等信息。
需要说明的是，当NameServer组件探活失败时，需要发送报警邮件，该报警邮件中包含了探活失败的NameServer组件的信息，以及失败异常信息。
S104、对于每个消费监控维度，对消费端进行监控，以获取消费端在消费监控维度的消费监控数据，当消费监控维度存在预警需求时，对消费监控数据进行预警分析，当消费端满足消费监控维度的预警条件时，生成预警信息。
优选的，消费端的各个消费监控维度包括消费堆积监控维度、消费堵塞监控维度、消费流量统计监控维度、消费落后监控维度、订阅状态监控维度、偏移量错误监控维度以及死信消息监控维度。
进一步的，在对消费端进行监控时，与消费端对应的各个消费监控维度可以并行监控。
进一步的，生成的预警信息中包含对应消费监控维度的信息，例如在消费堆积监控维度进行监控时生成了预警信息，则预警信息中包含了消费堆积监控维度的具体内容，例如异常原因、维度信息等；由此，在将预警信息向用户反馈时可以准确的告知客户出现异常的具体维度，便于用户后续的维护。
需要说明的是，当消费监控维度存在预警需求时，可进行对应的预警分析，以便及时反馈预警信息，优选的，消费监控维度是否存在预警需求可预先进行设置，可为消费监控维度设置对应的预警条件，当消费监控维度不存在预警需求时，可以将消费监控数据进行保存、展示等处理。
对消费端的每个消费监控维度的监控过程逐一进行说明，具体内容如下所述。
（一）、消费堆积监控维度的具体内容如下所述。
消费堆积为当消费者消费消息速度小于生产者生产消息的速度，产生大量消息无法及时消费的情况。
在消费监控维度为消费堆积监控维度的监控流程，具体如：
当消费监控维度为消费堆积监控维度时，定时采集存储端的每个消息存储模块的消息偏移信息，消费堆积监控维度具有预警需求；
基于各个消息偏移信息，确定消息堆积量；
当消息堆积量大于预设的消息堆积阈值时，确定消费端满足消费堆积监控维度的预警条件。
需要说明的是，消息偏移信息中包含了发送偏移量和消费偏移量，可以使用发送偏移量减去消费偏移量，得到堆积量，将各个堆积量进行求和运算，得到消息堆积量。
消息堆积阈值可以根据实际需求进行设置，进一步的，当消息堆积量不大于预设的消息堆积阈值时，确定消费端不满足消费堆积监控维度的预警条件。
优选的，不同类型的消息对应不同的消息队列，消息存储模块用于存储消息队列，消息偏移信息中包含多个消息队列的消息偏移数据，消息便宜数据中包含了消息队列的发送偏移量和消费偏移量。
参照图9，为本发明实施例提供的在消费端的消费堆积监控维度的监控流程图。
如图所示，监控流程分为两个部分，具体说明如下所述。
流程图中的①中包含的流程内容，具体为：Broker记录了Topic的最大物理存储偏移量和当前最新的消费偏移量信息。
需要说明的是，物理存储偏移量可以理解为上文中的发送偏移量，即消息发送写入的偏移量；消费偏移量可以理解为消息拉取的偏移量。
进一步的，Broker内存中会记录每次消息发送写入的最大偏移量和消息拉取的最大偏移量，具体的，Broker在接收到消息发送请求并成功写入消息后更新消息写入最大偏移量，在接收到消息拉取请求并成功返回消息后更新消息拉取最大偏移量。
流程图中的②中包含的流程内容，具体为：MQCloud定时采集已注册的Topic的生产消费偏移量信息，获取存储偏移量和消费偏移量的差值，并与设置的阈值比较，如果超限，将发送预警邮件至绑定的责任人。
进一步的，不同的Topic对应不同的消息队列，可以采集每个消息队列的生产消费偏移量信息，生产消费偏移量信息中包含发送偏移量和消费偏移量，确定每个消息队列的偏移量差值，并对各个偏移量差值进行求和运算，将得到的和作为消息堆积量，将消息堆积量与预设堆积阈值进行对比，如果消息堆积量大于预设堆积阈值，则确定超限，否则不超限。
优选的，MQCloud平台可以在web端以列表的形式展示topic的队列的消息堆积大小，优选的，web端所展示的列表中包含了多个消费队列，每个消费队列的发送偏移量、消费偏移量、堆积量等信息。
在展示消息堆积情况时，可以按照客户端、消息队列等维度进行消费详细信息的展示，其中堆积量说明当前队列的消息堆积量，也说明当前的消费进度相较于消息生产落后的情况。
进一步的，在发送报警邮件时，报警邮件中包含异常的内容，具体如总堆积消息量、单个队列最大堆积量、消费滞后时间等。
（二）、消费堵塞监控维度的具体内容如下所述。
消费阻塞表示消费者消费单条消息时间过长。
一个消费者组可能包含多个客户端，如果单个消费客户端存在长时间消费阻塞情况，那么就会影响整个消费者组的消费速度，因此，对消费堵塞情况进行监控是必要的。
参照图10，为本发明实施例提供的在消费端的消费堵塞监控维度的监控流程图。
如图所示，监控流程分为两个部分，具体说明如下所述。
流程图中的①中包含的流程内容，具体为：消费者在消息拉取和消息消费的过程中会实时更新运行数据，可以使用ConsumerRunningInfo类收集消费者的消费数据，其中，收集的数据包含最后消费时间，消费偏移量等指标。
需要说明的是，消费者会在JVM中记录下消息消费的状态，消费时间戳等信息，进一步的，消息消费的状态有两种，成功状态、失败状态。
流程图中的②中包含的流程内容，具体为：MQCloud定时检测各个消费客户端运行数据，依据内置的预警阀值判断当前是否堵塞，如果是，则发送报警邮件。
需要说明的是，内置的预警阀值有两个，预设消费时间和预设消息数量，MQCloud定时检测每个消费客户端运行数据，对于每个消费客户端，对检测到的数据进行分析，得到当前消费客户端的最新消费时间以及当前消费客户端的缓存消息数量，将最新消费时间和预设时间进行对比，以及将缓存消息数量和预设消息数量进行对比，当最新消息时间大于预设时间，且缓存消息数量大于预设消息数量时，确定堵塞，即确定超限，否则，确定不堵塞，即确定不超限。
优选的，每个消费客户端对应一个队列，确定消费客户端堵塞时即确定与其对应的队列堵塞。
需要说明的是，当确定堵塞时，可以发送包含堵塞时间、堵塞队列等信息的报警邮件。
（三）、消费流量统计监控维度的具体内容如下所述。
参照图11，为本发明实施例提供的在消费端的消费流量统计监控维度的监控流程图。
需要说明的是，Broker内置了针对消息消费的统计类，如图中的BrokerStatsManager，可以使用BrokerStatsManager实现计数器的功能，每次消息成功消费时，不同Topic下的消费计数器都会累加，进一步的，每种Topic均存在对应的消费计数器。MQCloud会定时采集Broker中消息消费统计信息，需要说明的是，消息消费统计信息中包含不同主题下的消费的消息量及大小数据，对消息消费统计数据进行分析处理后持久至内置数据库中，形成时间连续的采集样本。MQCloud可以在web端以曲线的形式展示该数据，且支持任意时间段的数据曲线查询。
可以在web端展示消费流量数据，展示消费流量数据的页面可称为消费详情页面，该页面可以展示消费流量曲线，优选的，消费流量曲线可以为实施的消费流量监控的曲线，该页面还可以同时展示订阅相同的多个消费者的消费数据，以及还可以展示生产曲线，以便于工作人员观察生产消费的差值，优选的，该页面还支持查询不同时间区间的曲线。
（四）、消费落后监控维度的具体内容如下所述。
消息的生产和消息的消费是完全解耦的两个过程，如果生产速度大于消费速度就会导致消费落后情况，对于一些要求消息及时性较高的业务场景，消息落后的情况将会导致响应延迟，此监控在于方便的监控落后情况，依据实际场景调整策略，减少消费落后带来的影响。
参照图12，为本发明实施例提供的在消费端的消费落后监控维度的监控流程图。
如图所示，监控流程分为两个部分，具体说明如下所述。
流程图中的①中包含的流程内容，具体为：Broker端流程处理，每次进行消息拉取的同时，计算消费进度大小，保存在内存中，优选的，可以使用momentStatsltemSetFallSize类计算消费落后消息的大小。
需要说明的是，Broker中保存有消息的最大物理偏移量和最新的消费偏移量，其中，最大物理偏移量可以理解为消息发送最大偏移量。
流程图中的②中包含的流程内容，具体为：MQCloud端处理流程，定时进行数据采集，获取各个Broker端的消息消费落后大小，发送邮件至绑定的责任人。
优选的，在向责任人反馈邮件时，邮件中可以包含各个Broker端的消息消费落后大小、内存阈值等信息。
优选的，MQCloud定时采集消费客户端数据，可以对采集的数据进行分析，得到消费偏移量差值，当消费偏移量差值大于预设的阈值时，向责任人发送报警邮件，报警邮件中包含报警的具体原因，其中，消费偏移量差值可以为最大物理偏移量和最新的消费偏移量的差值；可选的，当检测到消费客户端的阻塞时间超过阀值时，也可以向责任人发送报警邮件。
（五）、订阅状态监控维度的具体内容如下所述。
订阅状态可以理解为消费组订阅Topic的状态。
参照图13，为本发明实施例提供的在消费端的订阅状态监控维度的监控流程图。
如图所示，监控流程分为两个部分，具体说明如下所述。
流程图中的①中包含的流程内容，具体为：消费者启动时会将订阅关系保存在JVM中。
需要说明的是，RocketMQ的Broker中维护了消费者与Topic的订阅关系，优选的，可以ConsumerRunningInfo类用于维护消费订阅关系，该关系通过消费者的注册和心跳进行实时维护。
流程图中的②中包含的流程内容，具体为：MQCloud会定时采集消费者中运行时数据，分析是否同一消费者组内订阅不同Topic，如果存在，持久化该异常订阅数据，发送预警邮件。
进一步的，MQCloud定时采集该信息，分析同一个Topic下是否存在多种订阅关系，如果存在，则发生报警邮件，并记录该异常状态的订阅关系。
当消费者订阅多个Topic时候，MQCloud检测出订阅错误将会发送报警邮件，优选的，报警邮件中包含了消费者的订阅信息。
（六）、偏移量错误监控维度的具体内容如下所述。
此处的偏移量可以理解为消息消费偏移量，进一步的，消息消费偏移量为当前消息在消息队列的偏移量。
Broker端在进行消息拉取的时候，会将当前请求的消息偏移量进行校验，如果当前请求的偏移量不合理，会自动重新校验消费偏移量，此种情况下可能会导致消息的重复消费，该监控针对此类异常及时以邮件的形式告知用户，便于后续的问题追踪。
参照图14，为本发明实施例提供的在消费端的偏移量错误监控维度的监控流程图。
如图所示，监控流程分为两个部分，具体说明如下所述。
流程图中的①中包含的流程内容，具体为：Broker端处理流程，首先当接收到消息拉取请求后，解析请求中的消息拉取偏移量，并对偏移量进行校验，如果该偏移量能匹配到消息，那么正常返回，如果该偏移量未能定位到消息，那么就发送特定事件至内置Topic：OFFSET_MOVED_EVENT中。
需要说明的是，Broker会依据消息拉取请求提供的偏移量定位消息，如果未匹配到消息，将发送特定事件至内置Topic中。
流程图中的②中包含的流程内容，具体为：MQCloud处理流程，首先MQCloud会订阅内置Topic：OFFSET_MOVED_EVENT，监听其中的消息状态，如果有新的事件进入，MQCloud消费该消息，并发送报警邮件至责任人。
进一步的，MQCloud订阅该Topic，实时监控队列中的消息变动，如果有新的消息进入，及时发送预警邮件至责任人。
当MQCloud监听到偏移量错误异常出现，会向绑定用户报警，该报警为实时检查，进一步的，报警邮件中包含了详细的报警内容，具体如消费者信息、broker时间、请求偏移量、broker偏移量等信息。
（七）、死信消息监控维度的具体内容如下所述。
死信消息为当消息消费失败次数超过Broker设置的最大失败次数时，失败消息不再重新发送，转而进入死信队列的消息，该队列不会触发消费，需要人工干预。
在消费监控维度为死信消息监控维度的监控流程，具体如下所述：
当消费监控维度为死信消息监控维度时，定时采集预设的死信队列的信息数据，死信消息监控维度具有预警需求；
基于信息数据确定死信队列中是否存在死信消息，当死信队列中存在死信消息时，确定消费端满足消费堆积监控维度的预警条件。
优选的，信息数据中包含死信队列中是否存在消息的内容，优选的，当信息数据为空时，可表示死信队列中不存在死信信息，当信息数据不为空时，表示死信队列中存在死信信息。
参照图15，为本发明实施例提供的在消费端的死信消息监控维度的监控流程图。
如图所示，监控流程分为两个部分，具体说明如下所述。
流程图中的①中包含的流程内容，具体为：Broker端会记录当前进入死信队列的消息数量，维护在内存中，优选的，可以使用BorkerStatsManager类统计死信消息数量。
需要说明的是，RoketMQ中监听进入死信队列的消息数量，在内存中记录该指标。
流程图中的②中包含的流程内容，具体为：MQCloud会定时采集Broker中运行的数据，分析是否存在死信消息，如果存在，则发送预警邮件。
当MQCloud检测到死信消息，将发送预警邮件，便于通知责任人手动重新消费死信消息，优选的，预警邮件中包含了死信消息的具体数量以及对应的队列等信息。
参照图16，为本发明实施例提供的一种RocketMQ监控方法的实现架构图，具体说明如下所述：
图中的①为生产端的监控，主要的监控对象是生产者，这个监控主要关注的维度是消息发送量、耗时及发送失败情况。
图中的②为RocketMQ集群的监控，主要关注的是集群内各个组件的健康状态和消息存储性能、同步的状态。
图中的③为消费端的监控，主要的监控对象是消费者，监控的指标是消费中堆积落后，阻塞，流量异常等维度的监控。
优选的，本发明扩展了RocketMQ的通信部分，使得能够支持查询RocketMQ中自定义的数据统计埋点，具体实现为扩展RocketMQ的netty通信处理器，增加支持自定义查询指令，以便能够在不修改RocketMQ核心源码的情况下实现通信支持，具体的类图如图17所示，图中的MQCloud端配置了SohuMQAdminExt、NettyRemotingClient以及拓展指令等内容，其中SohuMQAdminExt表示自定义命令执行客户端，NettyRemotingClient表示远程通讯模块，扩展指令中包含了多种指令，例如查询指令、传输指令等，扩展指令为实现与MQCloud的数据交互，增加的网络通讯指令。图中Broker端配置了AdminBrokerProcessor以及扩展方法，其中，AdminBrokerProcessor表示Broker端命令执行器，优选的，扩展方法为Broker端监控数据采集的方法。应用本发明提供的类图可以扩展RocketMQ的通信部分，可以在不修改RocketMQ核心源码的情况下实现通信支持，减少工作人员的工作量。
本发明基于三大模块形成的监控体系主要有以下改善点：覆盖全局组件监控，对消息的上下游进行监控预警，可及时得知任何异常的情况，且基于MQCloud可动态配置预警阈值，针对不同的业务进行定制化设置。监控体系覆盖整个生产消费流程，便于单个监控预警触发后能快速定位问题。例如，产生消费堆积后预警后，可以依据当前监控体系，判断出是生产突增还是消息消费阻塞造成的生产消费不均衡。
传统的监控方法只是监控了存储端的消息堆积的问题，而缺乏对存储的上下游进行监控，形成不了全链路的监控体系，并且该单一模式监控下触发预警之后也没办法快速定位到问题。本发明的监控方法覆盖了全链路，从生产端的各个监控维度，存储端的各个监控维度以及消费端的各个监控维度进行监控，全面覆盖整个RocketMQ的链路中的内容，本发明还扩展RocketMQ内部通信协议，从而使得MQCloud能够定时自动数据采集，预警分析，实现了故障的快速发现和报警。监控指标覆盖消息的上下游流程，能够帮助快速定位故障问题及相关的流程。
与图1所示方法相对应的，本发明实施例还提供一种RocketMQ监控装置，该装置用于支持图1所示的方法具体的实现。
参照图18，为本发明实施例提供的一种RocketMQ监控装置的结构示意图，具体说明如下所述：
确定单元201，用于确定待监控的RocketMQ和监控配置信息，所述RocketMQ包含生产端、存储端和消费端，所述监控配置信息中包含所述生产端的各个生产监控维度、所述存储端的各个存储监控维度以及所述消费端的各个消费监控维度；
第一监控单元202，用于对于每个所述生产监控维度，对所述生产端进行监控，以获取所述生产端在所述生产监控维度的生产监控数据，当所述生产监控维度存在预警需求时，对生产监控数据进行预警分析，并当所述生产端满足所述生产监控维度的预警条件时，生成预警信息；
第二监控单元203，用于对于每个所述存储监控维度，对所述存储端进行监控，以获取所述存储端在所述存储监控维度的存储监控数据，当所述存储监控维度存在预警需求时，对所述存储监控数据进行预警分析，当所述存储端满足所述存储监控维度的预警条件时，生成预警信息；
第三监控单元204，用于对于每个所述消费监控维度，对所述消费端进行监控，以获取所述消费端在所述消费监控维度的消费监控数据，当所述消费监控维度存在预警需求时，对所述消费监控数据进行预警分析，当所述消费端满足所述消费监控维度的预警条件时，生成预警信息。
在本发明提供的另一实施例中，该装置的各个生产监控维度包括生产流量监控维度、生产耗时监控维度以及生产失败监控维度。
在本发明提供的另一实施例中，该装置的各个存储监控维度包括主从同步状态监控维度、消息存储状态监控维度、服务器状态监控维度以及Broker/NameServer存活状态监控维度。
在本发明提供的另一实施例中，该装置的各个消费监控维度包括消费堆积监控维度、消费堵塞监控维度、消费流量统计监控维度、消费落后监控维度、订阅状态监控维度、偏移量错误监控维度以及死信消息监控维度。
在本发明提供的另一实施例中，该装置的第一监控单元，包括：
第一采集子单元，用于当所述生产监控维度为生产流量监控维度时，定时从所述存储端的每个消息存储模块中采集生产流量统计数据，所述生产流量监控维度存在预警需求；
第一确定子单元，用于确定历史流量统计数据，对所述历史流量统计数据和所述生产流量统计数据进行分析，得到流量变化幅度，当所述流量变化幅度大于预设变化幅度时，确定所述生产端满足所述生产监控维度的预警条件；
接收子单元，用于当所述生产监控维度为生产失败监控维度时，定时接收所述生产端发送的异常累计数据，所述生产失败监控维度存在预警需求；
第二确定子单元，用于基于所述异常累计数据确定异常比例，当所述异常比例大于预设异常比例时，确定所述生产端满足所述生产监控维度的预警条件。
在本发明提供的另一实施例中，该装置的第二监控单元，包括：
第二采集子单元，用于当所述存储监控维度为消息存储状态监控维度时，定时采集消息统计数据，所述消息存储状态监控维度存在预警需求；
处理子单元，用于对所述消息统计数据进行处理，得到第一分析数值和第二分析数值；
第三确定子单元，用于当所述第一分析数值大于预设的第一报警阈值，且所述第二分析数值大于预设的第二报警阈值时，确定所述存储端满足所述存储监控维度的预警条件；
第三采集子单元，用于当所述存储监控维度为服务器状态监控维度时，定时采集与所述服务器状态监控维度对应的各个服务器指标的指标数值；
第四确定子单元，用于基于每个所述服务器指标的指标数值和预设预警数值，确定各个所述服务器指标中是否存在超标的服务器指标；
第五确定子单元，用于当确定各个所述服务器指标中存在超标的服务器指标时，确定所述存储端满足所述存储监控维度的预警条件。
在本发明提供的另一实施例中，该装置的第三监控单元，包括：
第四采集子单元，用于当所述消费监控维度为消费堆积监控维度时，定时采集所述存储端的每个消息存储模块的消息偏移信息，所述消费堆积监控维度具有预警需求；
第六确定子单元，用于基于各个所述消息偏移信息，确定消息堆积量；
第七确定子单元，用于当所述消息堆积量大于预设的消息堆积阈值时，确定所述消费端满足所述消费堆积监控维度的预警条件；
第五采集子单元，用于当所述消费监控维度为死信消息监控维度时，定时采集预设的死信队列的信息数据，所述死信消息监控维度具有预警需求；
第八确定子单元，用于基于所述信息数据确定所述死信队列中是否存在死信消息，当所述死信队列中存在死信消息时，确定所述消费端满足所述消费堆积监控维度的预警条件。
本发明实施例还提供了一种存储介质，所述存储介质包括存储的指令，其中，在所述指令运行时控制所述存储介质所在的设备执行上述RocketMQ监控方法。
本发明实施例还提供了一种电子设备，其结构示意图如图19所示，具体包括存储器601，以及一个或者一个以上的指令602，其中一个或者一个以上指令602存储于存储器601中，且经配置以由一个或者一个以上处理器603执行所述一个或者一个以上指令602执行上述RocketMQ监控方法。
上述各个实施例的具体实施过程及其衍生方式，均在本发明的保护范围之内。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (4)

1.一种RocketMQ监控方法，其特征在于，包括：
确定待监控的RocketMQ和监控配置信息，所述RocketMQ包含生产端、存储端和消费端，所述监控配置信息中包含所述生产端的各个生产监控维度、所述存储端的各个存储监控维度以及所述消费端的各个消费监控维度；所述各个生产监控维度包括生产流量监控维度、生产耗时监控维度以及生产失败监控维度；所述各个存储监控维度包括主从同步状态监控维度、消息存储状态监控维度、服务器状态监控维度以及Broker/NameServer存活状态监控维度；所述各个消费监控维度包括消费堆积监控维度、消费堵塞监控维度、消费流量统计监控维度、消费落后监控维度、订阅状态监控维度、偏移量错误监控维度以及死信消息监控维度；
对于每个所述生产监控维度，对所述生产端进行监控，以获取所述生产端在所述生产监控维度的生产监控数据，当所述生产监控维度存在预警需求时，对所述生产监控数据进行预警分析，并当所述生产端满足所述生产监控维度的预警条件时，生成预警信息；
所述获取所述生产端在所述生产监控维度的生产监控数据，当所述生产监控维度存在预警需求时，对所述生产监控数据进行预警分析，包括：
当所述生产监控维度为所述生产流量监控维度时，定时从所述存储端的每个消息存储模块中采集生产流量统计数据，所述生产流量监控维度存在预警需求；确定历史流量统计数据，对所述历史流量统计数据和所述生产流量统计数据进行分析，得到流量变化幅度，当所述流量变化幅度大于预设变化幅度时，确定所述生产端满足所述生产监控维度的预警条件；
当所述生产监控维度为所述生产失败监控维度时，定时接收所述生产端发送的异常累计数据，所述生产失败监控维度存在预警需求；基于所述异常累计数据确定异常比例，当所述异常比例大于预设异常比例时，确定所述生产端满足所述生产监控维度的预警条件；
对于每个所述存储监控维度，对所述存储端进行监控，以获取所述存储端在所述存储监控维度的存储监控数据，当所述存储监控维度存在预警需求时，对所述存储监控数据进行预警分析，当所述存储端满足所述存储监控维度的预警条件时，生成预警信息；
所述获取所述存储端在所述存储监控维度的存储监控数据，当所述存储监控维度存在预警需求时，对所述存储监控数据进行预警分析，包括：
当所述存储监控维度为所述消息存储状态监控维度时，定时采集消息统计数据，所述消息存储状态监控维度存在预警需求；对所述消息统计数据进行处理，得到第一分析数值和第二分析数值；所述第一分析数值为所述消息统计数据中的最大耗时；所述第二分析数值为从所述消息统计数据的各个耗时中选择的目标耗时，其中，所述目标耗时能使所述消息统计数据中小于或等于目标耗时的数量与耗时总数量的比值达到预设比值，或能使所述消息统计数据中大于或等于目标耗时的数量与耗时总数量的比值达到预设比值；当所述第一分析数值大于预设的第一报警阈值，且所述第二分析数值大于预设的第二报警阈值时，确定所述存储端满足所述存储监控维度的预警条件；
当所述存储监控维度为所述服务器状态监控维度时，定时采集与所述服务器状态监控维度对应的各个服务器指标的指标数值；基于每个所述服务器指标的指标数值和预设预警数值，确定各个所述服务器指标中是否存在超标的服务器指标；当确定各个所述服务器指标中存在超标的服务器指标时，确定所述存储端满足所述存储监控维度的预警条件；
对于每个所述消费监控维度，对所述消费端进行监控，以获取所述消费端在所述消费监控维度的消费监控数据，当所述消费监控维度存在预警需求时，对所述消费监控数据进行预警分析，当所述消费端满足所述消费监控维度的预警条件时，生成预警信息；
所述获取所述消费端在所述消费监控维度的消费监控数据，当所述消费监控维度存在预警需求时，对所述消费监控数据进行预警分析，包括：
当所述消费监控维度为所述消费堆积监控维度时，定时采集所述存储端的每个消息存储模块的消息偏移信息，所述消费堆积监控维度具有预警需求；基于各个所述消息偏移信息，确定消息堆积量；当所述消息堆积量大于预设的消息堆积阈值时，确定所述消费端满足所述消费堆积监控维度的预警条件；
当所述消费监控维度为所述死信消息监控维度时，定时采集预设的死信队列的信息数据，所述死信消息监控维度具有预警需求；基于所述信息数据确定所述死信队列中是否存在死信消息，当所述死信队列中存在所述死信消息时，确定所述消费端满足所述消费堆积监控维度的预警条件。
2.一种RocketMQ监控装置，其特征在于，包括：
确定单元，用于确定待监控的RocketMQ和监控配置信息，所述RocketMQ包含生产端、存储端和消费端，所述监控配置信息中包含所述生产端的各个生产监控维度、所述存储端的各个存储监控维度以及所述消费端的各个消费监控维度；所述各个生产监控维度包括生产流量监控维度、生产耗时监控维度以及生产失败监控维度；所述各个存储监控维度包括主从同步状态监控维度、消息存储状态监控维度、服务器状态监控维度以及Broker/NameServer存活状态监控维度；所述各个消费监控维度包括消费堆积监控维度、消费堵塞监控维度、消费流量统计监控维度、消费落后监控维度、订阅状态监控维度、偏移量错误监控维度以及死信消息监控维度；
第一监控单元，用于对于每个所述生产监控维度，对所述生产端进行监控，以获取所述生产端在所述生产监控维度的生产监控数据，当所述生产监控维度存在预警需求时，对所述生产监控数据进行预警分析，并当所述生产端满足所述生产监控维度的预警条件时，生成预警信息；
所述获取所述生产端在所述生产监控维度的生产监控数据，当所述生产监控维度存在预警需求时，对所述生产监控数据进行预警分析，包括：
当所述生产监控维度为所述生产流量监控维度时，定时从所述存储端的每个消息存储模块中采集生产流量统计数据，所述生产流量监控维度存在预警需求；确定历史流量统计数据，对所述历史流量统计数据和所述生产流量统计数据进行分析，得到流量变化幅度，当所述流量变化幅度大于预设变化幅度时，确定所述生产端满足所述生产监控维度的预警条件；
当所述生产监控维度为所述生产失败监控维度时，定时接收所述生产端发送的异常累计数据，所述生产失败监控维度存在预警需求；基于所述异常累计数据确定异常比例，当所述异常比例大于预设异常比例时，确定所述生产端满足所述生产监控维度的预警条件；
第二监控单元，用于对于每个所述存储监控维度，对所述存储端进行监控，以获取所述存储端在所述存储监控维度的存储监控数据，当所述存储监控维度存在预警需求时，对所述存储监控数据进行预警分析，当所述存储端满足所述存储监控维度的预警条件时，生成预警信息；
所述获取所述存储端在所述存储监控维度的存储监控数据，当所述存储监控维度存在预警需求时，对所述存储监控数据进行预警分析，包括：
当所述存储监控维度为所述消息存储状态监控维度时，定时采集消息统计数据，所述消息存储状态监控维度存在预警需求；对所述消息统计数据进行处理，得到第一分析数值和第二分析数值；所述第一分析数值为所述消息统计数据中的最大耗时；所述第二分析数值为从所述消息统计数据的各个耗时中选择的目标耗时，其中，所述目标耗时能使所述消息统计数据中小于或等于目标耗时的数量与耗时总数量的比值达到预设比值，或能使所述消息统计数据中大于或等于目标耗时的数量与耗时总数量的比值达到预设比值；当所述第一分析数值大于预设的第一报警阈值，且所述第二分析数值大于预设的第二报警阈值时，确定所述存储端满足所述存储监控维度的预警条件；
当所述存储监控维度为所述服务器状态监控维度时，定时采集与所述服务器状态监控维度对应的各个服务器指标的指标数值；基于每个所述服务器指标的指标数值和预设预警数值，确定各个所述服务器指标中是否存在超标的服务器指标；当确定各个所述服务器指标中存在超标的服务器指标时，确定所述存储端满足所述存储监控维度的预警条件；
第三监控单元，用于对于每个所述消费监控维度，对所述消费端进行监控，以获取所述消费端在所述消费监控维度的消费监控数据，当所述消费监控维度存在预警需求时，对所述消费监控数据进行预警分析，当所述消费端满足所述消费监控维度的预警条件时，生成预警信息；
所述获取所述消费端在所述消费监控维度的消费监控数据，当所述消费监控维度存在预警需求时，对所述消费监控数据进行预警分析，包括：
当所述消费监控维度为所述消费堆积监控维度时，定时采集所述存储端的每个消息存储模块的消息偏移信息，所述消费堆积监控维度具有预警需求；基于各个所述消息偏移信息，确定消息堆积量；当所述消息堆积量大于预设的消息堆积阈值时，确定所述消费端满足所述消费堆积监控维度的预警条件；
当所述消费监控维度为所述死信消息监控维度时，定时采集预设的死信队列的信息数据，所述死信消息监控维度具有预警需求；基于所述信息数据确定所述死信队列中是否存在死信消息，当所述死信队列中存在所述死信消息时，确定所述消费端满足所述消费堆积监控维度的预警条件。
3.一种存储介质，其特征在于，所述存储介质包括存储的指令，其中，在所述指令运行时控制所述存储介质所在的设备执行如权利要求1所述的RocketMQ监控方法。
4.一种电子设备，其特征在于，包括存储器，以及一个或者一个以上的指令，其中一个或者一个以上指令存储于存储器中，且经配置以由一个或者一个以上处理器执行如权利要求1所述的RocketMQ监控方法。
CN202211053264.4A 2022-08-31 2022-08-31 RocketMQ监控方法及装置、存储介质及电子设备 Active CN115134262B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211053264.4A CN115134262B (zh) 2022-08-31 2022-08-31 RocketMQ监控方法及装置、存储介质及电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211053264.4A CN115134262B (zh) 2022-08-31 2022-08-31 RocketMQ监控方法及装置、存储介质及电子设备

Publications (2)

Publication Number Publication Date
CN115134262A CN115134262A (zh) 2022-09-30
CN115134262B true CN115134262B (zh) 2023-01-06

Family

ID=83387999

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211053264.4A Active CN115134262B (zh) 2022-08-31 2022-08-31 RocketMQ监控方法及装置、存储介质及电子设备

Country Status (1)

Country Link
CN (1) CN115134262B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115333978A (zh) * 2022-10-11 2022-11-11 中化现代农业有限公司 一种数据监控方法以及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110213068A (zh) * 2018-03-06 2019-09-06 腾讯科技（深圳）有限公司 一种消息中间件的监控方法及相关设备
CN111752795A (zh) * 2020-06-18 2020-10-09 多加网络科技(北京)有限公司 一种全流程监控报警平台及其方法
CN112181776A (zh) * 2020-09-30 2021-01-05 银盛支付服务股份有限公司 RocketMQ监控和告警通知方法、系统、电子设备及存储介质
WO2021180025A1 (zh) * 2020-03-13 2021-09-16 北京金山云网络技术有限公司 一种消息处理方法、装置、电子设备及介质
CN114253748A (zh) * 2021-12-27 2022-03-29 北京宇信科技集团股份有限公司 一种消息处理系统和消息处理方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110213068A (zh) * 2018-03-06 2019-09-06 腾讯科技（深圳）有限公司 一种消息中间件的监控方法及相关设备
WO2021180025A1 (zh) * 2020-03-13 2021-09-16 北京金山云网络技术有限公司 一种消息处理方法、装置、电子设备及介质
CN111752795A (zh) * 2020-06-18 2020-10-09 多加网络科技(北京)有限公司 一种全流程监控报警平台及其方法
CN112181776A (zh) * 2020-09-30 2021-01-05 银盛支付服务股份有限公司 RocketMQ监控和告警通知方法、系统、电子设备及存储介质
CN114253748A (zh) * 2021-12-27 2022-03-29 北京宇信科技集团股份有限公司 一种消息处理系统和消息处理方法

Also Published As

Publication number Publication date
CN115134262A (zh) 2022-09-30

Similar Documents

Publication Publication Date Title
CN105718351B (zh) 一种面向Hadoop集群的分布式监控管理系统
US10348809B2 (en) Naming of distributed business transactions
US20030135382A1 (en) Self-monitoring service system for providing historical and current operating status
CN109660380A (zh) 服务器运行状态的监控方法、平台、系统及可读存储介质
US20190163546A1 (en) Correlating failures with performance in application telemetry data
CN106487574A (zh) 自动化运行维护监测系统
CN112965874B (zh) 一种可配置的监控告警方法及系统
CN110309030A (zh) 基于ELK和Zabbix的日志分析监控系统和方法
CN106161085B (zh) 消息总线的监控系统及方法
CN106940677A (zh) 一种应用日志数据告警方法及装置
CN115134262B (zh) RocketMQ监控方法及装置、存储介质及电子设备
CN112699007A (zh) 监控机器性能的方法、系统、网络设备及存储介质
CN105808415A (zh) 一种基于云计算环境的业务运行状态评估方法及其装置
CN111124609B (zh) 数据采集方法、装置、数据采集设备及存储介质
CN111538563A (zh) 一种对Kubernetes的事件分析方法及装置
CN101989931A (zh) 一种运维告警处理方法和装置
CN109783311A (zh) 断点行为的监控处理方法、装置、设备及可读存储介质
CN112596975A (zh) 对网络设备进行监控处理的方法、系统、设备和存储介质
CN114356499A (zh) Kubernetes集群告警根因分析方法及装置
CN112039726A (zh) 一种内容分发网络cdn设备的数据监控方法及系统
CN114328124A (zh) 用于业务监控的方法以及装置、存储介质、电子装置
CN109032904A (zh) 被监控、管理服务器及数据获取、分析方法和管理系统
CN113722187B (zh) 一种面向微服务架构的服务监控系统
CN114154035A (zh) 一种动环监控的数据处理系统
KR20180015027A (ko) 데이터 분산 서비스 응용 시스템 오류 자동 알림 장치 및 방법

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant