故障定位方法、装置、终端设备以及存储介质

技术领域

本发明涉及大数据分析领域，尤其涉及一种故障定位方法、装置、终端设备以及存储介质。

背景技术

随着互联网行业的持续发展，对社会的影响逐步增大。金融行业也在一轮又一轮的互联网浪潮下不断增加对软件研发的重视和资金投入。现如今，很多银行、证券机构的系统都在逐步上云，因此云应用也面临着越来越大的机遇和挑战。由于金融类软件对系统的稳定性、可用性、一致性要求极高，所以这些系统的开发人员必须尽最大可能来保障应用运行过程中不出差错。但软硬件都无法保证百分百可靠，再优秀的开发人员随着业务复杂度和应用场景的复杂化，也可能编写出在某些特殊场景下未考虑的情况，进而引发故障。此时，如何快速、准确地定位到故障就成了亟须考虑的问题。

然而，在目前的故障定位技术中，当系统出现问题时，大多数时候都依赖于开发运维人员的手工排障。该方式对开发运维人员的能力要求比较高，且入手时很容易偏离故障方向，此外，传统的分析方式只会根据生产报错信息，排查对应实例的代码、网络、数据库、机器等，对于某些不明显的报错信息，很难准确定位到出故障的环节，给排障工作带来额外的负担。综上所述，现有技术中故障定位方法定位精度不高，导致故障定位效率低下。

发明内容

本发明的主要目的在于提供一种故障定位方法、装置、终端设备以及存储介质，旨在提高故障定位精度，提高故障定位效率。

为实现上述目的，本发明提供一种故障定位方法，所述故障定位方法包括如下步骤：

获取业务监控数据和预设的聚合配置数据；

基于所述聚合配置数据确定聚合类型，并基于所述聚合类型对所述业务监控数据进行聚合分析，得到聚合分析结果以确定故障范围。

可选地，所述获取业务监控数据的步骤包括：

响应于故障定位指令，通过卡夫卡Kafka分区对预先获取的目标业务数据进行消费，得到消费数据；

通过Kafka消费线程从所述Kafka分区中拉取所述消费数据，得到所述业务监控数据。

可选地，所述基于所述聚合配置数据确定聚合类型，并基于所述聚合类型对所述业务监控数据进行聚合分析，得到聚合分析结果以确定故障范围的步骤包括：

基于所述聚合配置数据确定聚合类型，其中，所述聚合类型包括应用聚合、机器聚合和网段聚合；

若所述聚合类型为应用聚合，则基于所述应用聚合对应的第一类聚合维度对所述业务监控数据进行聚合分析，得到第一聚合分析结果；

若所述聚合类型为机器聚合，则基于所述机器聚合对应的第二类聚合维度对所述业务监控数据进行聚合分析，得到第二聚合分析结果；

若所述聚合类型为网段聚合，则基于所述网段聚合对应的网段数据进行聚合分析，得到第三聚合分析结果。

可选地，所述若所述聚合类型为应用聚合，则基于所述应用聚合对应的第一类聚合维度对所述业务监控数据进行聚合分析，得到第一聚合分析结果的步骤包括：

若所述聚合类型为应用聚合，则基于所述应用聚合确定所述第一类聚合维度，其中，所述第一类聚合维度包括实例级、分库级、应用级和全局级中的一种或多种；

基于所述实例级、所述分库级、所述应用级和所述全局级中的一种或多种确定对应的优先级排列顺序，得到第一优先级序列；

基于所述第一优先级序列对所述业务监控数据进行聚合分析，得到所述第一聚合分析结果。

可选地，所述基于所述实例级、所述分库级、所述应用级和所述全局级中的一种或多种确定对应的优先级排列顺序，得到第一优先级序列的步骤包括：

基于所述实例级、所述分库级、所述应用级和所述全局级，确定对应的优先级排列顺序，得到所述第一优先级序列，其中，所述第一优先级序列中优先级由高到低依次为所述全局级、所述应用级、所述分库级、所述实例级。

可选地，所述若所述聚合类型为机器聚合，则基于所述机器聚合对应的第二类聚合维度对所述业务监控数据进行聚合分析，得到第二聚合分析结果的步骤包括：

若所述聚合类型为机器聚合，则基于所述机器聚合确定所述第二类聚合维度，其中，所述第二类聚合维度包括物理机端口PM、虚拟存储区域网络VSAN以及可用区AZ；

基于所述PM、所述VSAN和所述AZ确定对应的优先级排列顺序，得到第二优先级序列；

基于所述第二优先级序列对所述业务监控数据进行聚合分析，得到所述第二聚合分析结果。

可选地，所述若所述聚合类型为网段聚合，则基于所述网段聚合对应的网段数据进行聚合分析，得到第三聚合分析结果的步骤包括：

若所述聚合类型为网段聚合，则基于所述网段聚合对应的网段数据进行数据解析，得到目标网段数据；

基于预设参数确定所述目标网段数据的聚合位数；

基于所述聚合位数对所述目标网段数据进行网段截取与聚合分析，得到所述第三聚合分析结果。

可选地，所述响应于故障定位指令，控制卡夫卡Kafka消费线程对预先获取的目标业务数据进行消费，得到消费数据的步骤之前包括：

将业务监控软件开发工具包SDK集成到添加到目标应用的依赖项中，并引入预设的轻量级开发框架，得到第一组合插件；

基于预设的业务逻辑对所述目标组合插件进行参数配置，得到第二组合插件；

基于所述第二组合插件控制所述目标应用将目标路径上的数据发送给业务监控集群，得到所述目标业务数据。

此外，为实现上述目的，本发明还提供一种故障定位装置，所述装置包括：

数据获取模块，用于获取业务监控数据和预设的聚合配置数据；

聚合分析模块，用于基于所述聚合配置数据确定聚合类型，并基于所述聚合类型对所述业务监控数据进行聚合分析，得到聚合分析结果以确定故障范围。

