CN112636942A - 业务主机节点的监测方法及装置 - Google Patents

Abstract

本发明公开一种业务主机节点的监测方法，包括：通过多个分别部署在各个业务主机节点的代理模块主动获取各个业务主机节点的业务探测结果；将多个代理模块获取到的各个业务主机节点的业务探测结果存储到后台数据库中；分析所述后台数据库中存储的各个业务主机节点的业务探测结果，根据分析结果确定各个业务主机节点之间的关联关系；根据各个业务主机节点之间的关联关系确定处于异常状态的业务主机节点，以实现针对业务主机节点的监测。该方式能够通过各个代理模块主动获取监测数据，进而实现实时监控的效果。并且，能够在业务网络异常时快速判断故障点，保障业务正常运行。

Description

业务主机节点的监测方法及装置

技术领域

本发明涉及电子信息领域，具体涉及一种业务主机节点的监测方法及装置。

背景技术

随着云计算的飞速发展，虚拟化及容器的成熟应用，核心网络业务功能模块越来越庞大，涉及的业务实例节点将会越来越多，其底层的网络节点迅速增长，使得出现网络故障的时候，很难去快速定位故障点。目前单纯的靠现有网络监控工具或者业务本身功能块进行监控很难满足故障定位需求。

现有的技术方案主要使用网络性能监控工具，如现网NPM，通过对各个网络设备进行流量采集、路径关联、会话延时等方式来进行网络性能监控，来判定目前业务网络性能状态。但是，上述方案至少存在如下问题：一方面，采集流量太大；另一方面，现有的监控工具都还不完善，很难做到实时监控，更难做到网络故障预警或告警，该类工具只能在事后实现问题溯源，无法应对突发情况。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种业务主机节点的监测方法及装置。

根据本发明的一个方面，提供了一种业务主机节点的监测方法，包括：

通过多个分别部署在各个业务主机节点的代理模块主动获取各个业务主机节点的业务探测结果；

将多个代理模块获取到的各个业务主机节点的业务探测结果存储到后台数据库中；

分析所述后台数据库中存储的各个业务主机节点的业务探测结果，根据分析结果确定各个业务主机节点之间的关联关系；

根据各个业务主机节点之间的关联关系确定处于异常状态的业务主机节点，以实现针对业务主机节点的监测。

根据本发明的另一个方面，提供了一种业务主机节点的监测装置，包括：

探测结果获取模块，适于通过多个分别部署在各个业务主机节点的代理模块主动获取各个业务主机节点的业务探测结果；

探测结果存储模块，适于将多个代理模块获取到的各个业务主机节点的业务探测结果存储到后台数据库中；

探测结果分析模块，适于分析所述后台数据库中存储的各个业务主机节点的业务探测结果，根据分析结果确定各个业务主机节点之间的关联关系；

监测模块，适于根据各个业务主机节点之间的关联关系确定处于异常状态的业务主机节点，以实现针对业务主机节点的监测。

依据本发明的再一方面，提供了一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如上述的业务主机节点的监测方法对应的操作。

依据本发明的再一方面，提供了一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如上述的业务主机节点的监测方法对应的操作。

在本发明提供的业务主机节点的监测方法及装置中，通过多个分别部署在各个业务主机节点的代理模块主动获取各个业务主机节点的业务探测结果，从而将多个代理模块获取到的各个业务主机节点的业务探测结果存储到后台数据库中。相应地，分析后台数据库中存储的各个业务主机节点的业务探测结果，根据分析结果确定各个业务主机节点之间的关联关系，进而根据各个业务主机节点之间的关联关系确定处于异常状态的业务主机节点，以实现针对业务主机节点的监测。由此可见，该方式能够通过各个代理模块主动获取监测数据，进而实现实时监控的效果。并且，能够在业务网络异常时快速判断故障点，保障业务正常运行。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例一提供的一种业务主机节点的监测方法的流程图；

图2示出了本发明实施例二提供的一种业务主机节点的监测方法的流程图；

图3示出了本发明实施例三提供的一种业务主机节点的监测装置的结构图；

