一种业务资源监测的方法和装置与流程

1.本公开涉及计算机技术领域，尤其涉及一种业务资源监测的方法和装置。


背景技术：

2.现有的监控技术主要用于监控云平台的各级资源，针对独立的业务资源或者业务系统进行监控，通过在关键的节点上部署代理程序实现。然而对这些独立的业务资源的监测没有统一的监测方法，以致当云平台本身发生故障时，如控制面失效，监控系统将失效。
3.并且，现有技术中的采用集中式的统一监测的方法是将各个业务资源的数据都发送至监管中心，但是这样会导致数据流量集中汇集到一个监管中心上，形成较大的数据处理流量，监管中心需要一次性集中启用较大量的计算、存储和网络资源，监测效果并不理想。


技术实现要素：

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.第四方面，本公开提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述任一项所述的业务资源监测的方法的步骤。
36.第五方面，本公开提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上述任一项所述业务资源监测的方法的步骤。
37.本公开提供了一种业务资源监测的方法和装置，通过对监管中心设置对应的业务监测组，在业务监测中包括监测业务机构和被监测业务机构，基于监测业务机构获取被监测业务机构的状态数据，通过状态数据判断被监测业务机构是否发生故障，充分利用监测业务机构和被监测业务机构之间的互相监测，能够避免使用监测管理平台中心对多个业务机构的监测，造成监测数据集中；在确认被监测业务机构发生故障的情况下，监测机构将故障信息上报至监管中心，监管中心对故障信息进行报警处理，监管中心负责监测机构上报的故障信息，并不处理监测业务机构之间互相监测的状态数据，这样能够合理利用多个监测业务机构之间进行互相监测，减少监管中心数据处理量，同时也能够实现监管中心对多个监测机构的全覆盖监测。
附图说明
38.为了更清楚地说明本公开或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
39.图1是本公开实施例提供的一个分布式监测平台的整体布局图；
40.图2是本公开实施例提供的业务资源监测的方法的流程示意图之一；
41.图3是本公开实施例提供的业务资源监测的方法的流程示意图之二；
42.图4是本公开实施例提供的业务资源监测的方法的流程示意图之三；
43.图5是本公开实施例提供的监管中心对金融机构进行监测的框图；
44.图6是本公开实施例提供的业务资源监测的整体流程示意图；
45.图7是本公开实施例提供的金融机构b的监测资源发生故障情况下的业务资源监测的整体流程示意图；
46.图8是为本公开实施例提供的一种业务资源监测的装置的结构示意图；
47.图9是本公开提供的电子设备的结构示意图。
具体实施方式
48.为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开实施例一部分实施例，而不是全部的实施例。基于本公开实施例中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本公开实施例保护的范围。
49.在本公开实施例中监测管理平台可以为分布式监测管理平台，所述分布式监测平台包括至少一个监管中心，若把每一个监管中心看做一个节点，则分布式监测管理平台可以理解为通过网络进行通信，为了完成共同的任务而协调工作的节点组成的一个监测管理
平台，建立监测管理平台的目的是基于监管中心，实现对多个业务机构进行监测。
50.对应地，监测管理平台可以包括一个监管中心或多个监管中心，监管中心对应至少一个业务监测组，业务监测组包括监测业务机构和被监测业务机构，相应的监测业务机构和被监测业务机构可以分别包括一个或多个业务机构资源。
51.参照图1所示，为本公开实施例提供的一个监测管理平台的整体布局图。图1中的布局是监测管理平台包括两个监管中心，监管中心x和监管中心y，其中，监管中心x对业务监测组进行监测，监管中心y作为备用。具体的，监管中心x对应三个业务机构，每一个业务机构都可以作为监测业务机构或被监测业务机构，每一监测机构包括三个业务机构资源。
52.根据地域或应用场景等一些预设条件的不同，可以划分为不同的业务机构，如图中的a、b、c等，对应的可以将业务机构a和b作为一个业务监测组、业务机构a和c作为一个业务监测组、业务机构b和c作为一个业务监测组，也可以将业务机构a、b、c整体作为一个业务监测组，对于业务监测组中的业务机构的数量不做具体的限定。监管中心在监测方和被监测方中随机配对，即在业务机构a和b作为一个业务监测组的情况下，可以将业务机构a作为监测业务机构，业务机构b作为被监测业务机构，业务机构a对业务机构b进行监测，但是业务机构a作为监测业务机构不能对自身进行监测；也可以将业务机构b作为监测业务机构，业务机构a作为被监测业务机构，业务机构b对业务机构a进行监测，但是业务机构b作为监测业务机构也不能对自身进行监测。并且，监测业务机构和被监测业务机构之间也互相不知道是哪个业务机构对自己进行的监测。这种监测方式可以称为背靠背监测，即每个业务机构共享出一定量的数据处理资源，每个业务机构之间互相不清楚拿出的数据处理资源是对哪个其它的业务机构进行监测，拿出的数据处理资源由统一的监管中心进行管理，使每个业务机构的稳定性都能被监测到，并且能够充分利用各个业务机构所共享出的数据处理资源。
53.其中，在业务监测组为多个的情况下，业务监测组中的监测业务机构之间采用环形网络结构进行数据互通，当其中的某一个监测业务机构发生异常不能对被监测业务机构进行监测时，通过网络切换的方式，可以将该监测业务机构的监测任务分配给邻近的上下游的监测业务机构，继续对被监测业务机构进行监测。实现了在监测业务机构发生异常的情况下，也能基于其他监测业务机构对被监测业务机构进行监测的效果。
54.本公开建立的监管中心，采用主备或双活的架构实现监管中心自身的高可用性。如图1中的监管中心x作为主数据监管中心，用于承担各个业务监测组的监测任务，监管中心y作为备份数据监管中心，用于备份主数据监管中心的数据、配置、业务等。备份数据监管中心一般有热备、冷备，双活的备份方式。
55.监管中心用于有效组织管理各个业务机构共享出来的用于进行全网监测的业务机构资源，实现各个业务机构内全部核心的业务机构资源的监测，并且实现数据的安全传输和管理，防止网络安全事件发生。为了确保公平公正，每个监测业务机构对所要进行监测的业务资源是不能获取的，通过数据加密方式使业务机构资源不能被非法获取。
56.参照图2所示，为本公开实施例提供的业务资源监测的方法的流程示意图之一，该方法包括：
57.210，通过所述监测业务机构获取所述被监测业务机构的状态数据。
58.该步骤中，业务监测组包括至少两个业务机构，每个业务机构可以作为监测业务
机构或被监测业务机构，监测业务机构获取被监测业务机构的状态数据，实现对被监测业务机构的监测，但是监测业务机构不能用于监测本身。对应的，业务机构的类型可以是任意的，如金融机构。
59.状态数据指的是被监测业务机构在运行时的状态数据，可以包括服务器的状态数据、虚拟机的状态数据或存储系统的状态数据等。
60.具体的，监测业务机构获取被监测业务机构的状态数据是采用背靠背的监测方式获取的，即监测业务机构和被监测业务机构之间互相不能确定是哪个业务机构对自身的监测。
61.220，通过所述监测业务机构基于所述状态数据判断所述被监测业务机构是否发生故障。
62.该步骤中，故障可以理解为被监测业务机构在运行过程中出现的故障事件，如发生宕机事件。
63.以监测业务机构和被监测业务机构是金融机构为例，金融机构a作为被监测业务机构，金融机构b为监测业务机构，具体的，金融机构b基于金融机构a的运行的状态数据判断金融机构a是否发生故障。
64.230，在确认所述被监测业务机构发生故障的情况下，通过所述监管中心接收所述监测业务机构上报的故障信息，并进行报警处理。
65.该步骤中，以金融机构a作为被监测业务机构，金融机构b为监测业务机构，在确定金融机构a发生故障的情况下，金融机构b将金融机构a的故障信息发送给监管中心，监管中心对故障信息进行报警处理。
66.本公开提供了一种业务资源监测的方法，通过对监管中心设置对应的业务监测组，在业务监测中包括监测业务机构和被监测业务机构，基于监测业务机构获取被监测业务机构的状态数据，通过状态数据判断被监测业务机构是否发生故障，充分利用监测业务机构和被监测业务机构之间的互相监测，能够避免使用监测管理平台中心对多个业务机构的监测，造成监测数据集中；在确认被监测业务机构发生故障的情况下，监测机构将故障信息上报至监管中心，监管中心对故障信息进行报警处理，监管中心负责监测机构上报的故障信息，并不处理监测业务机构之间互相监测的状态数据，这样能够合理利用多个监测业务机构之间进行互相监测，减少监管中心数据处理量，同时也能够实现监管中心对多个监测机构的全覆盖监测。
67.本公开实施例提供的方法，在步骤210之前，包括下述步骤211～212：
68.步骤211，通过监管中心获取所述监测业务机构和所述被监测业务机构分别对应的业务机构资源。
69.该步骤中，监测业务机构和被监测业务机构分别对应业务机构资源，将不同业务机构的业务机构资源提供给监管中心，由监管中心进行统一管理，各个业务机构之间没有管理对方的业务机构资源的权限。
70.对应的业务机构资源可以包括可用区、故障域、机架、物理服务器、虚拟机、存储单元、网络单元等多种层级的资源。
71.步骤212，通过所述监测业务机构和所述被监测业务机构分别对所述业务机构资源进行划分，生成对应的业务资源和监测资源，并在所述监测资源上设置资源监测节点。
72.该步骤中，分别对监测业务机构和被监测业务机构对应的业务机构资源进行划分，生成对应的业务资源和监测资源，也就是，监测业务机构的业务机构资源划分为业务资源和监测资源，被监测业务机构的业务机构资源也划分为业务资源和监测资源。
73.具体的，在业务机构资源包括可用区、故障域、机架、物理服务器、虚拟机、存储单元、网络单元等多层级的资源的前提下，监控资源可以包括物理服务器、虚拟机、存储单元、网络单元、安全设备和密码模块；业务资源可以包括可用区、故障域和机架等。
74.资源监测节点可以理解为是一段资源监测代理程序，具体的可以为agent程序，agent程序提供监视和管理的功能，在监测资源上安装agent程序，能够实现对被监测业务机构的监测。在监测资源上设置资源监测节点，指的是在监测业务机构的监测资源上和被监测业务机构的监测资源上设置资源监测节点。具体的可以将资源监测代理程序设置在监测资源的密码模块中。
75.本公开实施例提供的方法，步骤210，具体包括下述步骤2111～2112：
76.步骤2111，在预设周期内，通过被监测业务机构基于数据传输通道将所述状态数据传输至所述监测业务机构，其中，所述数据传输通道是在监测业务机构和被监测业务机构之间建立生成的。
77.该步骤中，在监测业务机构和被监测业务机构之间建立数据传输通道，具体是通过秘钥隔离的方式建立专用的密码数据传输通道，主要是为了保证业务监测组中的业务机构的业务机构资源的安全性，防止业务机构之间获取对方的业务机构资源，通过加密的方式保证了各自的业务机构资源的安全性。
78.步骤2112，通过所述监测业务机构的监测资源获取所述被监测业务机构的业务资源的状态数据。
79.本公开实施例提供的方法，步骤220具体包括下述步骤221～222：
80.步骤221，通过所述监测业务机构的监测资源对所述被监测业务机构的状态数据进行分析，获取分析结果。
81.步骤222，基于所述分析结果，通过所述监测机构的监测资源判断所述被监测业务机构的业务资源是否发生故障。
82.以金融机构b作为监测业务机构，金融机构a作为被监测业务机构，业务资源包括可用区、故障域和机架等多个层次，为例进行说明步骤221～222。
83.金融机构b中的监测资源对金融机构a中的可用区、故障域和机架等多个层次的业务资源的状态数据进行分析，基于分析结果判断金融机构a中的可用区、故障域和机架，每一层次的业务资源是否发生故障。
84.参照图3所示，为本公开实施例提供的业务资源监测的方法的流程示意图之二，包括：
85.310，通过监管中心在确定所述被监测业务机构的业务资源具有核心重要标签的情况下，选取所述业务监测组中的任意多个监测业务机构获取所述被监测业务机构的状态数据。
86.该步骤中，以业务监测组中包括四个业务机构为例，四个业务机构可以互相作为监测业务机构和被监测业务机构，但监测业务机构不能用于监测本身。若其中的一个业务机构的监测资源被监管中心确认为是核心重要的，将这个业务机构作为被监测业务机构，
选取业务监测组中的其他三个业务机构作为监测业务机构，对这个被监测业务机构进行监测，获取被监测业务机构的状态数据。
87.320，通过所述任意多个监测业务机构基于所述状态数据判断所述被监测业务机构的业务资源是否发生故障。
88.该步骤中，基于其他三个监测业务机构获取的被监测业务机构的状态数据，判断被监测业务机构的业务资源是否发生故障。
89.330，在确认所述被监测业务机构的业务资源发生故障的情况下，通过监管中心接收所述任意多个监测业务机构上报的故障信息，并进行报警处理。
90.该步骤中，其他三个监测业务机构确认被监测业务机构发生故障的情况下，将故障信息上报给监管中心，监管中心进行报警处理。
91.在被监测业务机构的业务资源确认为核心重要时，通过多个监测业务机构的监测资源进行监测，提高了监测的准确性，并且，监管中心仅需要处理上报的故障信息，减少了监测中心的资源用量，实现监测。
92.参照图4所示，为本公开实施例提供的业务资源监测的方法的流程示意图之三，还包括：
93.410，通过监管中心获取所述监测业务机构中监测资源的状态数据。
94.该步骤中，以金融机构a作为被监测业务机构，金融机构b为监测业务机构，金融机构b对应的金融机构资源包括监测资源和业务资源，通过监管中心获取金融机构b的监测资源的状态数据，具体可以为物理服务器、虚拟机、存储单元、网络单元、安全设备和密码模块对应的状态数据。
95.420，通过监管中心基于所述状态数据判断所述监测业务机构的监测资源是否发生异常。
96.该步骤中，基于物理服务器、虚拟机、存储单元、网络单元、安全设备和密码模块对应的状态数据，监管中心判断金融机构b的监测资源是否发生异常。
97.430，在确认所述监测资源发生故障的情况下，通过监管中心切换至新的监测业务机构。
98.该步骤中，在确认金融机构b的监测资源发生故障的情况下，监管中心切换新的监测业务机构，所述新的监测业务机构可以是金融机构b邻近的业务机构，如金融机构c。
99.440，通过监管中心基于所述新的监测业务机构判断所述监测业务机构的业务资源是否发生故障。
100.该步骤中，金融机构c需要完成金融机构b的任务，也就是，金融机构c对金融机构a的业务资源进行监测，同时金融机构c也需要对金融机构b的业务资源进行监测，并判断金融机构b的业务资源是否发生故障。
101.450，若所述监测业务机构的业务资源发生故障，通过监管中心接收所述被监测业务机构和所述监测业务机构统一上报的故障信息，并进行报警处理。
102.该步骤中，在金融机构c确认金融机构b的业务资源发生故障的情况下，将金融机构a的故障信息和金融机构b的故障信息统一上报至监管中心，监管中心进行报警处理。
103.在监测业务机构的监测资源自身发生故障的情况下，通过切换到邻近的业务机构，将邻近的业务机构作为新的监测业务机构，同时对被监测业务机构的业务资源和监测
业务机构的业务资源进行监测，避免了由于监测业务机构本身故障原因而不能对其他业务机构进行监测的问题。
104.进一步地，对本公开的实施做进一步补充说明：
105.参照图5所示，为本公开实施例提供的监管中心对金融机构进行监测的框图，具体的，以监测业务机构和被监测业务机构为金融机构，从图中可以看出每一个金融机构对应一个金融机构资源，金融机构资源中可以划分为，可用区、故障域、机架、服务器、虚拟机等。金融机构之间采用背靠背监测的方式，即三个金融机构之间互相不知道是哪个金融机构对自己进行监测，监管中心统一对三个金融机构的金融机构资源进行管理，不被各个金融机构所控制。
106.参照图6所示，为本公开实施例提供的业务资源监测的整体流程示意图，具体包括步骤610～640。
107.以监测业务机构和被监测业务机构为金融机构，监管中心划分为3个金融机构a、b、c，将金融机构a、b、c整体作为一个业务监测组，将金融机构a作为监测业务机构，金融机构b作为被监测业务机构，并将金融机构a、b、c对应的金融机构资源分别划分为监测资源和业务资源。
108.610，通过监管中心在金融机构a和金融机构b之间建立数据传输通道。
109.620，在预设的周期内，金融机构a通过数据传输通道向金融机构b发送业务资源对应的状态数据。
110.630，金融机构b的监测资源接收金融机构a的状态数据，并进行分析，基于分析结果，判断金融机构a的业务资源是否发生故障。
111.640，在金融机构b发现金融机构a的业务资源发生故障的情况下，将金融机构a的故障信息上报至监管中心，监管中心进行报警处理。
112.金融机构a、b、c中各自的监测资源会定期地将状态数据向监管中心发送，若监管中心在获取金融机构b的监测资源的状态数据时，发现金融机构b自身的监测资源发生故障，执行步骤710～730。参照图7所示，为本公开实施例提供的金融机构b的监测资源发生故障情况下的业务资源监测的整体流程示意图。
113.710，监管中心切换至邻近的金融机构c，基于金融机构c继续执行对金融机构a的监测任务。
114.720，金融机构c在对金融机构a的监测任务的同时，判断金融机构b的业务资源是否发生故障。
115.730，若金融机构b的业务资源也发生故障，将金融机构b的故障信息上报至监管中心，进行报警处理。
116.下面对本公开实施例提供的一种业务资源监测的装置进行描述，下文描述的业务资源监测的装置与上文描述的业务资源监测的方法可相互对应参照。
117.具体参照图8所示，为本公开实施例提供的一种业务资源监测的装置的结构示意图，该装置包括：
118.第一获取模块810，用于通过所述监测业务机构获取所述被监测业务机构的状态数据，
119.第一判断模块820，用于通过所述监测业务机构基于所述状态数据判断所述被监
测业务机构是否发生故障，
120.第一接收模块830，用于在确认所述被监测业务机构发生故障的情况下，通过所述监管中心接收所述监测业务机构上报的故障信息，并进行报警处理。
121.本公开提供了一种业务资源监测的装置，通过对监管中心设置对应的业务监测组，在业务监测中包括监测业务机构和被监测业务机构，基于监测业务机构获取被监测业务机构的状态数据，通过状态数据判断被监测业务机构是否发生故障，充分利用监测业务机构和被监测业务机构之间的互相监测，能够避免使用监测管理平台中心对多个业务机构的监测，造成监测数据集中；在确认被监测业务机构发生故障的情况下，监测机构将故障信息上报至监管中心，监管中心对故障信息进行报警处理，监管中心负责监测机构上报的故障信息，并不处理监测业务机构之间互相监测的状态数据，这样能够合理利用多个监测业务机构之间进行互相监测，减少监管中心数据处理量，同时也能够实现监管中心对多个监测机构的全覆盖监测。
122.基于上述任一实施例，在所述第一获取模块810之前，包括：
123.获取单元，用于通过监管中心获取所述监测业务机构和所述被监测业务机构分别对应的业务机构资源。
124.划分单元，用于通过所述监测业务机构和所述被监测业务机构分别对所述业务机构资源进行划分，生成对应的业务资源和监测资源，并在所述监测资源上设置资源监测节点。
125.基于上述任一实施例，在所述第一获取模块810具体用于：
126.在预设周期内，通过被监测业务机构基于数据传输通道将所述状态数据传输至所述监测业务机构，其中，所述数据传输通道是在监测业务机构和被监测业务机构之间建立生成的。
127.通过所述监测业务机构的监测资源获取所述被监测业务机构的业务资源的状态数据。
128.基于上述任一实施例，所述第一判断模块820，具体用于：
129.通过所述监测业务机构的监测资源对所述被监测业务机构的状态数据进行分析，获取分析结果。
130.基于所述分析结果，通过所述监测机构的监测资源判断所述被监测业务机构的业务资源是否发生故障。
131.基于上述任一实施例，所述装置还包括：
132.第二获取模块，用于通过监管中心在确定所述被监测业务机构的业务资源具有核心重要标签的情况下，选取所述业务监测组中的任意多个监测业务机构获取所述被监测业务机构的状态数据。
133.第二判断模块，用于通过所述任意多个监测业务机构基于所述状态数据判断所述被监测业务机构的业务资源是否发生故障。
134.第二接收模块，用于在确认所述被监测业务机构的业务资源发生故障的情况下，通过监管中心接收所述任意多个监测业务机构上报的故障信息，并进行报警处理。
135.基于上述任一实施例，所述装置还包括：
136.第三获取模块，用于通过监管中心获取所述监测业务机构中监测资源的状态数
据；
137.第三判断模块，用于通过监管中心基于所述状态数据判断所述监测业务机构的监测资源是否发生异常；
138.切换模块，用于在确认所述监测资源发生故障的情况下，通过监管中心切换至新的监测业务机构；
139.第三判断模块，用于通过监管中心基于所述新的监测业务机构判断所述监测业务机构的业务资源是否发生故障；
140.第三接收模块，用于若所述监测业务机构的业务资源发生故障，通过监管中心接收所述被监测业务机构和所述监测业务机构统一上报的故障信息，并进行报警处理。
141.图9示例了一种电子设备的实体结构示意图，如图9所示，该电子设备可以包括：处理器(processor)910、通信接口(communications interface)920、存储器(memory)930和通信总线940，其中，处理器910，通信接口920，存储器930通过通信总线940完成相互间的通信。处理器910可以调用存储器930中的逻辑指令，以执行一种业务资源监测的方法，该方法包括：通过所述监测业务机构获取所述被监测业务机构的状态数据；通过所述监测业务机构基于所述状态数据判断所述被监测业务机构是否发生故障；在确认所述被监测业务机构发生故障的情况下，通过所述监管中心接收所述监测业务机构上报的故障信息，并进行报警处理。
142.此外，上述的存储器930中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本公开实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
143.另一方面，本公开还提供一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法所提供的一种业务资源监测的方法，该方法包括：通过所述监测业务机构获取所述被监测业务机构的状态数据；通过所述监测业务机构基于所述状态数据判断所述被监测业务机构是否发生故障；在确认所述被监测业务机构发生故障的情况下，通过所述监管中心接收所述监测业务机构上报的故障信息，并进行报警处理。
144.又一方面，本公开还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以执行上述各提供的一种业务资源监测的方法，该方法包括：通过所述监测业务机构获取所述被监测业务机构的状态数据；通过所述监测业务机构基于所述状态数据判断所述被监测业务机构是否发生故障；在确认所述被监测业务机构发生故障的情况下，通过所述监管中心接收所述监测业务机构上报的故障信息，并进行报警处理。
145.以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可
以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
146.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
147.最后应说明的是：以上实施例仅用以说明本公开的技术方案，而非对其限制；尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本公开各实施例技术方案的精神和范围。