可选地，所述数据获取模块还用于：

响应于故障定位指令，通过卡夫卡Kafka分区对预先获取的目标业务数据进行消费，得到消费数据；

通过Kafka消费线程从所述Kafka分区中拉取所述消费数据，得到所述业务监控数据。

可选地，所述聚合分析模块还用于：

基于所述聚合配置数据确定聚合类型，其中，所述聚合类型包括应用聚合、机器聚合和网段聚合；

若所述聚合类型为应用聚合，则基于所述应用聚合对应的第一类聚合维度对所述业务监控数据进行聚合分析，得到第一聚合分析结果；

若所述聚合类型为机器聚合，则基于所述机器聚合对应的第二类聚合维度对所述业务监控数据进行聚合分析，得到第二聚合分析结果；

若所述聚合类型为网段聚合，则基于所述网段聚合对应的网段数据进行聚合分析，得到第三聚合分析结果。

可选地，所述聚合分析模块还用于：

若所述聚合类型为应用聚合，则基于所述应用聚合确定所述第一类聚合维度，其中，所述第一类聚合维度包括实例级、分库级、应用级和全局级中的一种或多种；

基于所述实例级、所述分库级、所述应用级和所述全局级中的一种或多种确定对应的优先级排列顺序，得到第一优先级序列；

基于所述第一优先级序列对所述业务监控数据进行聚合分析，得到所述第一聚合分析结果。

可选地，所述聚合分析模块还用于：

基于所述实例级、所述分库级、所述应用级和所述全局级，确定对应的优先级排列顺序，得到所述第一优先级序列，其中，所述第一优先级序列中优先级由高到低依次为所述全局级、所述应用级、所述分库级、所述实例级。

可选地，所述聚合分析模块还用于：

若所述聚合类型为机器聚合，则基于所述机器聚合确定所述第二类聚合维度，其中，所述第二类聚合维度包括物理机端口PM、虚拟存储区域网络VSAN以及可用区AZ；

基于所述PM、所述VSAN和所述AZ确定对应的优先级排列顺序，得到第二优先级序列；

基于所述第二优先级序列对所述业务监控数据进行聚合分析，得到所述第二聚合分析结果。

可选地，所述聚合分析模块还用于：

若所述聚合类型为网段聚合，则基于所述网段聚合对应的网段数据进行数据解析，得到目标网段数据；

基于预设参数确定所述目标网段数据的聚合位数；

基于所述聚合位数对所述目标网段数据进行网段截取与聚合分析，得到所述第三聚合分析结果。

可选地，所述聚合分析模块还用于：

将业务监控软件开发工具包SDK集成到添加到目标应用的依赖项中，并引入预设的轻量级开发框架，得到第一组合插件；

基于预设的业务逻辑对所述目标组合插件进行参数配置，得到第二组合插件；

基于所述第二组合插件控制所述目标应用将目标路径上的数据发送给业务监控集群，得到所述目标业务数据。

此外，为实现上述目的，本发明还提供一种终端设备，所述终端设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的故障定位程序，所述故障定位程序被所述处理器执行时实现如上所述的故障定位方法。

此外，为实现上述目的，本发明还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有故障定位程序，所述故障定位程序被处理器执行时实现如上所述的故障定位方法。

本发明实施例提出的一种故障定位方法、装置、终端设备以及存储介质，通过获取业务监控数据和预设的聚合配置数据；基于所述聚合配置数据确定聚合类型，并基于所述聚合类型对所述业务监控数据进行聚合分析，得到聚合分析结果以确定故障范围。本发明实施例通过对所述聚合配置数据进行预先设置，并基于所述聚合配置数据确定所述聚合类型以对所述业务监控数据进行对应的聚合分析，从而得到所述聚合分析结果以确定故障范围，提高了故障定位精度，从而提高故障定位效率。

附图说明

图1为本发明故障定位装置所属终端设备的功能模块示意图；

图2为本发明故障定位方法第一示例性实施例的流程示意图；

图3为本发明故障定位方法第一实例性聚合分析过程中的系统交互示意图；

图4为本发明故障定位方法第二示例性实施例的流程示意图；

图5为本发明故障定位方法第三示例性实施例的流程示意图；

图6为本发明故障定位方法第四示例性实施例的流程示意图；

图7为本发明故障定位方法第四示例性实施例中不同聚合类型对应的细分类型示意图；

图8为本发明故障定位方法第五示例性实施例的流程示意图；

图9为本发明故障定位方法第六示例性实施例的流程示意图；

图10为本发明故障定位方法第七示例性实施例的流程示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例的主要解决方案是：获取业务监控数据和预设的聚合配置数据；基于所述聚合配置数据确定聚合类型，并基于所述聚合类型对所述业务监控数据进行聚合分析，得到聚合分析结果以确定故障范围。

本申请实施例考虑到，当前业界传统的分析方式只会根据生产报错信息，排查对应实例的代码、网络、数据库、机器等，对于某些不明显的报错信息，很难准确定位到出故障的环节，给排障工作带来额外的负担。综上所述，现有技术中故障定位方法定位精度不高，导致故障定位效率低下。

基于此，本申请实施例提供一种解决方案，通过对所述聚合配置数据进行预先设置，并基于所述聚合配置数据确定所述聚合类型以对所述业务监控数据进行对应的聚合分析，从而得到所述聚合分析结果以确定故障范围，提高了故障定位精度，从而提高故障定位效率。

具体地，参照图1，图1为本申请故障定位装置所属终端设备的功能模块示意图。该故障定位装置可以为独立于终端设备的、能够进行故障定位的装置，其可以通过硬件或软件的形式承载于终端设备上。该终端设备可以为具有数据处理功能的智能移动终端，还可以为具有数据处理功能的固定终端设备或服务器等，此外，该故障定位装置还可以承载于故障定位系统中。