图4示出了本发明实施例五提供的一种电子设备的结构示意图；

图5示出了业务主机节点的监测方法所涉及的系统架构图；

图6示出了UI展示模块所展示的一种界面示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

实施例一

图1示出了本发明实施例一提供的一种业务主机节点的监测方法的流程图。如图1所示，该方法包括：

步骤S110：通过多个分别部署在各个业务主机节点的代理模块主动获取各个业务主机节点的业务探测结果。

其中，各个业务主机节点可以为分布式网络节点，相应地，分别在每个业务主机节点上部署一个代理模块，从而能够通过部署在各个业务主机节点上的代理模块获取本业务主机节点以及其他业务主机节点的业务探测结果。具体实施时，各个代理模块能够主动获取业务探测结果。

步骤S120：将多个代理模块获取到的各个业务主机节点的业务探测结果存储到后台数据库中。

具体地，各个代理模块获取到的各个业务主机节点的业务探测结果既包含代理模块获取到的本业务主机节点的业务探测结果，又包含代理模块获取到的其他业务主机节点的业务探测结果。由于各个业务主机节点之间存储业务关联，因此，各个业务主机节点的业务探测结果之间也存在相互关联，相应地，将各个业务主机节点的业务探测结果统一存储到后台数据库中，有利于针对各个业务主机节点的业务探测结果进行统一分析。

步骤S130：分析后台数据库中存储的各个业务主机节点的业务探测结果，根据分析结果确定各个业务主机节点之间的关联关系。

具体地，由数据处理模块负责分析后台数据库中存储的各个业务主机节点的业务探测结果，根据分析结果确定各个业务主机节点之间的关联关系。其中，该关联关系包括：各个业务主机节点之间的流量走向，以及各个业务主机节点之间的业务探测结果之间的相互影响。

步骤S140：根据各个业务主机节点之间的关联关系确定处于异常状态的业务主机节点，以实现针对业务主机节点的监测。

由于各个业务主机节点之间的业务探测结果存在相互影响，因此，根据各个业务主机节点之间的关联关系，能够确定处于异常状态的业务主机节点，从而实现针对业务主机节点进行监测的目的。

由此可见，在本发明提供的业务主机节点的监测方法中，通过多个分别部署在各个业务主机节点的代理模块主动获取各个业务主机节点的业务探测结果，从而将多个代理模块获取到的各个业务主机节点的业务探测结果存储到后台数据库中。相应地，分析后台数据库中存储的各个业务主机节点的业务探测结果，根据分析结果确定各个业务主机节点之间的关联关系，进而根据各个业务主机节点之间的关联关系确定处于异常状态的业务主机节点，以实现针对业务主机节点的监测。由此可见，该方式能够通过各个代理模块主动获取监测数据，进而实现实时监控的效果。并且，能够在业务网络异常时快速判断故障点，保障业务正常运行。

实施例二

图2示出了本发明实施例二提供的一种业务主机节点的监测方法的流程图。如图2所示，该方法包括：

步骤S210：通过多个分别部署在各个业务主机节点的代理模块主动获取各个业务主机节点的业务探测结果。

其中，各个业务主机节点可以为分布式网络节点，相应地，分别在每个业务主机节点上部署一个代理模块，从而能够通过部署在各个业务主机节点上的代理模块获取本业务主机节点以及其他业务主机节点的业务探测结果。具体实施时，各个代理模块能够主动获取业务探测结果。

其中，当部署在第一业务主机节点的代理模块获取到的第二业务主机节点的业务探测结果为异常时，部署在第一业务主机节点的代理模块进一步获取第二业务主机节点的ICMP探测结果；并且，部署在第一业务主机节点的代理模块进一步获取业务集群中的剩余业务主机节点的第一剩余HTTPS探测结果；业务集群中的剩余业务主机节点上部署的代理模块进一步获取第二业务主机节点的第二剩余HTTPS探测结果。相应地，在后续步骤中，将ICMP探测结果、第一剩余HTTPS探测结果、以及第二剩余HTTPS探测结果分别存储到后台数据库中。通过综合收集多个业务主机节点之间的探测结果，能够快速定位发生故障的业务主机节点。

