软件运行状态的监控方法和装置与流程

1.本技术涉及计算机技术领域，尤其涉及一种软件运行状态的监控方法和装置。


背景技术：

2.消息中间件是基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统，可以提供跨平台的节点间稳定的点对点消息传输能力，例如，tlq和mq是目前广泛使用的消息中间件产品。
3.消息中间件在运行过程中，可以对运行过程中出现的各事件以日志的方式进行记录，例如，消息中间件队列管理器的活动状态、消息中间件发送通道的活动状态以及消息中间件队列的消息深度等。
4.若消息中间件在运行过程中出现问题，例如，消息中间件队列管理器处于非活动状态，消息中间件缺少相应的告警提示功能，用户难以及时发现问题，导致用户的使用体验较差。


技术实现要素：

5.本技术实施例提供一种软件运行状态的监控方法和装置，通过对软件运行过程中的异常状态进行识别和预警，可以以使用户及时对出现的异常状态进行维护，提高软件的消息传输效率。
6.第一方面，本技术实施例提供一种软件运行状态的监控方法，包括：
7.在确定软件的进程存在时，从配置文件中获取所述软件的监控指标，所述监控指标包括所述第一队列管理器标识、消息队列的第一队列标识和通道的第一通道标识；
8.根据所述监控指标获取所述软件的运行状态，所述运行状态包括队列管理器的状态、消息队列的消息深度、接收通道的状态和发送通道的状态，所述消息深度用于指示消息队列中消息的数量；
9.确定所述运行状态为异常状态时，显示异常告警信息。
10.可选的，若满足如下至少一种条件，则确定所述运行状态为异常状态：
11.所述队列管理器的状态为非活动状态，且所述队列管理器非预设队列管理器；
12.所述消息深度大于预设值，且接收所述消息的ip地址非预设ip地址；
13.所述接收通道的状态为非活动状态，且所述接收通道的ip地址非预设ip地址；
14.所述发送通道的状态为断开状态、所述发送通道不为域名通道，且所述接收所述消息的ip地址不为预设ip地址。
15.可选的，在确定所述运行状态为正常状态时，所述方法还包括：
16.在第一预设时间后，重新获取所述发送通道的状态；
17.若所述发送通道的状态为连接状态，则确定获取所述发送通道的状态的次数；
18.若所述次数小于预设次数，则重复执行第一预设时间后，重新获取所述发送通道的状态的步骤，直至所述次数大于预设次数；
19.在所述次数大于预设次数后，获取当前消息队列的第二队列标识和当前通道的第二通道标识，并记录在队列信息表中；
20.根据所述队列信息表更新所述配置文件。
21.可选的，所述根据所述队列信息表更新所述配置文件，包括：
22.将所述队列信息表中第二队列标识和第二通道标识与所述配置文件中的第一队列标识和第一通道标识的进行匹配；
23.若一致，则重新执行获取所述软件的运行状态的步骤；
24.若不一致，则在服务器上获取第二队列管理器标识，根据所述第二队列管理器标识和所述队列信息表更新所述配置文件。
25.可选的，所述发送通道的状态为断开状态，若所述发送通道为域名通道，所述方法还包括：
26.对所述发送通道的域名进行解析，获得解析结果；
27.若所述解析结果中的ip地址与预设ip地址相同，刷新所述软件的dns缓存，执行获取所述发送通道的状态的次数的步骤。
28.可选的，若所述解析结果中的ip地址与预设ip地址不同，所述方法还包括：
29.在所述第一预设时间后，重新获取所述发送通道的状态，以确定所述发送通道是否重连接成功；
30.若所述发送通道重连接成功，执行获取所述发送通道的状态的次数的步骤；
31.若所述发送通道的状态为断开状态，重启所述软件。
32.可选的，所述软件为消息中间件软件。
33.第二方面，本技术实施例提供一种软件运行状态的监控装置，包括：
34.第一获取模块，用于在确定软件的进程存在时，从配置文件中获取所述软件的监控指标，所述监控指标包括所述第一队列管理器标识、消息队列的第一队列标识和通道的第一通道标识；
35.第二获取模块，用于根据所述监控指标获取所述软件的运行状态，所述运行状态包括队列管理器的状态、消息队列的消息深度、接收通道的状态和发送通道的状态，所述消息深度用于指示消息队列中消息的数量；
36.确定模块，用于确定所述运行状态为异常状态时，显示异常告警信息。
37.可选的，本技术实施例提供软件运行状态的监控装置可以执行第一方面任一项所述的软件运行状态的监控方法。
38.第三方面，本技术提供一种电子设备，包括：存储器和处理器；
39.存储器用于存储计算机指令；处理器用于运行存储器存储的计算机指令实现第一方面中任一项的方法。
40.第四方面，本技术提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行以实现第一方面中任一项的方法。
41.第五方面，本技术提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现第一方面中任一项的方法。
42.本技术实施例提供的软件运行状态的监控方法和装置，通过在确定软件的进程存在时，从配置文件中获取软件的监控指标，监控指标包括第一队列管理器标识、消息队列的
第一队列标识和通道的第一通道标识，根据监控指标获取软件的运行状态，运行状态包括队列管理器的状态、消息队列的消息深度、接收通道的状态和发送通道的状态，消息深度用于指示消息队列中消息的数量，确定软件的运行状态为异常状态时，显示异常告警信息。根据获取的监控指标实现了对软件运行状态的监控，并在出现异常状态时进行告警，以使用户及时对出现的问题进行维护，提高软件的消息传输效率。
附图说明
43.图1为本技术实施例提供的场景示意图；
44.图2为本技术实施例提供的软件运行状态的监控方法的流程示意图一；
45.图3为本技术实施例提供的软件运行状态的监控方法的流程示意图二；
46.图4为本技术实施例提供的软件运行状态的监控方法的示意图；
47.图5为本技术实施例提供的软件运行状态的监控装置的结构示意图；
48.图6为本技术实施例提供的软件运行状态的监控电子设备的结构示意图。
具体实施方式
49.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
50.在本技术的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分，并不对其先后顺序进行限定。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。
51.需要说明的是，本技术实施例中，“示例性的”或者“例如”等词用于表示例子、例证或说明。本技术中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
52.消息中间件也可以称消息队列，是指用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程的通信。
53.消息队列已经逐渐成为企业it系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步远程过程调用(remote procedure call，rpc)的主要手段之一，常用的消息中间件软件包括东方通(tonglinkq，tlq)、消息队列(message queue，mq)等。
54.消息中间件在运行过程中，可以对运行过程中各事件以日志的方式进行记录，消息中间件中的队列管理器的活动状态、消息中间件发送通道的活动状态以及消息中间件队列消息的深度等。
55.若消息中间件在运行过程中出现问题，例如，消息中间件队列管理器处于非活动状态，接收消息的节点异常等，消息中间件缺少相应的告警提示功能，用户难以及时发现问
题，导致消息传递的效率低，用户的使用体验较差。
56.有鉴于此，本技术实施例提供一种软件运行状态的监控方法和装置，通过对消息中间件软件运行过程中各队列与通道的状态进行监控，在消息中间件软件运行出现问题时，生成告警信息，对用户进行提示，以使用户及时发现问题并处理，可以提高消息的传递效率。
57.下面以具体地实施例对本技术的技术方案以及本技术的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以独立实现，也可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。
58.图1为本技术实施例的应用场景示意图，如图1所示，包括服务器101、消息中间件102和监控装置103。
59.其中，消息中间件102运行在服务器101上，可以将服务器101产生的消息发送至其他服务器中。
60.监控装置103可以为服务器101的处理器，通过与消息中间件102的交互来获取消息中间件102在运行过程中的状态，在消息中间件102运行出现问题时，生成对应的告警信息，并显示在服务器对应的显示单元中，以对用户进行提示。
61.本技术实施例中，监控装置103进行监控消息中间件102运行过程中的状态时，可以通过执行对应的计算机程序来实现。
62.示例性的，监控装置103可以执行用户存储于服务器101中的监控脚本中的查询指令，来实现对消息中间件102运行过程中的状态进行监控，并在消息中间件102运行出现问题时，生成对应的告警信息，并将该告警信息推送至服务器的显示单元。
63.上面对本技术实施例提供的软件运行状态的监控方法的应用场景进行了简单说明，下面以应用于图1中所示的监控装置为例，对本技术实施例提供的软件运行状态的监控方法如何解决上述问题进行详细说明。
64.为了便于理解和描述，后续行文中将以tlq指代上述软件，以处理器指代上述监控装置。
65.图2为本技术实施例提供的软件运行状态的监控方法的流程示意图一，如图2所示，包括如下步骤：
66.s201、在确定软件的进程存在时，从配置文件中获取软件的监控指标，监控指标包括第一队列管理器标识、消息队列的第一队列标识和通道的第一通道标识。
67.本技术实施例中，监控指标是指tlq运行过程中需要监控的各目标以及各目标对应的状态或者数值。
68.第一队列管理器标识是指用于确定tlq中需要监控的队列管理器的标识，消息队列的第一队列标识是指用于确定tlq中需要监控的消息队列的标识，通道的第一通道标识是指用于确定tlq中需要监控的通道的标识。
69.本技术实施例中，队列管理器是为tlq中提供消息传递服务的程序，消息队列是指在消息的传输过程中保存消息的容器，通道是指用于连接两个需要传递消息的节点之间的路径，tlq中可以包括多个队列管理器，一个队列管理器中可以包括多个消息队列，一个消息队列对应一个消息通道。
70.本技术实施例中，配置文件是指存储处理器执行监控tlq运行状态时的必要的配
置参数和初始设置的文件，配置文件可以为用户进行编写存储于服务器中的，也可以为处理器根据tlq软件生成的。
71.本技术实施例中，处理器可以在服务器的运行进行中，根据tlq的名称确定tlq进程存在时，从配置文件中获取tlq的监控指标。
72.示例性的，处理器在执行监控脚本时，在确定tlq进程存在时，可以根据监控脚本中配置文件的标识或者关键字，在监控脚本的同级目录中查询对应的配置文件，对配置文件进行解析获取配置文件中tlq的监控指标。
73.可选的，若监控脚本的同级目录中不存在配置文件，处理器可以通过查询指令查询tlq中当前运行的队列管理器、消息队列和通道，将上述三种作为需要进行监控的监控指标，并生成配置文件，写入监控脚本的同级目录中。其中，查询指令可以为用户写入监控脚本中的指令，通过查询指令在tlq对应的查询接口查询tlq中当前运行的队列管理器、消息队列和通道。
74.s202、根据监控指标获取软件的运行状态，运行状态包括队列管理器的状态、消息队列的消息深度、接收通道的状态和发送通道的状态，消息深度用于指示消息队列中消息的数量。
75.本技术实施例中，队列管理器的状态包括活动状态和非活动状态，消息队列的消息深度是指该消息队列中存储的消息的数量，接收通道的状态是指接收通道的监听状态，包括活动状态和非活动状态，发送通道的状态包括连接状态和断开状态，其中，连接状态又包括连接运行态和连接空闲态。连接运行态是指发送通道正在传输消息，连接空闲态是指发送通道暂时无需要传递的消息。
76.本技术实施例中，处理器获取到tlq的监控指标时，可以根据监控指标来获取对应的tlq的运行状态。
77.示例性的，处理器可以根据第一队列管理器标识，在tlq的查询接口中查询tlq中需要监控的队列管理器的状态，根据消息队列的第一队列标识来查询tlq中需要监控的消息队列中各消息队列的消息深度，根据通道的第一通道标识来查询tlq中需要监控的接收通道的状态和发送通道的状态。
78.s203、确定软件的运行状态为异常状态时，显示异常告警信息。
79.本技术实施例中，tlq的运行状态为异常状态是指队列管理器的状态为非活动状态、消息队列的消息深度大于预设值、接收通道的状态为非活动状态、发送通道的状态为断开状态中的任一种时，可以确定tlq的运行状态为异常状态。
80.本技术实施例中，处理器根据获取tlq的运行状态确定tlq为异常状态时，生成对应的告警信息，并将告警信息显示在服务器的显示单元中，以提示用户进行查看和维护。
81.本技术实施例提供的软件运行状态的监控方法，通过在确定软件的进程存在时，从配置文件中获取软件的监控指标，监控指标包括第一队列管理器标识、消息队列的第一队列标识和通道的第一通道标识，根据监控指标获取软件的运行状态，运行状态包括队列管理器的状态、消息队列的消息深度、接收通道的状态和发送通道的状态，消息深度用于指示消息队列中消息的数量，确定软件的运行状态为异常状态时，显示异常告警信息。根据获取的监控指标实现了对软件运行状态的监控，并在出现异常状态时进行告警，以使用户及时对出现的问题进行维护，提高软件的消息传输效率。
82.图3为本技术实施例提供的软件运行状态的监控方法的流程示意图二，在图2所示实施例的基础上，进一步对本技术实施例提供的软件运行状态的监控方法进行说明，如图3所示，包括如下步骤：
83.s301、在确定软件的进程存在时，从配置文件中获取软件的监控指标。
84.s302、根据软件的监控指标获取软件的运行状态。
85.本技术实施例中，s301和s302的具体实现方式与图2所示实施例中s201和s202的具体实现方式类似，此处不在赘述。
86.s303、确定队列管理器的状态是否正常，若是，可以执行s304所示步骤，若否，可以执行s309所示步骤。
87.本技术实施例中，处理器可以在tlq提供的查询接口处查询队列管理器的状态，若接收到tlq返回其中的队列管理器处于活动状态，例如，active，则确定队列管理器的状态为正常状态，可以执行s304所示步骤，若接收到tlq返回其中的队列管理器处于非活动状态，例如，inactive，则确定队列管理器的状态为异常状态，可以执行s309所示步骤。
88.示例性的，本技术实施例中，tlq中的队列管理器可以为多个，处理器在获取tlq的监控指标时，可以获取全部需要监控的队列管理器的名称，在确定全部的队列管理器处于活动状态时，处理器可以确定tlq的队列管理器的状态正常。
89.s304、确定消息队列的消息深度是否正常，若是，可以执行s305所示步骤，若否，可以执行s309所示步骤。
90.本技术实施例中，处理器可以在tlq提供的查询接口处查询消息队列的消息数量，若消息数量超过预设值，例如，200条，则可以确认该消息队列的消息深度异常。
91.可以理解的是，确定消息队列的消息深度是否正常，可以根据监控指标中每一个消息队列的名称进行查询，确定每一个消息队列中的消息数量均不超过预设值时，可以确定tlq的消息队列的消息深度正常，消息深度正常时可以执行s305所示步骤，消息深度异常时，可以执行s309所示步骤。
92.s305、确定接收通道的状态是否正常，若是，可以执行s306所示步骤，若否，可以执行s309所示步骤。
93.本技术实施例中，接收通道的状态是指接收通道的监听状态，即，监听接收通道程序是否处于正常运行状态。
94.处理器可以在tlq提供的查询接口处查询接收通道的状态，若接收到tlq返回其中的接收通道的状态处于活动状态，例如，active，则确定接收通道的状态为正常状态，可以执行s306所示步骤，若接收到tlq返回其中的接收通道处于非活动状态，例如，inactive，则确定接收通道的状态为异常状态，可以执行s309所示步骤。
95.s306、确定发送通道的状态是否正常，若是，可以执行s307所示步骤，若否，可以执行s308所示步骤。
96.本技术实施例中，发送通道的状态包括连接使用状态，即link状态，连接为使用状态，即，unlink状态，关闭状态，即，close状态。
97.处理器可以在tlq提供的查询接口处查询发送通道的状态，若接收到tlq返回其中的发送通道的状态处于link状态和unlink状态，则确定发送通道的状态为正常状态，可以执行s307所示步骤，若接收到tlq返回其中的发送通道处于close状态，则确定发送通道的
状态为异常状态，可以执行s308所示步骤。
98.本技术实施例中，s304至s306所示步骤的执行顺序没有严格的时序关系，可以同时执行，也可以先后进行执行。
99.s307、确定循环次数是否大于预设次数，若否，在第一预设时间后，重新执行s306所示步骤，若是，可以执行s311所示步骤。
100.本技术实施例中，循环次数是指处理器获取tlq获取发送通道的循环次本技术实施例中，为实现对tlq软件运行状态的实时监控，根据tlq通道默认的重连时间设置循环获取tlq运行状态，来对lq软件运行状态进行监控。
101.其中，发送通道为tlq中最容易出现异常的，需要进行间隔时间较短的监控流程，其余指标可以执行间隔时间较长的监控流程。
102.本技术实施例中，若发送通道的状态为连接状态，则确定获取发送通道的状态的次数，若确定获取发送通道的状态的循环次数小于预设次数，在第一预设时间后，重复执行获取发送通道的状态的循环次数，在大于预设次数时，可以执行监控其余监控指标的流程。
103.例如，处理器在确定tlq的运行状态正常时，可以以20秒为周期重复获取发送通道的状态，直至获取次数超过预设次数，如15次，或者，获取发送通道的总时长超过预设时长，例如5分钟，可以执行监控其他指标的流程。
104.s308、判断发送通道是否为域名通道，若否，可以执行s309所示步骤，若是，可以执行s312所示步骤。
105.本技术实施例中，tlq中的发送通道分为域名通道和ip通道，处理器在获取tlq的发送通道时，可以根据发送通道的名称来确定该发送通道为域名通道还是ip通道，例如根据发送通道名称中的类型标识来进行域名通道和ip通道的识别。
106.处理器确定发送通道不为域名通道是，可以执行s309步骤，为域名通道时，可以执行s312所示步骤。
107.本技术实施例中，发送通道若为ip通道时，tlq可以通过发送通道直接将消息从源节点发送至目标节点，若为域名通道时，tlq可以通过发送通道将消息从源节点发送至中转代理，再由中转代理发送至目标节点，可以降低tlq所在服务器的压力。
108.s309、确定是否为预设监控指标，若否，可以执行s310所示步骤，若是，结束流程。
109.本技术实施例中，预设监控指标是指可以对出现异常状态的各指标进行忽略的名单，例如，是预设监控指标可以为将某些出现异常的指标进行过滤，不进行告警。
110.本技术实施例中，为避免计划内的目标节点重启时，触发批量的无效告警，设置了匹配过滤条件。
111.示例性的，节点a通过tlq发送消息至节点b，若节点b中的某个服务器是有计划的关闭，或者重启，则处理器获取的tlq的运行状态中，关于连接节点b的队列管理器的状态、消息队列的消息深度、接收通道的状态和发送通道的状态等监控指标均可能处于异常状态，若不进行过滤，就会出现批量的无效告警，因此需要对这些监控指标进行过滤。
112.本技术实施例中，可以根据监控指标的名称或者接收消息的ip地址来进行监控指标的过滤，即，处理器可以根据获取的监控指标中的名称或者接收消息的ip地址与过滤条件中的ip地址是否相同来进行过滤，过滤条件可以为预先存储于服务器中的。
113.本技术实施例中，若过滤条件中的ip地址与获取的监控指标的ip不相同，即，不为
预设监控指标，则可以执行s310所示步骤，若是，结束流程。
114.s310、触发并显示告警信息。
115.本技术实施例中，处理器可以生成对应的告警信息，并将告警信息显示在服务器的显示单元中，以提示用户进行查看和维护。
116.s311、获取当前所有的队列与通道信息，并确定是否与配置文件中的队列与通道信息匹配，若是可以重复执行s303所示步骤，若否，可以执行s314所示步骤。
117.本技术实施例中，在确定获取发送通道的状态的循环次数大于预设次数时，可以执行获取当前所有的队列与通道的信息，具体的：
118.获取当前消息队列的第二队列标识和当前通道的第二通道标识，并记录在队列信息表中。
119.将队列信息表中第二队列标识和第二通道标识与配置文件中的第一队列标识和第一通道标识的进行匹配，若一致，则执行s303所示步骤，即，重复执行监控所有tlq的监控指标的步骤。
120.本技术实施例中，若用户在tlq运行过程中，新建或者删除了部分监控指标，此时，队列信息表中第二队列标识和第二通道标识与配置文件中的第一队列标识和第一通道标识不匹配，则需要更新tlq的监控指标，即，可以执行s314所示步骤。
121.s312、对发送通道的域名进行解析，判断解析结果是否为预设结果，若是，刷新软件的dns缓存后，可以执行s307所示步骤，若否，在第一预设时间后，可以执行s313所示步骤。
122.本技术实施例中，若发送通道的状态为断开状态，且发送通道为域名通道，则处理器对该发送通道的域名进行解析，获取解析结果，解析结果包括接收消息的ip地址，若解析结果中的ip地址与预设的ip地址相同，则处理器刷新tlq的dns缓存，以使发送通道是否可以根据刷新后的dns进行重新连接，并执行确定循环次数是否大于预设次数的步骤。
123.本技术实施例中，若解析结果与中的ip地址与预设的ip地址不同，此时，接收消息的节点可能更换了服务器，例如，接收消息的节点进行了主备服务器的切换时，发送通道的域名解析结果就会发生变化。此时，可以执行s313所示步骤。
124.s313、判断发送通道重新连接是否成功，若是，可以执行s307所示步骤，若否，重启队列管理器后，可以执行s314所示步骤。
125.本技术实施例中，若确定ip地址发生了变更，处理器在在第一预设时间后，重新获取发送通道的状态，以确定发送通道是否重连接成功；若发送通道重连接成功，执行获取发送通道的状态的次数的步骤；若发送通道的状态为断开状态，重启tlq。
126.本技术实施例中，处理器在域名解析结果发生变化，且通道始终为断开状态时，强制重启tlq，执行s314所示步骤，强制加载新的域名地址，实现接收节点的地址变更时，tlq的快速切换。
127.s314、从服务器中获取软件的运行信息，并根据该运行信息生成配置文件后执行s301所示步骤。
128.本技术实施例中，软件的运行信息包括队列管理器的信息、队列的信息和通道信息。
129.在tlq重启后，处理器可以从服务器中重新获取tlq的运行信息，并根据该运行信
息生成配置文件，加载该配置文件后实现对tlq运行状态的监控。
130.本技术实施例中，在队列信息表中第二队列标识和第二通道标识与配置文件中的第一队列标识和第一通道标识不匹配时，处理器可以在服务器上重新获取第二队列管理器标识，根据第二队列管理器标识和队列信息表更新配置文件，根据更新后的配置文件实现对tlq运行状态的监控。
131.本技术实施例提供的软件运行状态的监控方法，通过循环获取软件的运行状态，实现了在软件运行状态异常时的监控告警，并通过监控指标的过滤，避免计划内重启、批量触发的无效告警。在接收端进行主备切换时，可以触发软件的重启，强制加载新域名地址，实现关联方连接快速切换。
132.图4为本技术实施例提供的软件运行状态监控方法的完整示意图，其具体的实现方式以在上述图2和图3进行了说明，此处不在赘述。
133.综上所述，本技术实施例提供的软件运行状态监控方法，基于比对配置文件与动态数据、队列管理器重启触发必要的配置信息采集流程，主动更新配置文件的同时减少了不必要的性能消耗；当触发域名通道重连时，依赖有序的判断逻辑，保证了域名第一时间刷新缓存生效，且通道仅在必要时重启，兼容了日常运行的容错能力，提升了系统自愈水平，节约了人工成本。
134.在上述软件运行状态监控方法实施例的基础上，本技术实施例还提供一种软件运行状态的监控装置。
135.图5为本技术实施例提供的软件运行状态的监控装置50的结构示意图，如图5所示，包括：
136.第一获取模块501，用于在确定软件的进程存在时，从配置文件中获取软件的监控指标，监控指标包括第一队列管理器标识、消息队列的第一队列标识和通道的第一通道标识；
137.第二获取模块502，用于根据监控指标获取软件的运行状态，运行状态包括队列管理器的状态、消息队列的消息深度、接收通道的状态和发送通道的状态，消息深度用于指示消息队列中消息的数量；
138.确定模块503，用于确定运行状态为异常状态时，显示异常告警信息。
139.可选的，确定模块503，还用于若满足如下至少一种条件，则确定运行状态为异常状态：
140.队列管理器的状态为非活动状态，且队列管理器非预设队列管理器。
141.消息深度大于预设值，且接收消息的ip地址非预设ip地址。
142.接收通道的状态为非活动状态，且接收通道的ip地址非预设ip地址。
143.发送通道的状态为断开状态、发送通道不为域名通道，且接收消息的ip地址不为预设ip地址。
144.可选的，第一获取模块501，还用于在确定运行状态为正常状态时，在第一预设时间后，重新获取发送通道的状态；若发送通道的状态为连接状态，则确定获取发送通道的状态的次数；若次数小于预设次数，则重复执行第一预设时间后，重新获取发送通道的状态的步骤，直至次数大于预设次数；在次数大于预设次数后，获取当前消息队列的第二队列标识和当前通道的第二通道标识，并记录在队列信息表中；根据队列信息表更新配置文件。
145.可选的，确定模块503，还用于将队列信息表中第二队列标识和第二通道标识与配置文件中的第一队列标识和第一通道标识的进行匹配；若一致，则重新执行获取软件的运行状态的步骤；若不一致，则在服务器上获取第二队列管理器标识，根据第二队列管理器标识和队列信息表更新配置文件。
146.可选的，确定模块503，还用于对发送通道的域名进行解析，获得解析结果；若解析结果中的ip地址与预设ip地址相同，刷新软件的dns缓存，执行获取发送通道的状态的次数的步骤。
147.可选的，确定模块503，还用于在第一预设时间后，重新获取发送通道的状态，以确定发送通道是否重连接成功；若发送通道重连接成功，执行获取所述发送通道的状态的次数的步骤；若发送通道的状态为断开状态，重启软件。
148.本技术实施例提供的软件运行状态的监控装置可以执行图2至图4所示的软件运行状态的监控方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。
149.图6为本技术实施例提供的软件运行状态的监控电子设备的结构示意图。如图6所示，本实施例提供的软件运行状态的监控电子设备60可以包括：
150.处理器601。
151.存储器602，用于存储终端设备的可执行指令。
152.其中，处理器配置为经由执行可执行指令来执行上述软件运行状态的监控方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。
153.本技术实施例中还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述软件运行状态的监控方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。
154.一种可能的实现方式中，计算机可读介质可以包括随机存取存储器(random access memory，ram)，只读存储器(read-only memory，rom)，只读光盘(compact disc read-only memory，cd-rom)或其它光盘存储器，磁盘存储器或其它磁存储设备，或目标于承载的任何其它介质或以指令或数据结构的形式存储所需的程序代码，并且可由计算机访问。而且，任何连接被适当地称为计算机可读介质。例如，如果使用同轴电缆，光纤电缆，双绞线，数字用户线(digital subscriber line，dsl)或无线技术(如红外，无线电和微波)从网站，服务器或其它远程源传输软件，则同轴电缆，光纤电缆，双绞线，dsl或诸如红外，无线电和微波之类的无线技术包括在介质的定义中。如本文所使用的磁盘和光盘包括光盘，激光盘，光盘，数字通用光盘(digital versatile disc，dvd)，软盘和蓝光盘，其中磁盘通常以磁性方式再现数据，而光盘利用激光光学地再现数据。上述的组合也应包括在计算机可读介质的范围内。
155.本技术实施例中还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述软件运行状态的监控方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。
156.在上述终端设备或者服务器的具体实现中，应理解，处理器可以是中央处理单元(英文：central processing unit，简称：cpu)，还可以是其他通用处理器、数字信号处理器(英文：digital signal processor，简称：dsp)、专用集成电路(英文：application specific integrated circuit，简称：asic)等。通用处理器可以是微处理器或者该处理器
也可以是任何常规的处理器等。结合本技术实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
157.本领域技术人员可以理解，上述任一方法实施例的全部或部分步骤可以通过与程序指令相关的硬件来完成。前述的程序可以存储于计算机可读取存储介质中，该程序被执行时，执行上述方法实施例的全部或部分的步骤。
158.本技术技术方案如果以软件的形式实现并作为产品销售或使用时，可以存储在计算机可读取存储介质中。基于这样的理解，本技术的技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括计算机程序或者若干指令。该计算机软件产品使得计算机设备(可以是个人计算机、服务器、网络设备或者类似的电子设备)执行本技术实施例所述方法的全部或部分步骤。
159.最后应说明的是：以上各实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述各实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。