在本实施例中，该故障定位装置所属终端设备至少包括输出模块110、处理器120、存储器130以及通信模块140。

存储器130中存储有操作系统以及故障定位程序；输出模块110可为显示屏等。通信模块140可以包括WIFI模块、移动通信模块以及蓝牙模块等，通过通信模块140与外部设备或服务器进行通信。

其中，存储器130中的故障定位程序被处理器执行时实现以下步骤：

获取业务监控数据和预设的聚合配置数据；

基于所述聚合配置数据确定聚合类型，并基于所述聚合类型对所述业务监控数据进行聚合分析，得到聚合分析结果以确定故障范围。

进一步地，存储器130中的故障定位程序被处理器执行时还实现以下步骤：

响应于故障定位指令，通过卡夫卡Kafka分区对预先获取的目标业务数据进行消费，得到消费数据；

通过Kafka消费线程从所述Kafka分区中拉取所述消费数据，得到所述业务监控数据。

进一步地，存储器130中的故障定位程序被处理器执行时还实现以下步骤：

基于所述聚合配置数据确定聚合类型，其中，所述聚合类型包括应用聚合、机器聚合和网段聚合；

若所述聚合类型为应用聚合，则基于所述应用聚合对应的第一类聚合维度对所述业务监控数据进行聚合分析，得到第一聚合分析结果；

若所述聚合类型为机器聚合，则基于所述机器聚合对应的第二类聚合维度对所述业务监控数据进行聚合分析，得到第二聚合分析结果；

若所述聚合类型为网段聚合，则基于所述网段聚合对应的网段数据进行聚合分析，得到第三聚合分析结果。

进一步地，存储器130中的故障定位程序被处理器执行时还实现以下步骤：

若所述聚合类型为应用聚合，则基于所述应用聚合确定所述第一类聚合维度，其中，所述第一类聚合维度包括实例级、分库级、应用级和全局级中的一种或多种；

基于所述实例级、所述分库级、所述应用级和所述全局级中的一种或多种确定对应的优先级排列顺序，得到第一优先级序列；

基于所述第一优先级序列对所述业务监控数据进行聚合分析，得到所述第一聚合分析结果。

进一步地，存储器130中的故障定位程序被处理器执行时还实现以下步骤：

基于所述实例级、所述分库级、所述应用级和所述全局级，确定对应的优先级排列顺序，得到所述第一优先级序列，其中，所述第一优先级序列中优先级由高到低依次为所述全局级、所述应用级、所述分库级、所述实例级。

进一步地，存储器130中的故障定位程序被处理器执行时还实现以下步骤：

若所述聚合类型为机器聚合，则基于所述机器聚合确定所述第二类聚合维度，其中，所述第二类聚合维度包括物理机端口PM、虚拟存储区域网络VSAN以及可用区AZ；

基于所述PM、所述VSAN和所述AZ确定对应的优先级排列顺序，得到第二优先级序列；

基于所述第二优先级序列对所述业务监控数据进行聚合分析，得到所述第二聚合分析结果。

进一步地，存储器130中的故障定位程序被处理器执行时还实现以下步骤：

若所述聚合类型为网段聚合，则基于所述网段聚合对应的网段数据进行数据解析，得到目标网段数据；

基于预设参数确定所述目标网段数据的聚合位数；

基于所述聚合位数对所述目标网段数据进行网段截取与聚合分析，得到所述第三聚合分析结果。

进一步地，存储器130中的故障定位程序被处理器执行时还实现以下步骤：

将业务监控软件开发工具包SDK集成到添加到目标应用的依赖项中，并引入预设的轻量级开发框架，得到第一组合插件；

基于预设的业务逻辑对所述目标组合插件进行参数配置，得到第二组合插件；

基于所述第二组合插件控制所述目标应用将目标路径上的数据发送给业务监控集群，得到所述目标业务数据。

本实施例通过上述方案，通过获取业务监控数据和预设的聚合配置数据；基于所述聚合配置数据确定聚合类型，并基于所述聚合类型对所述业务监控数据进行聚合分析，得到聚合分析结果以确定故障范围。本实施例通过对所述聚合配置数据进行预先设置，并基于所述聚合配置数据确定所述聚合类型以对所述业务监控数据进行对应的聚合分析，从而得到所述聚合分析结果以确定故障范围，提高了故障定位精度，从而提高故障定位效率。

基于上述终端设备架构但不限于上述架构，提出本申请方法实施例。

参照图2，图2为本申请故障定位方法第一示例性实施例的流程示意图。所述故障定位方法包括：

步骤S10，获取业务监控数据和预设的聚合配置数据；

具体地，本实施例应用于网络业务报错情况下的排障场景，例如高频流程交易网络环境下的排障场景。在互联网浪潮对金融行业的影响下，企业云的运用越来越广泛，对于云应用应对不同场景的能力也有了更高的要求，在一些重要应用运行过程中，会经常进行一些高频流程交易，而在交易过程中经常出现一些诸如调用超时、下游处理失败等异常场景，这些场景如果不能及时被运维人员感知到，将产生严重的生产问题，尤其是在那些涉及金钱交易的重要场景，这种问题就变得更加严重，极容易产生严重的生产事故。然而，现有技术往往难以在高业务复杂度和复杂应用场景下快速并且准确地定位故障。

基于此，本实施例提出一种故障定位方法，通过业务监控集群对高频交易过程中的关键路径(可由用户自行选定)中的流量数据进行监控。本实施例通过用户预先配置聚合规则，主要包括聚合类型(应用、机器、网段)，聚合位置(上游应用、下游应用、发起应用或结束应用)，聚合维度(根据所选聚合类型的不同，聚合维度也有不同的选项)；基于所述聚合规则可以生成聚合配置数据，存储在配置中心中，当业务监控集群需要对故障进行定位时，首先就要获取业务监控数据和预设的聚合配置数据，基于所述聚合配置数据来确定聚合规则，从而动态实现对故障的定位，由于聚合配置数据可由用户进行配置，具有很高的自由度，因此更加适应各种云应用出现故障的场景。