步骤S220：将多个代理模块获取到的各个业务主机节点的业务探测结果存储到后台数据库中。

具体地，各个代理模块获取到的各个业务主机节点的业务探测结果既包含代理模块获取到的本业务主机节点的业务探测结果，又包含代理模块获取到的其他业务主机节点的业务探测结果。由于各个业务主机节点之间存储业务关联，因此，各个业务主机节点的业务探测结果之间也存在相互关联，相应地，将各个业务主机节点的业务探测结果统一存储到后台数据库中，有利于针对各个业务主机节点的业务探测结果进行统一分析。

步骤S230：分析后台数据库中存储的各个业务主机节点的业务探测结果，根据分析结果确定各个业务主机节点之间的关联关系。

具体地，由数据处理模块负责分析后台数据库中存储的各个业务主机节点的业务探测结果，根据分析结果确定各个业务主机节点之间的关联关系。其中，该关联关系包括：各个业务主机节点之间的流量走向，以及各个业务主机节点之间的业务探测结果之间的相互影响。

步骤S240：根据各个业务主机节点之间的关联关系确定处于异常状态的业务主机节点，以实现针对业务主机节点的监测。

其中，当ICMP探测结果无效，且第二剩余HTTPS探测结果无效时，确定第二业务主机节点处于异常状态；当ICMP探测结果有效，第二剩余HTTPS探测结果有效，且第一剩余HTTPS探测结果无效时，确定第一业务主机节点上部署的代理模块处于异常状态；当ICMP探测结果无效，第二剩余HTTPS探测结果有效，确定第二业务主机节点至第一业务主机节点的网络异常。由此可见，通过各个业务主机节点之间的关联关系，能够定位处于异常状态的业务主机节点，从而实现故障点的快速定位。

步骤S250：通过多个分别部署在各个业务主机节点的代理模块主动获取各个业务主机节点的网络流量数据以及探测反应时长数据，将网络流量数据以及探测反应时长数据存储到后台数据库中。

其中，本步骤的执行时机可以与步骤S210至步骤S240并行执行，也可以在步骤S210至步骤S240执行完毕后执行，总之，本发明不限定本步骤的具体执行时机。

其中，各个业务主机节点的网络流量数据包括：流量数值、流量走向等具体信息。探测反应时长数据主要包括：接收到探测请求的时间点与反馈探测结果的时间点之间的时间差，通过探测反应时长数据能够反映各个业务主机节点的处理性能、处理状态等。

步骤S260：通过均值聚类算法，识别异常状态的探测反应时长数据，并在后台数据库中标记异常状态的探测反应时长数据；在用户界面中展示异常状态的探测反应时长数据。

其中，均值聚类算法可以为k-means算法。K-Means算法的主要内容是：对于给定的样本集，按照样本之间的距离大小，将样本集划分为K个簇，让簇内的点尽量紧密的连在一起，而让簇间的距离尽量的大。通过划分簇，能够将各个待识别的数据分别划分至正常簇以及异常簇，从而根据异常簇快速识别异常状态的探测反应时长数据。

步骤S270：针对各个业务主机节点之间的网络流量数据进行排序，在用户界面中展示排序结果；其中，通过星云图展示业务集群中相互关联的各个业务主机节点之间的流量走向；并且，各个业务主机节点为分布式节点。

其中，各个业务主机节点之间的网络流量数据包括：流量数值数据以及流量走向数据。相应地，通过冒泡排序等排序算法能够对各个业务主机节点之间的网络流量数据进行排序。并且，通过星云图展示业务集群中相互关联的各个业务主机节点之间的流量走向，从而便于根据流量信息识别异常状况并告警。

为了便于理解本发明，下面以一个具体示例为例，详细描述上述各个步骤的具体实现方式：

该示例的目的是提供一种主动性分布式网络性能监测方法，本方法主要涉及用户界面展示部分、数据处理部分、Agent(代理部分)，从而实现对整个网络性能进行监测的目的。图5示出了该方法所涉及的系统架构图。如图5所示，该方法主要由UI展示模块、数据处理模块、以及代理模块实现。下面分别针对各个模块的具体工作流程进行详细描述：

