一种消息队列的监控方法及装置与流程

1.本技术主要涉及数据监控领域，特别涉及一种消息队列的监控方法及装置。


背景技术：

2.消息队列(message queue，mq)，是基础数据结构中“先进先出”的一种数据结构，把要传输的数据(消息)放在队列中，用队列机制来实现消息传递。mq软件，即消息队列中间件，采用消息队列进行通信传输，作为分布式系统中的重要组件，可提供跨平台的节点间消息稳定传输功能。
3.在mq软件的日常运维中，需要对消息队列的队列、通道、私信、状态和日志等配置项进行监控。在配置项发生新增和调整时，也需要相应地对监控项进行修改；目前的监控系统往往采用手动调整监控项的方式，给运维工作带来了额外的工作开销；此外，对监控项的手动修改也可能会产生纰漏，影响监控系统的稳定性。


技术实现要素：

4.有鉴于此，本技术提供了一种消息队列的监控方法及装置，能够降低运维压力，无需手动调整监控项。
5.一方面，本技术实施例提供了一种消息队列的监控方法，所述方法包括：
6.获取目标配置项的路径信息，并将所述目标配置项的路径信息写入配置文件，所述目标配置项包含在所述消息队列的配置项中；
7.根据所述配置文件中的目标配置项的路径信息，监测所述目标配置项的配置信息是否出现异常。
8.可选的，所述方法还包括：
9.若所述目标配置项的配置信息出现异常，则，确定所述出现异常的目标配置项对应的过滤条件是否满足；
10.若所述出现异常的目标配置项对应的过滤条件满足，则不进行报警；
11.若所述出现异常的目标配置项对应的过滤条件不满足，则进行报警。
12.可选的，所述过滤条件包括：
13.异常次数不大于预设阈值，和/或，
14.异常时间段处于预设时间段。
15.可选的，所述消息队列的配置项包括：所述消息队列的队列管理器，通道，队列深度和运行日志。
16.可选的，所述方法还包括：
17.若所述目标配置项的配置信息不出现异常，则，休眠一定时间，再继续监测所述目标配置项的配置信息是否出现异常。
18.可选的，所述获取目标配置项的路径信息包括：
19.获取所述消息队列的配置项的路径信息；
20.从所述消息队列的配置项的路径信息中，筛选出所述目标配置项的路径信息。
21.另一方面，本技术实施例还提供了一种消息队列的监控装置，所述装置包括：
22.初始化模块，用于获取目标配置项的路径信息，并将所述目标配置项的路径信息写入配置文件，所述目标配置项包含在所述消息队列的配置项中；
23.监控模块，用于根据所述配置文件中的目标配置项的路径信息，监测所述目标配置项的配置信息是否出现异常。
24.可选的，所述装置还包括：
25.报警过滤模块，用于若所述目标配置项的配置信息出现异常，则，确定所述出现异常的目标配置项对应的过滤条件是否满足；
26.若所述出现异常的目标配置项对应的过滤条件满足，则不进行报警；
27.若所述出现异常的目标配置项对应的过滤条件不满足，则进行报警。
28.另一方面，本技术实施例还提供了一种设备，所述设备包括：处理器和存储器；
29.所述存储器，用于存储指令；
30.所述处理器，用于执行所述存储器中的所述指令，执行以上方面所述的方法。
31.另一方面，本技术实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有程序代码或指令，当其在计算机上运行时，使得所述计算机执行以上方面所述的方法。
32.由此可见，本技术实施例有如下有益效果：
33.本技术通过获取目标配置项的路径信息，并将其写入配置文件，从而自动获取需要被监控的消息队列的配置项；再根据配置文件中目标配置项的路径信息，监测目标配置项的配置信息是否出现异常，从而对目标配置项进行自动监控，减少了运维工作的工作量，实现了对目标配置项的自动获取和自动监控，有利于监控的稳定性。
附图说明
34.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
35.图1为本技术实施例提供的一种消息队列的监控方法的方法流程图；
36.图2为本技术实施例提供的一种写入配置文件的流程图；
37.图3为本技术实施例提供的一种监控消息队列的具体流程图；
38.图4为本技术实施例提供的一种消息队列的监控装置的装置示意图。
具体实施方式
39.为使本技术的上述目的、特征和优点能够更加明显易懂，下面结合附图对本技术的具体实施方式做详细的说明。
40.在下面的描述中阐述了很多具体细节以便于充分理解本技术，但是本技术还可以采用其它不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本技术内涵的情况下做类似推广，因此本技术不受下面公开的具体实施例的限制。
41.目前，应用于mq软件的监控系统，主要存在以下问题：
42.(1)监控项无法跟随配置项的调整而自动调整，运维成本较高；
43.(2)对监控项的报警策略较为固定，难以适应多种运行环境下的不同要求，在一些不需要报警的情况下也进行报警。
44.为了解决上述问题，本技术提供了一种消息队列的监控方法及装置，通过自动获取需要被监控的消息队列的配置项，并对目标配置项进行自动监控，从而减少了运维工作的工作量，有利于监控的稳定性。
45.为了便于理解，下面结合附图对本技术实施例提供的一种消息队列的监控方法及装置进行详细的说明。
46.参考图1所示，为本技术实施例提供的一种消息队列的监控方法的方法流程图，该方法可以包括以下步骤：
47.s101：获取目标配置项的路径信息，并将所述目标配置项的路径信息写入配置文件。
48.其中，所述目标配置项包含在所述消息队列的配置项中。
49.本技术实施例中，目标配置项即需要被监控的消息队列的配置项。目标配置项的路径信息为目标配置项对应的路径，如名称、端口等。具体地，目标配置项的路径信息可以通过dspmq、display等命令自动匹配获取，在此不对目标配置项的路径信息的具体获取方式作任何限定。
50.本技术实施例通过获取目标配置项的路径信息并将其写入配置文件，从而能够根据配置文件中目标配置项的路径信息，获取目标配置项的配置信息；在目标配置项的配置信息更新时，无需手动更新需要被监控的配置项，只需要根据目标配置项的路径，即能获取最新的目标配置项的配置信息；当目标配置项增加或减少时，也无需重新对需要被监控的配置项进行设置，只需要重新获取目标配置项的路径信息，并同步更新配置文件中的目标配置项，即可对需要被监控的配置项进行调整。上述自动获取目标配置项的路径信息并写入配置文件的步骤，通过自动发现目标配置项，提高了监控的自动化程度。
51.在一种可能的实现方式中，所述消息队列的配置项包括：所述消息队列的队列管理器，通道，队列深度和运行日志。
52.本技术实施例中，消息队列的配置项主要可以分为状态和日志等。其中，状态可以包括队列管理器、通道、队列深度等配置项的状态；日志可以包括运行日志等配置项的内容。
53.在一种可能的实现方式中，所述获取目标配置项的路径信息包括：
54.获取所述消息队列的配置项的路径信息；
55.从所述消息队列的配置项的路径信息中，筛选出所述目标配置项的路径信息。
56.本技术实施例中，目标配置项的路径信息是从消息队列的配置项的路径信息中筛选得到的。具体地，和目标配置项对应的路径信息可以包括：队列管理器名称，队列名称，通道名称和日志路径等。
57.本技术实施例中，在获取目标配置项的路径信息之前，还可以对是否存在mq进程进行判断。若不存在mq进程，则无需对目标配置项的路径信息，直接结束流程。参考图2，本技术实施例提供的一种写入配置文件的流程图。如图2所示，写入配置文件可以包括以下步
骤：
58.判断是否存在mq进程，若否，则结束流程；
59.若是，则：
60.获取队列管理器名称、队列名称、通道名称等目标配置项的路径信息；
61.将目标配置项的路径信息写入配置文件，结束流程。
62.需要说明的是，上述写入配置文件的流程图仅为便于说明提供的一种可能的实现方式，本技术实施例不对具体获取哪些目标配置项和获取不同目标配置项的先后顺序作任何限定。
63.s102：根据所述配置文件中的目标配置项的路径信息，监测所述目标配置项的配置信息是否出现异常。
64.本技术实施例中，通过根据配置文件中的目标配置项的路径信息，能够自动获取目标配置项的配置信息，从而监测目标配置项的配置信息是否出现异常。
65.本技术实施例中，目标配置项主要可以分为状态类的目标配置项和日志类的目标配置项，等等。
66.其中，对于状态类的目标配置项，目标配置项的配置信息可以包括目标配置项的状态值，如，队列管理器的状态、通道的运行状态和队列深度等。具体地，对状态类的目标配置项的配置信息的监测则可以包括监测目标配置项的状态值是否出现异常，例如，监测队列管理器的状态是否异常、监测通道的运行状态是否异常和监测队列深度是否超过阈值等。
67.对于日志类的目标配置项，目标配置项的配置信息则可以包括运行日志的内容等。具体地，对日志类的目标配置项是否出现异常的监测，可以包括将消息队列的日志内容同配置文件中的报错关键字进行匹配，确定运行日志的内容是否报错。
68.一种可能的实现方式中，所述方法还包括：
69.若所述目标配置项的配置信息不出现异常，则，休眠一定时间，再继续监测所述目标配置项的配置信息是否出现异常。
70.本技术实施例中，如果在一轮监测中，所有的目标配置项均不出现异常，则，休眠一定时间，再继续下一轮监测。具体地，可以休眠3分钟后再进行下一轮监测；在一种可能的实现方式中，若消息队列发生调整的次数较为频繁，则在每一轮监测之后，可以重新获取目标配置项的路径信息，并相应地更新配置文件，从而及时对需要被监控的配置项进行调整和更新；而在消息队列发生调整的次数较为不频繁的情况下，也可以对重新获取目标配置项的路径信息的周期进行设置，在此不作任何限定。
71.一种可能的实现方式中，所述方法还包括：
72.若所述目标配置项的配置信息出现异常，则，确定所述出现异常的目标配置项对应的过滤条件是否满足；
73.若所述出现异常的目标配置项对应的过滤条件满足，则不进行报警；
74.若所述出现异常的目标配置项对应的过滤条件不满足，则进行报警。
75.本技术实施例中，若目标配置项的配置信息出现异常，并不都会引起报警。在一些运行环境下，当目标配置项的配置信息出现异常时，可能存在无需进行维护的情况，如，在夜间批量发送消息时，队列深度可能超过阈值，但此时无需进行报警。因此，本技术实施例
中，针对每个目标配置项，可以自定义有对应的过滤条件，只有当过滤条件满足时，才进行报警。若过滤条件不满足，则继续进行监测。
76.本技术实施例提供了一种监控消息队列的具体流程图，如图3所示。根据图3，监控消息队列可以包括以下流程：
77.判断队列管理器、通道、队列深度和运行日志等目标配置项是否异常；
78.若所有目标配置项均不出现异常，则休眠3分钟，再重新判断目标配置项是否异常；
79.若任意一项目标配置项出现异常，则判断是否满足出现异常的目标配置项对应的过滤条件，若满足，则继续进行下一项目标配置项的判断；
80.若不满足，则报警，并结束流程。
81.本技术实施例中，报警之后，可以根据报警信息，及时进行运维处理。通过根据判断是否满足过滤条件确定是否报警，有利于提升报警的有效性，能够实现对需要运维处理的异常情况进行精准报警，降低了对消息队列运行维护的压力和成本。
82.一种可能的实现方式中，所述过滤条件包括：
83.异常次数不大于预设阈值，和/或，
84.异常时间段处于预设时间段。
85.本技术实施例中，过滤条件可以为异常次数不大于预设阈值，或异常时间段处于预设时间段，也可以既考虑异常次数，又考虑异常时间段。具体地，例如，通道状态对应的过滤条件可以为异常次数不超过10次，也可以为异常时间段为凌晨1:00-5:00，也可以为凌晨1:00-5:00并且异常次数不超过10次。本技术实施例中，还可以选取其他的过滤条件，在此不作任何限定。
86.本技术实施例中，通过按照时间段、异常次数等自定义的过滤条件进行报警过滤，并且过滤条件是与目标配置项相对应的，能够根据运行环境进行精准报警，提升了报警的有效性。
87.基于以上消息队列的监控方法，本技术实施例还提供了一种消息队列的监控装置，参照图4所示，该图为本技术实施例提供的一种消息队列的监控装置的装置示意图，该消息队列的监控装置可以包括：
88.初始化模块201，用于获取目标配置项的路径信息，并将所述目标配置项的路径信息写入配置文件，所述目标配置项包含在所述消息队列的配置项中；
89.监控模块202，用于根据所述配置文件中的目标配置项的路径信息，监测所述目标配置项的配置信息是否出现异常。
90.一种可能的实现方式中，所述装置还包括：
91.报警过滤模块，用于若所述目标配置项的配置信息出现异常，则，确定所述出现异常的目标配置项对应的过滤条件是否满足；
92.若所述出现异常的目标配置项对应的过滤条件满足，则不进行报警；
93.若所述出现异常的目标配置项对应的过滤条件不满足，则进行报警。
94.一种可能的实现方式中，所述过滤条件包括：
95.异常次数不大于预设阈值，和/或，
96.异常时间段处于预设时间段。
97.一种可能的实现方式中，所述消息队列的配置项包括：所述消息队列的队列管理器，通道，队列深度和运行日志。
98.一种可能的实现方式中，所述装置还包括：
99.休眠模块，用于若所述目标配置项的配置信息不出现异常，则，休眠一定时间，再继续监测所述目标配置项的配置信息是否出现异常。
100.一种可能的实现方式中，所述初始化模块包括：
101.筛选子模块，用于获取所述消息队列的配置项的路径信息；
102.从所述消息队列的配置项的路径信息中，筛选出所述目标配置项的路径信息。
103.基于以上消息队列的监控方法，本技术实施例还提供了一种设备，该设备可以包括：处理器和存储器；
104.存储器，用于存储指令；
105.处理器，用于执行所述存储器中的所述指令，执行上文所述的消息队列的监控方法。
106.基于以上消息队列的监控方法，本技术实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有程序代码或指令，当其在计算机上运行时，使得所述计算机执行上文所述的消息队列的监控方法。
107.需要说明的是，本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统或装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
108.应当理解，在本技术中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“a和/或b”可以表示：只存在a，只存在b以及同时存在a和b三种情况，其中a，b可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。
109.还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
110.结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。
111.对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本技术。
对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本技术的精神或范围的情况下，在其它实施例中实现。因此，本技术将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。