步骤S20，基于所述聚合配置数据确定聚合类型，并基于所述聚合类型对所述业务监控数据进行聚合分析，得到聚合分析结果以确定故障范围。

具体地，本实施例基于所述聚合配置数据可以确定用户预先设置的聚合规则，并对从业务监控集群获取的业务监控数据进行进一步的聚合分析。所述业务监控数据都有自己对应的监测码，在进行故障定位之前，故障定位系统就已经基于所有已知监测码进行聚合处理器的配置，该配置过程也即对聚合处理器的初始化，用以实现后续的聚合分析。例如，用户配置的聚合规则里包含了按应用聚合、按机器聚合和按网段聚合，则所述聚合处理器也对应有应用聚合处理器、机器聚合处理器和网段聚合处理器。

参照图3，图3为本实施例中聚合分析过程中的系统交互图；如图3所示，首先，本实施例中的聚合分析系统具体以聚合应用ZBM2(聚合应用简称)为例，具体地，ZbmApplicationListener(聚合应用监控器)在启动时会从配置中心拉取一次配置，且该拉取动作在启动以预设的定时任务执行一次，所述定时任务可设置为每5分钟触发一次；其次，本实施例的聚合分析系统获取预先生成的监测码，并根据所述监测码配置构建对应的应用、网段、机器聚合处理器，以进行后续的数据聚合处理；然后，在完成配置拉取以及聚合处理器初始化之后，启动Kafka消费线程，基于当前服务实例的部署位置以及消费者数量，分配对应的Kafka分区给对应实例进行消费，其中，每个消费线程都会不断地从Kafka指定分区中拉取数据，并发送给对应的ProcessAggregationController控制器(进程聚合控制器)进行处理；最后，通过ProcessAggregationController进行数据解析并匹配数据中的监测码与对应的监测码配置，经过简单校验后，通过聚合处理器进行聚合分析，得到聚合分析结果。

本实施例通过上述方案，具体通过获取业务监控数据和预设的聚合配置数据；基于所述聚合配置数据确定聚合类型，并基于所述聚合类型对所述业务监控数据进行聚合分析，得到聚合分析结果以确定故障范围。本发明实施例通过对所述聚合配置数据进行预先设置，并基于所述聚合配置数据确定所述聚合类型以对所述业务监控数据进行对应的聚合分析，从而得到所述聚合分析结果以确定故障范围，提高了故障定位精度，从而提高故障定位效率。综上所述，针对应用高频流程交易场景，本实施例通过在执行高频流程交易时，将流程关键步骤数据发送至业务监控专用Kafka集群(也即上述业务监控集群)，并通过模型采集、分析执行状态，及时发现和定位异常问题。本实施例不仅提供了实时的异常告警，还会对这些异常进行聚合分析，这种聚合分析可以有效地缩小故障范围，帮助用户更方便、迅速地定位故障节点。

参照图4，图4为本申请故障定位方法第二示例性实施例的流程示意图。

基于第一实施例，提出本申请第二实施例，本申请第二实施例与第一实施例的区别在于：本实施例对步骤S10，获取业务监控数据和预设的聚合配置数据进行细化。

在本实施例中，步骤S10，获取业务监控数据包括：

步骤S101，响应于故障定位指令，通过卡夫卡Kafka分区对预先获取的目标业务数据进行消费，得到消费数据；

具体地，在本实施例中，当云应用中有故障发生时，本实施例将根据上述实施例中的步骤进行配置拉取并且对聚合处理器进行初始化，在完成配置拉取与聚合器的初始化后，本实施例将先根据当前服务实例的部署位置及消费者数量，分配对应的Kafka分区给对应实例去进行消费。其中，所述Kafka分区是指将一个主题(Topic)的消息日志划分为多个独立的存储单元的过程，每个分区对应一个有序、不可变且持久化存储的消息序列。Topic是指具有相同主题的消息集合，可以理解为一种逻辑上的消息分类或数据流。每个Topic在Kafka中都有一个唯一的名称。此外，本实施例得到消费数据的具体步骤包括：

首先，在消费程序中初始化卡夫卡Kafka消费者的配置，包括配置消费者组、设置Kafka服务器地址和端口等；

然后，根据配置信息，创建一个Kafka消费者实例。消费者将用于从指定的主题中获取业务数据；

最后，通过调用消费者的assign(分配)方法，为消费者分配要消费的分区。可以根据预先确定的目标分区进行分配，或者根据特定的策略进行分配，对预先获取的目标业务数据进行消费，从而得到消费数据。

步骤S102，通过Kafka消费线程从所述Kafka分区中拉取所述消费数据，得到所述业务监控数据。

具体地，本实施例启动Kafka消费者线程，所述消费线程会不断地从Kafka指定分区中拉取数据，并交给对应的ProcessAggregationController控制器进行处理。消费线程可以通过循环来实现持续的消费。此外，在消费过程中，本实施例还可以根据需要向外部系统或上层模块反馈消费状态；具体可以通过回调函数、消息队列等方式将消费状态通知给相关方。通过本步骤可以实现对预先获取的目标业务数据进行实例消费，并根据具体需求进行处理、保存和反馈。此外，还可以利用Kafka的偏移量管理功能，记录消费者的偏移量，从而实现消费的断点续传和精确控制。通过本步骤，本实施例获取到所述业务监控数据，所述业务监控数据中的报文数据中包含有监测码，所述监测码的映射关系是预先制定的，用以确定所述业务监控数据对应的聚合规则，匹配对应的聚合处理器。