(1)UI展示模块

UI模块(即UI展示模块)的功能包括但不限于业务集群中各相关主机节点星云式关系网、性能数据排序以及异常告警等。UI模块将从数据模块(即数据处理模块)中获取相对应的数据指标来显示整体业务集群的网络性能状态。UI模块中每个星点表示一个业务主机节点，通过从数据模块中取得的数据指标，把业务集群中所有相关主机节点的流量走向等都相关联起来，形成整个星云图，并对实时的业务IP流量排行数据进行展示，以及对异常探测时间的数据进行相对应的告警提醒等。图6示出了UI展示模块所展示的一种界面示意图。

(2)数据处理模块

数据处理模块负责数据处理，包括MySQL数据库。数据处理模块在定时收到代理模块传送到数据库的数据后，对各个业务地址IP流量做相应的排序处理，并对探测的反应时长做异常告警推送。

排序方式采用常用的冒泡排序：

优先比较相邻的元素：如果第一个比第二个大，就交换它们两个，对每一对相邻元素作同样的工作，从开始第一对到结尾的最后一对，这样在最后的元素应该会是最大的数，针对所有的元素重复以上的步骤，除了最后一个，重复步骤1～3，直到排序完成。

冒泡排序的最佳情况：T(n)＝O(n)；最差情况：T(n)＝O(n2)；能够满足目前业务集群主机节点的数据量排序。

IP流量在排序完成后，将重新插入mysql库中形成新表，以供UI调取数据。

上文的步骤S250中提到的探测反应时长数据的获取以及步骤S260中提到的均值聚类算法的具体实现方式如下：

通过均值聚类算法探测反应时长突变告警的核心算法采用k-means算法：K-Means主要内容是对于给定的样本集，按照样本之间的距离大小，将样本集划分为K个簇，让簇内的点尽量紧密的连在一起，而让簇间的距离尽量的大。前期将采集目前业务集群节点前一个整月的网络服务探测反应时间的数据量，用作前期初始质点提取的数集：D＝{t1,t2,...tm},输出的簇集划分为C＝{k1,k2}，k1为正常范围内的簇集，k2为突变簇集用于告警，t为探测反应时间。从数据集D中随机选择2个样本作为初始的2个质心向量：{μ1,μ2}，对于i＝1,2...m,计算样本ti和各个质心向量μj(j＝1,2)的距离：

将ti标记最小的为dij所对应的类别λi，此时更新Cλi＝Cλi∪{ti}，对于j＝1,2,对Cj中所有的样本点重新计算新的质心：

输出簇划分C＝{C1,C2}，这样将产生两个初始质心μj(j＝1,2)：

簇集初始化后，数据处理模块将对实时接收到的新数据做标准的k-means算法，判定属于哪个簇集，若在异常簇集将会把这个数据标注为异常并更新至数据库表内供前端调取。

(3)代理模块

代理模块(即Agent模块)需预安装到对应业务集群的主机节点，代理模块的核心组件包含：配置文件、客户端模块(client模块)、服务器模块(server模块)、流量监控模块(iftop模块)。

配置文件中包含定义好的业务集群主机IP地址、agent传送数据地址、server端口号等，以供agent初始化调用。

Iftop模块使用如下：

Iftop模块是一种可以对本机节点的网络流量进行监控，并可实时监控本机节点有关的各个业务ip地址的收发数据流量的工具，通过iftop模块在系统层面设定crontab定时任务来监控主机节点各个相关ip数据流量，记录到指定日志文件中并传到client模块进行处理。

Client模块具体功能：

a)client在数据采集方面，由iftop模块定时发送数据后进行过滤并传送到mysql数据指定表中，过滤方式采用关键字过滤，关联配置文件中的业务集群ip地址，对业务集群相关的数据采集过滤后入库。

b)client模块在主动探测方面，有效对长流程业务端对端的进行网络服务的主动检测。默认情况将定时对固定server端发送https探测请求，并取得相关探测数据，包括探测是否成功以及探测反应平均时长，整个集群业务节点探测形成环路，具体规则算法如下：