本实施例通过上述方案，具体通过响应于故障定位指令，通过卡夫卡Kafka分区对预先获取的目标业务数据进行消费，得到消费数据；通过Kafka消费线程从所述Kafka分区中拉取所述消费数据，得到所述业务监控数据。本实施例启动Kafka消费者线程从Kafka指定分区中拉取数据，为每个线程指定不同的分区，可以实现数据的并行消费。这样可以提高消费速度和吞吐量，并更好地满足高负载和大规模数据处理的需求，更有利于对海量大数据进行聚合分析。

参照图5，图5为本申请故障定位方法第三示例性实施例的流程示意图。

基于第一实施例，提出本申请第三实施例，本申请第三实施例与第一实施例的区别在于：本实施例对步骤S20，基于所述聚合配置数据确定聚合类型，并基于所述聚合类型对所述业务监控数据进行聚合分析，得到聚合分析结果以确定故障范围进行细化。

在本实施例中，步骤S20，基于所述聚合配置数据确定聚合类型，并基于所述聚合类型对所述业务监控数据进行聚合分析，得到聚合分析结果以确定故障范围包括：

步骤S201，基于所述聚合配置数据确定聚合类型，其中，所述聚合类型包括应用聚合、机器聚合和网段聚合；

具体地，本实施例在获取到用户预先设置的聚合配置数据后，对聚合类型进行确定。其中，所述聚合类型包括应用聚合、机器聚合和网段聚合，所述应用聚合在故障聚合分析中指的是将多个相关的应用程序或服务聚合在一起进行故障分析，通过将多个应用程序的日志、错误报告、性能指标等数据进行整合和分析，可以更全面地了解应用系统的健康状况，并发现潜在的故障根因；所述机器聚合在故障聚合分析中指的是将多个相关的机器或设备聚合在一起进行故障分析。通过将多台机器的日志、监控数据、系统指标等进行集中分析，可以发现系统故障的规律和模式；所述网段聚合在故障聚合分析中指的是将多个相关的网络子网或IP地址段聚合在一起进行故障分析。通过将多个网络段的网络流量、连接状态、路由信息等进行整合和分析，可以识别网络中潜在的故障点和瓶颈。将所述聚合类型分为三大类，可以提供给用户不同的故障聚合分析方式，从而实现动态故障定位。

步骤S202，若所述聚合类型为应用聚合，则基于所述应用聚合对应的第一类聚合维度对所述业务监控数据进行聚合分析，得到第一聚合分析结果；

具体地，在本实施例中，根据定时任务从配置中心拉取聚合配置数据后，基于所述聚合配置数据可以确定用户预先配置的聚合规则。若用户配置的是按应用聚合，也即所述聚合类型为应用聚合，则本实施例将基于所述应用聚合对应的第一类聚合维度对所述业务监控数据进行数据分析。更具体地，所述第一类聚合维度有对应的聚合处理器，通过所述第一类聚合维度对应的聚合处理器可以完成对所述业务监控数据的聚合分析，从而得到所述第一聚合分析结果。

步骤S203，若所述聚合类型为机器聚合，则基于所述机器聚合对应的第二类聚合维度对所述业务监控数据进行聚合分析，得到第二聚合分析结果；

具体地，在本实施例中，若用户配置的是按机器聚合，也即所述聚合类型为机器聚合，则本实施例将基于所述机器聚合对应的第二类聚合维度对所述业务监控数据进行数据分析。更具体地，所述第二类聚合维度有对应的聚合处理器，通过所述第二类聚合维度对应的聚合处理器可以完成对所述业务监控数据的聚合分析，从而得到所述第二聚合分析结果。

步骤S204，若所述聚合类型为网段聚合，则基于所述网段聚合对应的网段数据进行聚合分析，得到第三聚合分析结果。

具体地，在本实施例中，若用户配置的是按网段聚合，也即所述聚合类型为网段聚合，则本实施例将基于所述机器聚合对应的网段数据对所述业务监控数据进行数据分析。更具体地，所述网段数据有对应的聚合处理器，通过所述网段数据对应的聚合处理器可以完成对所述业务监控数据的聚合分析，从而得到所述第三聚合分析结果。

本实施例通过上述方案，具体通过基于所述聚合配置数据确定聚合类型，其中，所述聚合类型包括应用聚合、机器聚合和网段聚合；若所述聚合类型为应用聚合，则基于所述应用聚合对应的第一类聚合维度对所述业务监控数据进行聚合分析，得到第一聚合分析结果；若所述聚合类型为机器聚合，则基于所述机器聚合对应的第二类聚合维度对所述业务监控数据进行聚合分析，得到第二聚合分析结果；若所述聚合类型为网段聚合，则基于所述网段聚合对应的网段数据进行聚合分析，得到第三聚合分析结果。本实施例提供了三种聚合分析方式对应的聚合类型，可以由用户根据实际情况自行选择，从而满足不同场景下基于聚合分析的故障定位需求，选择出最合适的聚合方式进行分析和处理。

参照图6，图6为本申请故障定位方法第四示例性实施例的流程示意图。

基于第三实施例，提出本申请第四实施例，本申请第四实施例与第三实施例的区别在于：本实施例对步骤S201，若所述聚合类型为应用聚合，则基于所述应用聚合对应的第一聚合维度对所述业务监控数据进行聚合分析，得到第一聚合分析结果进行细化。

在本实施例中，步骤S202，若所述聚合类型为应用聚合，则基于所述应用聚合对应的第一类聚合维度对所述业务监控数据进行聚合分析，得到第一聚合分析结果包括：

步骤S2021，若所述聚合类型为应用聚合，则基于所述应用聚合确定所述第一类聚合维度，其中，所述第一类聚合维度包括实例级、分库级、应用级和全局级中的一种或多种；

具体地，参照图7，图7为本实施例中不同聚合类型对应的细分类型示意图；若所述聚合类型为应用聚合，也即用户配置的聚合规则是按应用聚合，本实施例首先基于所述应用聚合的聚合类型确定所述第一类聚合维度，其中，如图7所示，所述第一类聚合维度包括实例级、分库级、应用级以及全局级中的一种或者多种(可由用户自行选择所述第一类聚合维度)，其中，所述实例级是指将同一个应用程序的不同实例或副本聚合在一起进行分析。这意味着将同一应用程序部署在不同的服务器或主机上，每个实例负责处理一部分请求或工作负载；故障定位为实例级故障，也即所述故障存在于应用程序的某个实例上或副本上。所述分库级是指将同一应用程序的不同数据库分片(shard)或分区聚合在一起进行分析。这适用于使用分布式数据库的应用程序，其中数据被划分为多个独立的分片。故障定位为分库级故障后，也即所述故障存在于数据库或库分区的层级上。所述应用级则是指将应用程序的不同组件、服务或模块聚合在一起进行分析，故障定位为应用级，也即故障存在于应用程序的层级上。所述全局级是指涉及的所有应用程序、服务或系统的数据聚合在一起进行故障聚合分析，跨越多个应用程序或服务，将它们的日志、指标、事件等信息进行综合分析。通过全局级聚合，可以识别更大范围的故障模式、性能瓶颈以及资源利用情况，从而更全面地评估整个系统的状态和健康。

步骤S2022，基于所述实例级、所述分库级、所述应用级和所述全局级中的一种或多种确定对应的优先级排列顺序，得到第一优先级序列；

具体地，本实施例中的第一类聚合维度包括所述实例级、所述分库级、所述应用级和所述全局级中的一种或多种，通过上述维度可以确定一个优先级排序，例如，维度的高低排序为全局级、应用级、分库级、实例级，因而优先级从高到低依次为全局级、应用级、分库级、实例级，并作为所述第一优先级序列。

进一步地，步骤S2022，基于所述实例级、所述分库级、所述应用级和所述全局级中的一种或多种确定对应的优先级排列顺序，得到第一优先级序列包括：

基于所述实例级、所述分库级、所述应用级和所述全局级，确定对应的优先级排列顺序，得到所述第一优先级序列，其中，所述第一优先级序列中优先级由高到低依次为所述全局级、所述应用级、所述分库级、所述实例级。

具体地，所述全局级涵盖了整个应用程序或系统的全局配置和设置。在这个级别上进行的更改将影响到整个系统的行为。例如，所述全局级的配置可能包括网络基础设施、安全策略、身份验证和授权机制等。因此，若依据本实施例所提故障定位方法聚合出全局级故障，则其优先级为最高。可以理解的，本实施例所提的第一优先级序列的意义在于，在进行系统或应用程序配置时，需要首先考虑全局级别的设置，因为它会影响到整个系统；接下来是应用级别的设置，然后是分库级别和实例级别的设置。通过遵循这个优先级序列，可以保证在更改配置时的一致性和优化。

步骤S2023，基于所述第一优先级序列对所述业务监控数据进行聚合分析，得到所述第一聚合分析结果；

具体地，本实施例得到所述第一优先级序列后，若经过聚合处理器得到的故障定位结果为应用级和全局级故障，则以全局级作为最终的第一聚合分析结果；同理，若经过聚合处理器得到的故障定位结果为实例级和分库级故障，则以分库级作为最终第一聚合分析结果，以此来保证聚合的客观性。

本实施例通过上述方案，具体通过若所述聚合类型为应用聚合，则基于所述应用聚合确定所述第一类聚合维度，其中，所述第一类聚合维度包括实例级、分库级、应用级和全局级中的一种或多种；基于所述实例级、所述分库级、所述应用级和所述全局级中的一种或多种确定对应的优先级排列顺序，得到第一优先级序列；基于所述第一优先级序列对所述业务监控数据进行聚合分析，得到所述第一聚合分析结果。本实施例具体细化了应用聚合对应的聚合分析方式下，实例级、分库级、应用级和全局级的四种聚合维度，并生成优先级序列以保证基于聚合分析得到的故障定位的结果的客观性。

参照图8，图8为本申请故障定位方法第五示例性实施例的流程示意图。

基于第三实施例，提出本申请第五实施例，本申请第五实施例与第三实施例的区别在于：本实施例对步骤S203，若所述聚合类型为机器聚合，则基于所述机器聚合对应的第二类聚合维度对所述业务监控数据进行聚合分析，得到第二聚合分析结果进行细化。

在本实施例中，步骤S203，若所述聚合类型为机器聚合，则基于所述机器聚合对应的第二类聚合维度对所述业务监控数据进行聚合分析，得到第二聚合分析结果包括：

步骤S2031，若所述聚合类型为机器聚合，则基于所述机器聚合确定所述第二类聚合维度，其中，所述第二类聚合维度包括物理机端口PM、虚拟存储区域网络VSAN以及可用区AZ；

具体地，若所述聚合类型为机器聚合，也即用户配置的聚合规则是按机器聚合，本实施例首先基于所述应用聚合的聚合类型确定所述第二类聚合维度，如图7所示，所述第二类聚合维度包括物理机端口PM、虚拟存储区域网络VSAN以及可用区AZ，其中，所述PM是指将同一台物理服务器或计算设备上的不同端口进行聚合分析。每个物理机端口通常负责处理特定类型的网络流量，例如入站、出站、存储等。所述VSAN是指将相同的虚拟存储区域网络中的多个存储设备或存储组件进行聚合分析。VSAN是一种虚拟化技术，它将物理存储设备抽象为逻辑上隔离的存储区域网络。通过VSAN级别的聚合，可以监视和比较不同存储设备之间的性能指标、容量使用情况、故障状态等，以发现特定VSAN中的存储问题或性能瓶颈。所述AZ是指将同一地理区域内的不同可用区进行聚合分析。可用区是云计算环境中的一个概念，指的是具有独立电力供应和网络基础设施的区域。通过可用区级别的聚合，可以监控和比较不同可用区中的机器健康状态、负载情况、资源利用率等指标，以发现特定可用区中的故障或性能问题，并进行合理的负载均衡。