当探测信息反馈异常后，client端将自动发起对对应server端进行ICMP层的探测，通过ping方式，并获取反馈结果后将数据传输到数据处理层(即数据处理模块)。同时，当前client端将对配置文件中定义的其余业务主机IP发送https的主动探测请求并同时触发其余业务节点对异常server节点进行二次https探测，具体如下：

在正常的长流程环路探测过程中，假设有A、B、C、D、E五个主机节点，各个主机节点之间相互发送请求消息并反馈响应消息。正常情况下，各个节点之间的消息均可送达。

固定时间平均探测时长计算公式如下：

T为web探测反应时长，Ti为每次探测反应时长，K为固定时间内探测总次数。计算完成后对每次探测和探测平均时长做记录，传送到数据模块的mysql数据库，做入库处理。

异常探测：A节点(即第一业务主机节点)对B节点(即第二业务主机节点)探测失效，则A节点client端发起对集群其余节点(业务集群中的剩余业务主机节点)的https层探测请求并对B节点进行ping检测。

其余节点对B节点server端进行https层探测请求：在异常检测流程中，可以有效对B节点的网络服务是否正常进行判定，假定集群其余节点对B节点https探测状态为N，A节点对其余节点https探测状态为M，A对B节点ICMP探测状态为T，具体规则如下：

当T无效，N无效，则B节点网络服务异常；当T有效，B无效，则B节点https服务异常；当T有效，N有效，M无效，则B节点网络服务正常，A节点探测模块异常；当T无效，N有效，则B节点到A节点的网络异常，B节点https服务正常。异常判定由client自动根据以上规则判定生产并将结果数据传输至数据处理模块。

server模块主要功能是提供一个被动的https探测端口，在agent初始化的时候，配置文件内已定义好server模块使用的端口号，此端口区别系统现有端口。初始化完成后，server模块以系统进程方式运行在主机系统上，在每次有其他系统节点的client探测时，被动反馈探测数据。

本提案通过上述方案提升对现网网络性能监控，可以获得以下实际用途：在基于整个业务集群范围内，通过主动性分布式的监测网络服务并结合业务集群各主机节点数据流量的采集，在前端UI展示整个业务集群中各个主机节点的网络状态和关联性，通过星云图实现可视化，实现对整个业务集群网络性能的实时监控，可以在业务网络异常时快速判断故障点。针对越来越具复杂性的业务网络，数据中心可以有效的应对网络突发状况，保障业务正常运行。

综上可知，在现有技术中，不能有效的解决网络性能监控中如何快速发现并定位故障点的问题，其主要缺陷如下：首先，在基于现有网络性能监控工具的监控中，通过对各个网络设备进行流量采集、路径关联、会话延时等方式来进行基于业务端到端的网络性能监控，但效果不佳。一方面采集流量太大，另一方面现在的监测工具都还不完善，很难做到实时的监控，更难做到网络故障预警或告警，这类工具只适合做事后的问题溯源，无法应对突发情况。其次，通过前端业务模块的流量以及业务成功率来反映网络性能问题，不够准确，业务模块的故障关联点有很多，有可能是业务本身导致，也可能是底层网络导致，无法有效的反应具体是哪一个网络节点或者是哪一段网络路径的问题。

本发明的上述方法基于主动性分布式网络性能监测装置实现，此装置核心是自主开发形成监测模型，在加入并发调度及自动采集流量数据后，实现在业务实例所在主机层面的主动性网络探测，对业务关联的各个主机节点实现可视化的网络拓扑，并实时监控各个主机节点的网络性能状态，大大提升了运维监控能力，应对突发状况的处理时效。针对越来越复杂性的业务类型，数据中心可以有效的应对网络突发状况，保障业务正常运行。在数据中心整个网络性能监控中，通过在业务集群相关的各主机系统上进行主动性网络服务探测、结合主机层面流量数据采集，对整个业务集群的网络性能状态实现自动化、可视化的监控检测，提高数据中心运维和处理突发故障能力。本发明中通过在主机层面主动性分布式的监测网络服务，对业务集群网络形成可视化监控，大大减少人工干预，能够基于业务层的网络性能实现主动性分布式的监控目的。