步骤S2032，基于所述PM、所述VSAN和所述AZ确定对应的优先级排列顺序，得到第二优先级序列；

具体地，本实施例中的第二类聚合维度包括所述PM、所述VSAN和所述AZ，通过上述维度可以确定一个优先级排序，例如，维度的高低排序为AZ、VSAN、PM，因而优先级从高到低依次为AZ、VSAN、PM，并作为所述第二优先级序列。

步骤S2033，基于所述第二优先级序列对所述业务监控数据进行聚合分析，得到所述第二聚合分析结果。

具体地，本实施例得到所述第二优先级序列后，若经过聚合处理器得到的故障定位结果为AZ级和VSAN级故障，则以AZ级作为最终的第二聚合分析结果；同理，若经过聚合处理器得到的故障定位结果为AZ级和PM级故障，则以AZ级作为最终的第二聚合分析结果，以此来保证聚合的客观性。

本实施例通过上述方案，具体通过若所述聚合类型为机器聚合，则基于所述机器聚合确定所述第二类聚合维度，其中，所述第二类聚合维度包括物理机端口PM、虚拟存储区域网络VSAN以及可用区AZ；基于所述PM、所述VSAN和所述AZ确定对应的优先级排列顺序，得到第二优先级序列；基于所述第二优先级序列对所述业务监控数据进行聚合分析，得到所述第二聚合分析结果。本实施例具体细化了机器聚合对应的聚合分析方式下，PM级、VSAN级、AZ级的三种聚合维度，并生成优先级序列以保证基于聚合分析得到的故障定位的结果的客观性。

参照图9，图9为本申请故障定位方法第六示例性实施例的流程示意图。

基于第三实施例，提出本申请第六实施例，本申请第六实施例与第三实施例的区别在于：本实施例对步骤S204，若所述聚合类型为网段聚合，则基于所述网段聚合对应的网段数据进行聚合分析，得到第三聚合分析结果进行细化。

在本实施例中，步骤S204，若所述聚合类型为网段聚合，则基于所述网段聚合对应的网段数据进行聚合分析，得到第三聚合分析结果包括：

步骤S2041，若所述聚合类型为网段聚合，则基于所述网段聚合对应的网段数据进行数据解析，得到目标网段数据；

具体地，若所述聚合类型为网段聚合，则本实施例基于所述网段聚合对应的网段数据进行数据解析，在故障定位分析中，网段故障聚合分析是指将同一网络中的多个发生故障的网段进行聚合分析，以便更好地理解和解决网络故障。这种聚合分析可以帮助网络管理员快速定位和处理网段故障，提高网络的可用性和稳定性。

步骤S2042，基于预设参数确定所述目标网段数据的聚合位数；

具体地，本实施例基于用户预先设置的参数对所述网段数据的聚合位数进行限定，本实施例中将所述聚合位数设定为前24位，也即进行网段聚合分析时，本实施例会对解析出的网段数据中的前24位进行聚合。

步骤S2043，基于所述聚合位数对所述目标网段数据进行网段截取与聚合分析，得到所述第三聚合分析结果。

具体地，本实施例通过上述步骤得到所述聚合位数后，对所述解析出的网段数据中的前24位进行聚合，得到所述第三聚合分析结果，以定位出故障网段。在故障网段聚合分析中，首先检测出发生故障的网段。然后，对这些故障网段按照前24位进行聚合。相邻且具有相同前24位的故障网段将被合并为一个更大的故障网段。通过按照前24位进行网段聚合，可以将相邻的故障网段合并，从而简化故障的分析和处理过程。这种聚合方式可帮助网络管理员更好地组织和管理故障数据，并提高定位和修复故障的效率。同时，以前24位为基准聚合网段还能保留足够的细节信息，以便更精确地识别故障网段中不同的主机或子网。

本实施例通过上述方案，具体通过若所述聚合类型为网段聚合，则基于所述网段聚合对应的网段数据进行数据解析，得到目标网段数据；对网段的故障聚合分析；基于预设参数确定所述目标网段数据的聚合位数；基于所述聚合位数对所述目标网段数据进行网段截取与聚合分析，得到所述第三聚合分析结果。本实施例对按网段聚合的分析方式对应的聚合分析过程进行了进一步细化，通过按照前24位进行网段聚合，可以将相邻的故障网段合并，从而简化故障的分析和处理过程。这种聚合方式可帮助网络管理员更好地组织和管理故障数据，并提高定位和修复故障的效率。

参照图10，图10为本申请故障定位方法第七示例性实施例的流程示意图。

基于第二实施例，提出本申请第七实施例，本申请第七实施例与第二实施例的区别在于：

在本实施例中，步骤S101，响应于故障定位指令，控制卡夫卡Kafka消费线程对预先获取的目标业务数据进行消费，得到消费数据的步骤之前包括：

步骤S1001，将业务监控软件开发工具包SDK集成到添加到目标应用的依赖项中，并引入预设的轻量级开发框架，得到第一组合插件；

具体地，本实施例采用了业务监控软件开发工具包SDK对框架进行功能增强，为用户提供选择上的自由度，同时避免了框架嵌入过多功能带来的臃肿和难以维护问题。业务监控SDK是一个提供了特定功能和接口的软件包，用于在应用程序中集成业务监控功能。所述业务监控SDK可以包含与业务监控相关的类、方法、配置文件等。本实施例中所述轻量级框架采用的是Summer框架(轻量级框架中的一种)，所述Summer框架是Spring框架(java编程语言中的一种应用程序框架)的下一代表现层框架。将业务监控SDK添加到目标应用的依赖项中，意味着在应用程序的构建过程中，需要引入该SDK作为额外的依赖。这通常涉及在应用程序的配置文件或构建脚本中指定SDK的版本号和位置，以使编译器/解释器能够正确加载和使用SDK。其中，所述目标应用可以是第一实施例中提到的云应用。通过将业务监控SDK集成到目标应用的依赖项中，并引入预设的轻量级开发框架，可以得到第一组合插件。这个组合插件结合了业务监控的功能和轻量级开发框架的便利性，使开发人员能够更轻松地开发具备业务监控能力的应用程序。

步骤S1002，基于预设的业务逻辑对所述目标组合插件进行参数配置，得到第二组合插件；

具体地，在本实施例中，所述预设的业务逻辑是指在开发第一组合插件时提前定义好的一套规则和逻辑。这些规则可以包括特定的配置项、默认参数、数据流程等，旨在满足特定的业务需求。本实施例中所述参数配置是根据预设的业务逻辑，对第一组合插件进行相应的设置和调整，从而生成第二组合插件。这个插件将保留原有的功能和框架，但参数值和配置选项会根据业务逻辑进行更新，以更好地适应实际的业务需求。

步骤S1003，基于所述第二组合插件控制所述目标应用将目标路径上的数据发送给业务监控集群，得到所述目标业务数据。

具体地，本实施例通过第二组合插件，可以对目标应用进行控制，以执行特定的操作。这可能包括在目标应用的代码中添加调用插件功能的语句、使用插件提供的API(开放接口)进行控制等。第二组合插件的一个功能是将目标路径上的数据发送给业务监控集群。具体来说，插件可以在目标应用中监测指定路径上的数据，并将其发送到预先设置好的业务监控集群中。本实施例通过执行第二组合插件所提供的数据发送功能，目标应用将目标路径上的数据传输到业务监控集群。这些数据可以是与业务相关的关键指标、性能数据、错误日志等，用于对应用程序的运行状况进行分析和监控。

进一步地，除了上述聚合类型对应的聚合分析方法以外，还可以进一步对子网级、用户级进行对应的聚合分析。所述子网级是指在网络中划分的较小的子网范围。在这个级别上进行的更改将仅影响到特定的子网。例如，在企业网络中，可以将不同的部门或办公区域划分为不同的子网，并对每个子网进行独立的配置和管理；所述用户级是指根据用户身份或角色对配置进行划分。在这个级别上进行的更改将仅影响到特定的用户或用户组。例如，在一个应用程序中，可以为不同的用户或用户组设置不同的功能权限、界面偏好等。

进一步地，除了上述聚合类型和聚合维度外，本实施例中的聚合分析系统(也即业务监控系统)还提供对聚合位置的配置。

具体地，用户可以预先指定在上游应用、下游应用、发起应用或者结束应用处进行聚合分析，从而生成聚合位置配置数据。本实施例通过拉取用户预先设定的聚合位置配置数据，匹配对应的关键字，选择对应的聚合处理器进行聚合处理，从而在不同场景下解决故障源头不尽相同的问题，具有较大的灵活性。可以理解地，本实施例中的一种聚合位置优先级序列(按优先级从高到低排列)可以是：所述上游应用、所述下游应用、所述发起应用、所述结束应用；其中，所述发起应用是业务流程的起点，负责触发整个流程的开始；因此，发起应用的优先级较高，应该放在首位，所述上游应用是直接提供数据或服务给当前应用的应用程序。这些应用对当前应用的正常运行至关重要，其优先级较高；相应的，所述结束应用和所述下游应用的优先级较低，且结束应用是业务流程的终点，通常负责完成最后的操作或保存结果，故所述结束应用的优先级最低。此外，本实施例所提方法还自动对接了告警系统，可以在检测出故障后，将信息发送给相关人员，确保运维人员及时感知，从而避免更严重的损失。

本实施例通过上述方案，具体通过将业务监控软件开发工具包SDK集成到添加到目标应用的依赖项中，并引入预设的轻量级开发框架，得到第一组合插件；基于预设的业务逻辑对所述目标组合插件进行参数配置，得到第二组合插件；基于所述第二组合插件控制所述目标应用将目标路径上的数据发送给业务监控集群，得到所述目标业务数据。本实施例通过业务监控软件开发工具包SDK对框架进行功能增强，为用户提供选择上的自由度，同时避免了框架嵌入过多功能带来的臃肿和难以维护问题。用户使用时只需在界面上进行简单配置，并在一些核心场景中调用SDK方法即可，后续的Topic创建、故障聚合等任务都由平台自动完成，使用方便，步骤简洁。

需要说明的是，上述各实施例可以根据实际情况进行合理的组合实施，本实施例对此不再赘述。

此外，本申请实施例还提供一种故障定位装置，所述故障定位装置包括：

数据获取模块，用于获取业务监控数据和预设的聚合配置数据；

聚合分析模块，用于基于所述聚合配置数据确定聚合类型，并基于所述聚合类型对所述业务监控数据进行聚合分析，得到聚合分析结果以确定故障范围。

本实施例实现故障定位的原理及实施过程，请参照上述各实施例，在此不再赘述。

此外，本申请实施例还提出一种终端设备，所述终端设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的故障定位程序，所述故障定位程序被所述处理器执行时实现如上所述的故障定位方法的步骤。

由于本故障定位程序被处理器执行时，采用了前述所有实施例的全部技术方案，因此至少具有前述所有实施例的全部技术方案所带来的所有有益效果，在此不再一一赘述。

此外，本申请实施例还提供一种计算机可读存储介质，所述故障定位可读存储介质上存储有故障定位程序，所述故障定位程序被处理器执行时实现如上所述的故障定位方法的步骤。

由于本故障定位程序被处理器执行时，采用了前述所有实施例的全部技术方案，因此至少具有前述所有实施例的全部技术方案所带来的所有有益效果，在此不再一一赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例排序仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。