实施例三

图3示出了本发明实施例三提供的一种业务主机节点的监测装置的结构示意图，该装置包括：

探测结果获取模块31，适于通过多个分别部署在各个业务主机节点的代理模块主动获取各个业务主机节点的业务探测结果；

探测结果存储模块32，适于将多个代理模块获取到的各个业务主机节点的业务探测结果存储到后台数据库中；

探测结果分析模块33，适于分析所述后台数据库中存储的各个业务主机节点的业务探测结果，根据分析结果确定各个业务主机节点之间的关联关系；

监测模块34，适于根据各个业务主机节点之间的关联关系确定处于异常状态的业务主机节点，以实现针对业务主机节点的监测。

可选的，所述探测结果获取模块具体适于：

当部署在第一业务主机节点的代理模块获取到的第二业务主机节点的业务探测结果为异常时，所述部署在第一业务主机节点的代理模块进一步获取所述第二业务主机节点的ICMP探测结果；

并且，所述部署在第一业务主机节点的代理模块进一步获取业务集群中的剩余业务主机节点的第一剩余HTTPS探测结果；

所述业务集群中的剩余业务主机节点上部署的代理模块进一步获取所述第二业务主机节点的第二剩余HTTPS探测结果；

将所述ICMP探测结果、第一剩余HTTPS探测结果、以及所述第二剩余HTTPS探测结果分别存储到所述后台数据库中。

可选的，所述监测模块具体适于：

当所述ICMP探测结果无效，且所述第二剩余HTTPS探测结果无效时，确定所述第二业务主机节点处于异常状态；

当所述ICMP探测结果有效，所述第二剩余HTTPS探测结果有效，且所述第一剩余HTTPS探测结果无效时，确定所述第一业务主机节点上部署的代理模块处于异常状态；

当所述ICMP探测结果无效，所述第二剩余HTTPS探测结果有效，确定所述第二业务主机节点至所述第一业务主机节点的网络异常。

可选的，所述探测结果获取模块进一步适于：

通过所述多个分别部署在各个业务主机节点的代理模块主动获取各个业务主机节点的网络流量数据以及探测反应时长数据，将所述网络流量数据以及探测反应时长数据存储到所述后台数据库中。

探测结果获取模块，所述监测模块进一步适于：

通过均值聚类算法，识别异常状态的探测反应时长数据，并在所述后台数据库中标记所述异常状态的探测反应时长数据；

在用户界面中展示所述异常状态的探测反应时长数据。

监测模块，所述监测模块进一步适于：

针对各个业务主机节点之间的网络流量数据进行排序，在用户界面中展示排序结果。

可选的，所述监测模块具体适于：

通过星云图展示业务集群中相互关联的各个业务主机节点之间的流量走向；并且，各个业务主机节点为分布式节点。

关于上述各个模块的具体结构和工作原理可参照方法实施例中相应部分的描述，此处不再赘述。

实施例四

本申请实施例四提供了一种非易失性计算机存储介质，所述计算机存储介质存储有至少一可执行指令，该计算机可执行指令可执行上述任意方法实施例中的业务主机节点的监测方法。可执行指令具体可以用于使得处理器执行上述方法实施例中对应的各个操作。

实施例五

图4示出了根据本发明实施例五的一种电子设备的结构示意图，本发明具体实施例并不对电子设备的具体实现做限定。

如图4所示，该电子设备可以包括：处理器(processor)402、通信接口(Communications Interface)406、存储器(memory)404、以及通信总线408。

其中：

处理器402、通信接口406、以及存储器404通过通信总线408完成相互间的通信。

通信接口406，用于与其它设备比如客户端或其它服务器等的网元通信。

处理器402，用于执行程序410，具体可以执行上述业务主机节点的监测方法实施例中的相关步骤。

具体地，程序410可以包括程序代码，该程序代码包括计算机操作指令。

处理器402可能是中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路。电子设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。

存储器404，用于存放程序410。存储器404可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

程序410具体可以用于使得处理器402执行上述方法实施例中对应的各个操作。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的基于语音输入信息的抽奖系统中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (10)

1.一种业务主机节点的监测方法，包括：

通过多个分别部署在各个业务主机节点的代理模块主动获取各个业务主机节点的业务探测结果；

将多个代理模块获取到的各个业务主机节点的业务探测结果存储到后台数据库中；

分析所述后台数据库中存储的各个业务主机节点的业务探测结果，根据分析结果确定各个业务主机节点之间的关联关系；

根据各个业务主机节点之间的关联关系确定处于异常状态的业务主机节点，以实现针对业务主机节点的监测。

2.根据权利要求1所述的方法，其中，所述通过多个分别部署在各个业务主机节点的代理模块主动获取各个业务主机节点的业务探测结果包括：

当部署在第一业务主机节点的代理模块获取到的第二业务主机节点的业务探测结果为异常时，所述部署在第一业务主机节点的代理模块进一步获取所述第二业务主机节点的ICMP探测结果；

并且，所述部署在第一业务主机节点的代理模块进一步获取业务集群中的剩余业务主机节点的第一剩余HTTPS探测结果；

所述业务集群中的剩余业务主机节点上部署的代理模块进一步获取所述第二业务主机节点的第二剩余HTTPS探测结果；

将所述ICMP探测结果、第一剩余HTTPS探测结果、以及所述第二剩余HTTPS探测结果分别存储到所述后台数据库中。

3.根据权利要求2所述的方法，其中，所述根据各个业务主机节点之间的关联关系确定处于异常状态的业务主机节点包括：

当所述ICMP探测结果无效，且所述第二剩余HTTPS探测结果无效时，确定所述第二业务主机节点处于异常状态；

当所述ICMP探测结果有效，所述第二剩余HTTPS探测结果有效，且所述第一剩余HTTPS探测结果无效时，确定所述第一业务主机节点上部署的代理模块处于异常状态；

当所述ICMP探测结果无效，所述第二剩余HTTPS探测结果有效，确定所述第二业务主机节点至所述第一业务主机节点的网络异常。

4.根据权利要求1-3任一所述的方法，其中，所述方法进一步包括：

通过所述多个分别部署在各个业务主机节点的代理模块主动获取各个业务主机节点的网络流量数据以及探测反应时长数据，将所述网络流量数据以及探测反应时长数据存储到所述后台数据库中。

5.根据权利要求4所述的方法，其中，所述将所述网络流量数据以及探测反应时长数据存储到所述后台数据库中之后，进一步包括：

通过均值聚类算法，识别异常状态的探测反应时长数据，并在所述后台数据库中标记所述异常状态的探测反应时长数据；

在用户界面中展示所述异常状态的探测反应时长数据。

6.根据权利要求4所述的方法，其中，所述将所述网络流量数据以及探测反应时长数据存储到所述后台数据库中之后，进一步包括：

针对各个业务主机节点之间的网络流量数据进行排序，在用户界面中展示排序结果。

7.根据权利要求6所述的方法，其中，所述在用户界面中展示排序结果具体包括：

通过星云图展示业务集群中相互关联的各个业务主机节点之间的流量走向；并且，各个业务主机节点为分布式节点。

8.一种业务主机节点的监测装置，包括：

探测结果获取模块，适于通过多个分别部署在各个业务主机节点的代理模块主动获取各个业务主机节点的业务探测结果；

探测结果存储模块，适于将多个代理模块获取到的各个业务主机节点的业务探测结果存储到后台数据库中；

探测结果分析模块，适于分析所述后台数据库中存储的各个业务主机节点的业务探测结果，根据分析结果确定各个业务主机节点之间的关联关系；

监测模块，适于根据各个业务主机节点之间的关联关系确定处于异常状态的业务主机节点，以实现针对业务主机节点的监测。

9.一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-7中任一项所述的业务主机节点的监测方法对应的操作。

10.一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如权利要求1-7中任一项所述的业务主机节点的监测方法对应的操作。

Images