组件分析方法及相关装置与流程

1.本技术属于互联网技术领域，具体涉及一种组件分析方法及相关装置。


背景技术：

2.随着计算机和互联网技术的不断发展，容器化技术的出现有效地解决了不同组件之间的环境隔离、资源限制等难题，加速了组件在分布式计算环境中的大规模部署、动态迁移和弹性伸缩。但同时，这些组件在分布式环境中的部署位置和实例数量变得不确定。组件复杂、高频的动态迁移和弹性伸缩，以及海量的用户并发访问，给系统的稳定性保障带来了严峻的考验，组件部署位置和实例数量的不确定性加剧了系统排障的难度。
3.目前，常见的排障系统在分布式计算环境下，往往很难精确定位到系统或组件异常的根因，排障时间较长，导致系统可用性降低。


技术实现要素：

4.本技术提供一种组件分析方法及相关装置，以精确定位到导致系统或组件异常的根因。
5.为解决上述技术问题，本技术采用的一个技术方案是：提供一种组件分析方法，包括：接收第一组件的第一指标的异常信息；判断所述第一组件是否未调用其他组件或者所述第一组件调用的所述其他组件的第一指标是否均未发生异常；其中，所述其他组件的个数为至少一个；若是，则判定所述第一指标的异常是由于所述第一组件导致；否则，获得被所述第一组件调用且所述第一指标发生异常的第二组件，将所述第二组件作为第一组件，并返回至判断所述第一组件是否未调用其他组件或者所述第一组件调用的所述其他组件的第一指标是否均未发生异常的步骤。
6.为解决上述技术问题，本技术采用的一个技术方案是：提供一种组件分析装置，包括：接收模块，用于接收第一组件的第一指标的异常信息；判断模块，用于判断所述第一组件是否未调用其他组件或者所述第一组件调用的所述其他组件的第一指标是否均未发生异常；其中，所述其他组件的个数为至少一个；第一判定模块，与所述判断模块连接，用于在所述判断模块判断结果为是时，判定所述第一指标的异常是由于所述第一组件导致；第二判定模块，与所述判断模块连接，用于在所述判断模块判断结果为否时，获得被所述第一组件调用且所述第一指标发生异常的第二组件，将所述第二组件作为第一组件，并返回至判断所述第一组件是否未调用其他组件或者所述第一组件调用的所述其他组件的第一指标是否均未发生异常的步骤。
7.为解决上述技术问题，本技术采用的一个技术方案是：提供一种电子设备，包括相互耦接的存储器和处理器，所述存储器中存储有程序指令，所述处理器用于执行所述程序指令以实现上述任一实施例中所述的组件分析方法。
8.为解决上述技术问题，本技术采用的另一个技术方案是：提供一种存储装置，存储有能够被处理器运行的程序指令，所述程序指令用于实现上述任一实施例中所述的组件分
析方法。
9.区别于现有技术情况，本技术的有益效果是：本技术可以对存在调用关系的链路上的组件进行遍历，定位出导致异常发生的根因组件，以提高排障效率，缩短故障恢复的时间，提升系统的可用性。
附图说明
10.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图，其中：
11.图1为本技术组件分析方法一实施方式的流程示意图；
12.图2为本技术组件分析方法另一实施方式的流程示意图；
13.图3a为权重矩阵初始化后一实施方式的结构示意图；
14.图3b为基于第一个时间子段进行统计一实施方式的结构示意图；
15.图3c为基于所有时间子段进行统计后一实施方式的结构示意图；
16.图4为本技术组件分析方法另一实施方式的流程示意图；
17.图5为本技术组件分析方法另一实施方式的流程示意图；
18.图6为本技术组件分析装置一实施方式的结构示意图；
19.图7为本技术电子设备一实施方式的结构示意图；
20.图8为本技术存储装置一实施方式的结构示意图。
具体实施方式
21.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本技术的一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本技术保护的范围。
22.在大规模集群下，组件众多，业务调用链路复杂，基于常规的指标阈值监控和日志监控，虽然能够发现大部分的故障，但故障根因定位困难，导致故障恢复的时间较长。现有方案存在如下问题：
23.1)缺失组件指标和日志的输出规范，或者缺乏有效的规范保障机制，导致不同组件的指标、指标属性标签和日志数据结构等往往不同，甚至同名指标在不同组件下的度量方法、数值单位和语义不同，导致排障系统需要针对不同的组件独立建模和分析，针对不同组件的故障根因分析、相关性分析困难变得繁杂、困难，增加了排障系统设计和实现的复杂度和难度。
24.2)组件崩溃、卡死等故障依赖线下的调试和分析，故障定位效率较低。
25.3)基于常规的指标阈值监控，难以发现指标数据的趋势异常，故障提前预警困难。
26.4)缺乏基于调用链路的告警过滤和根因定位，当上游组件或业务发生异常时，容易产生告警风暴，故障根因定位困难。
27.为了解决上述现有方案中的至少一个问题，本方案在进行正常的组件分析方法之
前，会预先设置好各个组件的各个指标的输出规范，所有组件在输出指标数据时必须遵守该规范。针对组件指标数据的规范化，具体的，约定组件输出的指标数据为时序数据，符合metrics指标结构和类型规范；且组件能够提供基于http协议的get请求接口，或具有实现主动推送指标数据的功能，以使得组件在接收到指标数据返回请求或者达到某个条件时返回各项指标数据。同时，该规范在以下方面对指标的输出进行约束：
28.1)指标语义规范化，即每个指标的语义明确，对语义有歧义的指标进行细化定义或者统一约定。比如，对于组件的内存使用量，如果定义指标的名称为“memory_usage”，则该指标是否包含缓存不明确，不同的人会有不同的理解，存在语义上的歧义。同时指标的度量单位也不明确，在不同组件中，对该指标可能会采用不同的度量单位，最终会导致排障系统在做统计分析时产生统计计算上的混乱或错误，所以需要细化明确，保证不同组件中同一指标的度量单位相同。比如，将组件的内存使用量细分为“memory_rss_usage_bytes”(其含义为：物理内存使用量，度量单位为字节)和“memory_cache_usage_bytes”(其含义为：缓存内存使用量，度量单位为字节)。
29.2)指标维度规范化。所有的组件都必须输出必要的指标数据，一个组件所输出的指标至少需要包含监控系统的四大类黄金指标：延迟、流量、错误、饱和度；其次包含业务特定场景的自定义指标项，例如，组件任务队列中的任务滞留数量、平均滞留时长等，可根据业务场景和需求自定义。其中，延迟表示业务的具体处理时延；流量表示业务在单位时间内的调用量；错误表示业务调用出错数量，成功率等；饱和度表示应用已使用的资源占比。指标维度规范化是为了满足排障系统对组件进行分析告警和故障定位的最基本数据要求。
30.3)指标属性标签规范化。每个具体的指标必须包含必要的属性标签(例如，组件标签和指标标签)，其次包含与业务相关的自定义属性标签。比如，对于一个组件的指标，通常都需要包含组件名称或容器名称，主机ip或容器ip等指标属性标签。指标属性标签的规范化是为了满足排障系统对指标进行基础的细化统计和分析。比如，所有组件都上报了“memory_rss_usage_bytes”指标项，为了能够统计分析不同组件关于该指标的趋势变化，该指标项的属性标签就必须包含组件名称这一指标属性标签，或者能唯一标识各个组件的其他指标属性标签。
31.4)指标数值规范化。metrics提供了五种基本的度量类型，分别是gauges(计数器)、counters(计数器)、histograms(直方图)、timers(计时器)、meters(tps计数器)。指标数值的度量类型需符合预设要求，即须在这五种度量类型中选取。同时指标数值须符合指标度量类型的取值规范；比如，counter类型的指标，其指标数值必须大于或等于0，且只能随着时间的推移单调递增。
32.5)错误码语义规范化。同一个错误码在不同的组件中可能代表着不同的错误，也就是说错误码同样存在语义上的歧义。为了对错误码的语义进行规范，本技术约定了一套错误码清单，并明确每个错误码的含义。组件在处理业务逻辑的过程中，需要上报相关错误的指标数据时，必须按照对应语义的错误码进行上报。如果对应语义的错误码缺失，需要对错误码清单进行增补。
33.上述组件指标数据的规范化，保证了组件输出的指标数据是同构的，便于排障系统对这些指标数据统一建模分析。但如何保障规范被很好的执行落地依然是一个较大的挑战，为此业务系统实现了一个智能组件来保障规范的有效执行。智能组件实际上被实现为
一个服务的管理器，它实现了服务的抽象管理，具体服务的业务逻辑被抽象成插件，由不同服务的开发者实现，不同的服务插件与智能组件组合在一起形成一个功能完备的服务组件。智能组件除了服务的抽象管理，还实现了以上规范中基础指标数据的采集，智能组件通过将业务逻辑与基础功能解耦，保障了不同服务组件之间基础指标数据在维度和语义上的规范化，确保了不同组件之间指标数据是同构的。在具体应用过程中，每个组件输出的各个指标数据即符合上述规范，而无需再经过其余服务器等进行转化处理，以降低排障系统的计算负荷，提高排障系统的工作效率。
34.在系统运行过程中，可以对各个组件的各个指标数据进行采集。由于所有组件天然实现了基础指标的输出，并提供了metrics接口。组件指标的采集可以基于prometheus实现，由prometheus通过组件的metrics接口拉取指标数据，并持久化存储。
35.另外，在系统运行过程中，也可对日志数据进行采集。将各机器的docker运行时根目录配置为统一的指定目录。针对组件容器日志，采用daemonset类型部署filebeat进行日志的采集。所谓daemonset，是kubernetes容器编排的一种管理对象，以deamonset类型部署的组件，会被自动部署到满足机器标签选择的每台机器上，且每台机器上一个服务实例。针对组件自定义输出的文本日志，采用sidecar的方式部署filebeat进行日志的采集。所谓sidecar部署方式就是将filebeat容器和组件容器编排在一个pod管理对象内，filebeat容器和组件容器通过共享数据卷的方式实现日志目录的共享读写，从而使得filebeat能够监听和采集组件的文本日志。组件容器日志和业务文本日志通过filebeat采集后，直接传输给elasticsearch进行存储，后续可通过kibina进行检索和展示。
36.一般而言，在系统运行过程中，可能会出现组件崩溃、组件卡死、组件启动异常等异常事件，对于上述异常事件的监测方式可以为：
37.对于组件崩溃事件，就是要捕获组件运行过程中的崩溃异常，在组件的程序入口位置设置程序异常捕获和处理模块，当程序发生崩溃时，会触发异常捕获和处理模块，执行相应的处理逻辑。
38.对于组件卡死事件，就是要监测程序的线程或协程是否存在死锁或阻塞。在组件的服务管理中，会对每次请求做会话管理；正常情况下，服务插件对每次会话的处理应该在超时时间之内返回成功或者失败，如果一次或多次会话请求没有在超时时间之内返回成功或失败的结果，则判定当前服务存在卡死。
39.对于组件的启动异常事件，就是要捕获组件在启动过程中的导致组件无法按预期正常执行的各种异常。常见的启动异常原因如内存不足、配置文件错误、网络异常、数据库异常等。组件在程序启动的过程中，会检测环境和配置的相关异常，如果发现异常则判定为启动异常事件。否则，执行服务插件的初始化接口，如果服务启动异常，会通过初始化接口返回错误码和异常原因描述等信息。
40.当监测到上述异常事件后，可以对于异常事件相关的事件数据进行采集；一般而言，事件数据由三部分组成：异常事件基本信息(即异常事件的属性标签)，与异常事件相关联的数据信息，以及异常事件发生时刻的会话参数。事件的基本信息就是描述事件本身的一些基本属性的数据。与异常事件相关联的数据信息就是与事件根因相关联的一些数据，如崩溃、卡死的堆栈，启动异常的原因描述等。异常事件发生时刻的会话参数，就是在故障发生邻近时刻，组件正在处理的会话参数。不同事件数据的采集方法有所差异，具体的：
41.1)异常事件基本信息的采集。异常事件基本信息包含异常事件id、异常事件类型、服务id、集群名称、服务pod名称、异常事件发生时间和元数据等基本信息。其中，异常事件的元数据为json格式的文本，包含了主机地址、异常事件关联数据的文本名称，以及其他可扩展信息。当异常事件发生时，组件根据服务的配置生成事件基本信息，并调用排障系统的事件管理接口追加该事件信息。
42.2)与异常事件相关联的数据信息的采集。异常事件关联数据，包括崩溃、卡死事件发生时刻的堆栈信息、启动异常事件发生时的异常原因描述信息。当组件监测到异常事件的发生时，对应异常事件的处理模块会对异常事件关联数据进行采集。具体的，对于崩溃事件，组件通过“runtime”包的“runtime.stack”方法捕获程序panic异常的堆栈，并将其写入到命名规范为“事件类型_服务id_事件id”的文件中。对于卡死事件，组件基于pstack工具获取当前进程的stack信息，并将其写入到命名规范为“事件类型_服务id_事件id”的文件中。对于启动异常事件，组件将检测到的异常信息、或服务插件初始化接口返回的异常信息写入到命名规范为“事件类型_服务id_事件id”的文件中。最终，日志采集工具filebeat会监听到文件的内容变化，并将其读取并传送至elasticsearch中持久化存储。
43.3)异常事件发生时刻的会话参数的采集。当崩溃、卡死异常事件发生时，组件还会读取会话队列中正在处理的会话参数，如果会话参数中包含音视频、图片等多媒体数据，则对其进行base64编码，然后以异常事件id作为key，会话参数组成的json对象数组作为value，将异常事件发生时刻的会话参数存储到数据库中。
44.在确定好上述规范之后，可以对系统中的多个组件进行正常监测和分析过程，请参阅图1，图1为本技术组件分析方法一实施方式的流程示意图，上述组件分析方法具体包括：
45.s101：接收第一组件的第一指标的异常信息。
46.具体地，处理器可以接收系统中多个组件上传的多个指标的时序数据信息；当基于该时序数据信息判断出当前某个组件的某个指标异常时，则可将发生异常的某个组件可以称之为第一组件，发生异常的某个指标称之为第一指标。在某些情况下，第一组件的个数可能为多个，第一组件的第一指标可能为多个，可以针对每个发生异常的第一组件的第一指标进行下述步骤s102-步骤s104的分析过程。或者，也可是处理器接收到异常事件的上报信息后，基于该异常事件获得第一组件和第一指标。或者，也可是处理器接收到错误码的上报信息后，基于该错误码的上报信息获得第一组件和第一指标。
47.一般而言，第一组件的第一指标发生异常可能是由自身第一组件导致，也可能是由第一组件的调用链路上的其他组件导致，后续步骤s102-步骤s104的目的就是确定出导致第一组件的第一指标发生异常的根因组件的位置。
48.s102：判断第一组件是否未调用其他组件或者第一组件调用的其他组件的第一指标是否均未发生异常；其中，其他组件的个数为至少一个。
49.具体地，在apm系统(应用性能管理系统)中，对会话请求进行全链路trace_id追踪，能够得到各组件之间的调用关系，这些调用关系本质上是一个有向图。当一个服务发生异常时，排障系统的根因分析模块从apm系统中获取组件调用关系有向图的邻接矩阵，得到一个n
×
n的矩阵，其中n代表组件的数量；基于该邻接矩阵获得第一组件的调用关系，即获得第一组件所在的调用链路。其中，定义f1(i,j)＝1表示组件i调用组件j，f1(i,j)＝0表示
组件i和组件j之间没有调用关系，其中1≤i,j≤n。此外，本技术中所指调用为单向调用，即组件i调用组件j后，组件j向组件i返回信息不称之为调用。定义e(k,m)＝1表示组件k的m指标发生异常，e(k,m)＝0表示组件k的m指标未发生异常，其中1≤k≤n。
50.当步骤s101中接收到组件i的m指标异常信息时，上述步骤s102的判断过程用公式表示为即判断是否等于0或者是否等于0。
51.s103：若是，则判定第一组件的第一指标的异常是由于第一组件导致。
52.具体地，上述若是的含义是：若第一组件未调用其他组件，或者第一组件调用了其他组件，但调用的其他组件的第一指标均是正常的，则可以判定出第一组件的第一指标异常是由第一组件本身导致的。
53.在一个应用场景中，假设基于邻接矩阵获得如下调用关系：组件a调用组件b，组件b调用组件c，组件a调用组件d；且经过步骤s101发现组件a的m指标发生异常，但经过步骤s102发现组件a调用的组件b和组件d的m指标均未发生异常，则可以判定组件a的m指标异常是由于组件a本身导致。
54.s103：否则，获得被第一组件调用且第一指标发生异常的第二组件，将第二组件作为第一组件，并返回至判断第一组件是否未调用其他组件、或者第一组件调用的其他组件的第一指标均未发生异常的步骤。
55.具体地，上述否则的含义是：若第一组件调用了其他组件且调用的其他组件中有至少一个其他组件的第一指标异常，则对被第一组件调用且第一指标发生异常的第二组件进行判定，以确定该异常根因是否发生在该第二组件。
56.在一个应用场景中，假设基于邻接矩阵获得如下调用关系：组件a调用组件b，组件b调用组件c，组件a调用组件d；且经过步骤s101发现组件a的m指标发生异常，但经过步骤s102发现组件a调用的组件b的m指标发生异常，组件a调用的组件d的m指标未发生异常，则此时获得组件b，并对组件b进行根因判定。而对组件b进行根因判定的过程与组件a类似，即基于邻接矩阵获得组件b的调用关系，然后判定组件b是否未调用其他组件或者组件b调用的其他组件的m指标是否均未发生异常。如此循环，直至搜索到根因组件的位置。
57.通过上述设计方式，本技术可以对存在调用关系的链路上的组件进行遍历，定位出导致异常发生的根因组件，以提高排障效率，缩短故障恢复的时间，提升系统的可用性。
58.在一个实施方式中，每个组件一般有很多维度的时序指标，某些组件的某些指标之间具有一定的关联，即一个组件的一个指标发生异常时，另一个组件的另一个指标可能同时发生异常。本技术的排障系统通过聚类分析可以基于历史异常时序数据，对历史的异常项进行聚类，以发现众多异常项之间的关系。后续在系统监控过程中，可以从聚为一类的多个指标中仅选择一个代表性指标作为系统的监控指标，从而简化监控的复杂度和根因定位的难度。具体地，请参阅图2，图2为本技术组件分析方法另一实施方式的流程示意图，该组件分析方法包括：
59.s201：获得第一预设时间段内发生异常的多个异常项的异常时序数据；其中，异常项的属性标签包含组件标签和指标标签，不同异常项的组件标签和指标标签中的至少一个不同。
60.举例而言，假设目前在第一预设时间段内发生异常的有组件a和组件b，组件a有a和b两个指标，组件b也有a和b两个指标，则此时异常项包括aa、ab、ba和bb。
61.s202：将第一预设时间段划分为多个时间子段，基于每个时间子段进行统计，将发生异常的异常项的自相关权重增加预设值、以及将同时发生异常的两个异常项的互相关权重增加预设值。
62.可选地，在本实施例中，可以借助于权重矩阵对每个时间子段进行统计。具体而言，在上述步骤s202之前，包括：初始化权重矩阵；其中，多个异常项的个数为n，权重矩阵为n行n列矩阵，且权重矩阵中第i行第j列元素代表第i个异常项与第j个异常项之间的相关权重；当第i个异常项与第j个异常项相同时，相关权重为自相关权重；当第i个异常项与第j个异常项不同时，相关权重为互相关权重。
63.举例而言，当异常项包括aa、ab、ba和bb时，如图3a所示，图3a为权重矩阵初始化后一实施方式的结构示意图。权重矩阵初始化后各个权重的初始值可以为0；且可选地，预设值可以为1等正整数。第一预设时间段可以被划分为多个时间子段，且每个时间子段的长度相同，相邻两个时间子段中前一个时间子段的终止时刻与下一个时间子段的起始时刻重合。
64.如图3b所示，图3b为基于第一个时间子段进行统计一实施方式的结构示意图。图3b中将第一预设时间段划分为九个时间子段，且图3b中圆圈表示在该时间子段内对应组件的指标发生异常。以第一个时间子段为例，异常项为aa和ba，则此时权重矩阵中aa对应的自相关权重+1，ba对应的自相关权重+1，与aa和ba相关的互相关权重+1。与之类似的，以第三个时间子段为例，异常项为bb，则此时权重矩阵中bb对应的自相关权重+1。以第六个时间子段为例，异常项包括aa、ab和ba，则此时权重矩阵中aa、ab和ba分别对应的自相关权重+1，与aa和ab相关的互相关权重+1，与aa和ba相关的互相关权重+1，与ab和ba相关的互相关权重+1。最终的统计结果可如图3c所示，图3c为基于所有时间子段进行统计后一实施方式的结构示意图。
65.s203：针对每个异常项，响应于当前异常项的自相关权重超过聚类门限，且与当前异常项相关的互相关权重在预设范围内，则将当前互相关权重对应的两个异常项聚为一类；其中，预设范围与自相关权重和波动系数相关。
66.具体地，可以从统计后的权重矩阵中获取组件i的t指标的自相关权重p
it
，若p
it
》δ，且其与组件j的m指标的互相关权重p(it,jm)≤p
it
±
ε，则将组件i的t指标和组件j的m指标异常聚为一类；其中，δ为聚类门限，ε为波动系数，p
it
±
ε为预设范围。
67.例如，以图3c中异常项aa为例，与其相关的其他异常项包括ab和ba，则此时需要分别判断aa和ab是否能聚为一类、以及aa和ba是否能聚为一类。假设当判断出aa和ab能聚为一类、以及aa和ba能聚为一类时，可以直接将aa、ab和ba三者聚为一类。
68.需要说明的是，在本实施例中，上述图2中的聚类分析可以在图1中链路分析之前或之后进行，或者上述图2中的聚类分析也可单独图1中的链路分析进行。当图2中聚类分析在图1中链路分析之前进行时，可以从聚为一类的集合中挑选出一个作为监控对象；当接收到该监控对象的异常信息(即图1中第一组件的第一指标的异常信息)后，可以获得与该第一组件的第一指标聚为一类但未被监控的其他指标项，当判定出其他指标项发生异常后，将其他指标项作为第一组件和第一指标，并同样进行图1中步骤s102-步骤s104的过程，以确定出根因组件；即获得其他异常项的组件信息和指标信息，将其他异常项的组件信息和指标信息作为第一组件和第一指标，并进入步骤s102-步骤s104。
69.在又一个实施方式中，组件有很多维度的时序指标，某些维度的指标之间具有一定的相关性，甚至存在一定的因果关系，比如请求量大导致接口延迟增加。排障系统通过相关性分析找出同组件不同维度指标之间的相关性，并取强相关指标中的某个代表性指标作为系统的监控指标，从而简化监控的复杂度和根因定位的难度，具体实现方法如下，请参阅图4，图4为本技术组件分析方法另一实施方式的流程示意图，其具体包括：
70.s301：获取第二预设时间段内同一组件的多个指标的第一历史时序数据；其中，组件在第二预设时间段内发生异常或未发生异常。
71.具体地，第一历史时序数据可以包括异常数据或非异常数据。且在同一时刻下同一组件的每个指标均有相应的第一历史时序数据。
72.s302：基于同一组件的任意两个指标的第一历史时序数据获得两个指标之间的相关性系数。
73.具体地，可以根据下列公式计算获得相关性系数：
[0074][0075]
其中，r
xy
为指标x和指标y的相关性系数，n为指标数据个数，xi为指标x的在第i个时刻下的指标值，yi为指标y在第i个时刻下的指标值。
[0076]
s303：响应于相关性系数的绝对值大于或等于第一阈值，则与相关性系数相关的两个指标存在强相关关系。
[0077]
可选地，第一阈值可以为0.8等。
[0078]
需要说明的是，在本实施例中，上述图4中的相关性分析可以在图1中链路分析之前或之后进行，也可单独于图1中的链路分析进行。当图4中相关性分析在图1中链路分析之前进行时，可以从具有强相关关系的集合中挑选出一个作为监控对象；当接收到该监控对象的异常信息(即图1中第一组件的第一指标的异常信息)后，可以获得与该第一组件的第一指标具有强相关关系但未监控的其他指标，将第一组件的其他指标同样进行图1中步骤s102-步骤s104的过程，以确定出根因组件；即将第一组件的其他指标作为第一组件的第一指标，并进入步骤s102-步骤s104。
[0079]
在又一个实施方式中，在大规模分布式集群中，指标在时序上往往会呈现出稳定的趋势变化，尤其是流量、饱和度相关指标，表现尤为明显。针对这些具有明显趋势变化的指标，通过对历史数据的拟合，能够建立一个预测模型，根据预测模型能够对未来某一时刻的数值进行预测。常规的数据拟合依赖大量历史数据，计算量大；本技术提出基于改进的移动平均法进行趋势预测，适用于邻近时间内的趋势预测，具有计算量小，实时性高的特点。具体请参阅图5，图5为本技术组件分析方法另一实施方式的流程示意图。该组件分析方法包括：
[0080]
s401：基于当前周期下的当前时刻设置时间窗口，并获得当前周期之前的多个历史周期下的同一时间窗口内的目标组件的目标指标的第二历史时序数据。
[0081]
具体地，假设当前周期下的当前时刻为t，划定时间窗口为[t-δt,t+δt]，具体划定时间窗口的大小与后续待预测的未来时刻没有太大关联，只要未来时刻在t+δt附近即可。以一定的时间周期t(一般以天为周期)滑动时间窗口，获得各个历史周期下同一时间窗
口内的第二历史时序数据。例如，第i个时间周期ti的时间窗口为[t-i
×
t-δt，t-i
×
t+δt]，获取该时间窗口内的第二历史时序数据m
i1
,
…
,m
ip
,其中p为该时间窗口内时序指标的数量。
[0082]
s402：基于所有第二历史时序数据获得同一时刻下的多个第二历史时序数据的均值。
[0083]
具体地，以公式表示如下：
[0084][0085]
其中，表示均值，n代表历史周期的个数，m
iz
表示在第i个历史周期中第z个时刻下的时序指标值。
[0086]
s403：对不同时刻下的所有均值进行拟合以获得拟合函数。
[0087]
具体地，可以将多个时刻下的均值进行线性或多项式拟合，以获得拟合函数f2(t)。
[0088]
s404：基于拟合函数、以及当前周期下的当前时刻之前的多个第二历史时序数据获得当前时刻之后的未来时刻的预测值。
[0089]
具体地，上述步骤s404的具体实现过程可以为：
[0090]
a、基于当前周期下的当前时刻之前的多个第二历史时序数据与对应时刻的均值获得离差。具体地，取时间窗口[t-δt，t]中时序指标m1,
…
,mv，其中v为该时间窗口[t-δt，t]内时序指标的数量，计算这些时序数据与对应的均值获得离差，以公式表示如下：
[0091][0092]
其中，δ为离差，mj为[t-δt，t]时间窗口内第j个时刻下的时序指标值，为经过步骤s402获得的多个历史周期下第j个时刻下的均值。
[0093]
b、基于拟合函数获得未来时刻下的函数值，并将函数值与离差之和作为预测值。
[0094]
具体地，可以将未来时刻t1代入拟合函数f2(t)以获得函数值为f2(t1)，并将f2(t1)与δ之和作为预测值。
[0095]
s405：基于预测值获得目标指标的趋势判定结果。
[0096]
具体地，上述步骤s405的实现过程可以为：判断预测值是否位于第一可信区间外、以及离差是否位于第二可信区间外；若预测值位于第一可信区间外或离差位于第二可信区间外，则判定目标指标趋势异常；否则，判定目标指标趋势正常。
[0097]
需要说明的是，在本实施例中，上述图5中的趋势预测分析可以在图1中链路分析之前或之后进行，也可单独于图1中的链路分析进行。
[0098]
在又一个实施方式中，当异常事件发生后，可以基于异常事件进行故障日志检索，具体为：事件发生之后，需要检索日志辅助排障时，排障系统根据异常事件id从数据库中查询事件基本信息，获取事件发生的时刻t、服务id、事件类型、日志文件名称、服务pod名称等信息。然后，排障系统基于异常事件的基本信息，调用elasticsearch sdk中的查询接口检索事件相关的容器日志、组件业务日志，崩溃或卡死堆栈，默认检索[t-10min,t+10min]时间段内的相关日志和堆栈，并支持用户自主选择检索的起止时间，排障系统分别将这些日志信息在日志检索页面进行展示。
[0099]
此外，崩溃、卡死异常事件发生时，排障系统采集了异常事件发生时刻正在处理的会话参数，组件崩溃、卡死由这些会话请求导致的可能性极高，因此故障的在线复现主要基于事件发生时刻正在处理的会话请求进行回放，同时也支持用户自定义的请求回放。具体过程为：
[0100]
响应于接收到异常事件在线复现请求，基于异常事件的属性标签(例如，异常事件的id)，获得异常事件发生时刻的会话参数；将会话参数转化成第一调用请求(例如，grpc或http调用请求)，并回放第一调用请求，用户可以逐条或批量回放这些调用请求。
[0101]
响应于第一调用请求无法回放，接收用户构造的自定义请求参数，基于自定义请求参数生成第二调用请求，并回放第二调用请求。具体地，用户可以基于web协议表单构造自定义的请求参数，并逐条或批量回放自定义请求参数生成的调用请求。
[0102]
此外，在异常事件发生后，还可对其进行调试，具体过程可以为：实例部署器基于事件id从排障系统的数据库中查询事件关联的服务id、集群名称、服务pod名称。实例部署器基于服务id、集群名称、服务pod名称从cd系统中获取服务组件的部署编排文件。实例部署器修改服务组件部署编排文件，将节点选择标签修改为指定的目标调试机器，修改环境变量，禁止组件自动向lb注册和上报服务信息，其他信息保持不变，将容器的启动命令修改为bash。基于修改后的服务组件编排文件，通过cd系统的api完成服务组件调试实例的部署。实例部署器通过cd系统查询api获取已经启动的服务pod信息，调用cd系统的管理api，执行exec操作启动服务进程。至此，一个以bash为主进程，并且已经启动了服务进程的容器实例启动完成。调试终端为用户提供易于调试操作的web terminal，当服务的容器实例启动之后，调试终端首先通过cd系统获取服务容器的信息，然后调用docker的api获取http流，基于xtermjs、web socket实现调试操作的执行和回显。调试结束，实例部署器调用cd下线接口完成调试实例和资源的回收。
[0103]
请参阅图6，图6为本技术组件分析装置一实施方式的结构示意图。该组件分析装置包括接收模块20、判断模块22、第一判定模块24和第二判定模块26。
[0104]
其中，接收模块20用于接收第一组件的第一指标的异常信息。判断模块22用于判断第一组件是否未调用其他组件或者第一组件调用的其他组件的第一指标是否均未发生异常；其中，其他组件的个数为至少一个。第一判定模块24与判断模块22连接，用于在判断模块22判断结果为是时，判定第一指标的异常是由于第一组件导致；第二判定模块26与判断模块22连接，用于在判断模块22判断结果为否时，获得被第一组件调用且第一指标发生异常的第二组件，将第二组件作为第一组件，并返回至判断第一组件是否未调用其他组件或者第一组件调用的其他组件的第一指标是否均未发生异常的步骤。
[0105]
在一个实施方式中，本技术所提供的组件分析装置还包括第一获得模块、统计模块和聚类模块；其中，第一获得模块用于获得第一预设时间段内发生异常的多个异常项的异常时序数据；其中，异常项的属性标签包含组件标签和指标标签，不同异常项的组件标签和指标标签中的至少一个不同。统计模块与第一获得模块连接，用于将第一预设时间段划分为多个时间子段，基于每个时间子段进行统计，将发生异常的异常项的自相关权重增加预设值、以及将同时发生异常的两个异常项的互相关权重增加预设值。聚类模块与统计模块连接，用于针对每个异常项，响应于当前异常项的自相关权重超过聚类门限，且与当前异常项相关的互相关权重在预设范围内，则将当前互相关权重对应的两个异常项聚为一类；
其中，预设范围与自相关权重和波动系数相关。
[0106]
可选地，在上述第一获得模块和统计模块之间还可包括初始化模块，用于初始化权重矩阵；其中，多个异常项的个数为n，权重矩阵为n行n列矩阵，且权重矩阵中第i行第j列元素代表第i个异常项与第j个异常项之间的相关权重；当第i个异常项与第j个异常项相同时，相关权重为自相关权重；当第i个异常项与第j个异常项不同时，相关权重为互相关权重。
[0107]
在又一个实施方式中，本技术所提供的组件分析装置还包括：第二获得模块、第三获得模块和相关性判定模块；其中，第二获得模块用于获取第二预设时间段内同一组件的多个指标的第一历史时序数据；其中，组件在第二预设时间段内发生异常或未发生异常。第三获得模块与第二获得模块连接，用于基于同一组件的任意两个指标的第一历史时序数据获得两个指标之间的相关性系数。相关性判定模块与第三获得模块连接，用于响应于相关性系数的绝对值大于或等于第一阈值，则与相关性系数相关的两个指标存在强相关关系。
[0108]
在又一个实施方式中，本技术所提供的组件分析装置还包括第四获得模块、第五获得模块、拟合模块、预测模块和趋势判定模块。其中，第四获得模块用于基于当前周期下的当前时刻设置时间窗口，并获得当前周期之前的多个历史周期下的同一时间窗口内的目标组件的目标指标的第二历史时序数据。第五获得模块与第四获得模块连接，用于基于所有第二历史时序数据获得同一时刻下的多个第二历史时序数据的均值。拟合模块与第五获得模块连接，用于对不同时刻下的所有均值进行拟合以获得拟合函数。预测模块与拟合模块连接，用于基于拟合函数、以及当前周期下的当前时刻之前的多个第二历史时序数据获得当前时刻之后的未来时刻的预测值。趋势判定模块与预测模块连接，用于基于预测值获得目标指标的趋势判定结果。
[0109]
可选地，上述预测模块具体用于基于当前周期下的当前时刻之前的多个第二历史时序数据与对应时刻的均值获得离差；基于拟合函数获得未来时刻下的函数值，并将函数值与离差之和作为预测值。
[0110]
另一可选地，上述趋势判定模块具体用于判断预测值是否位于第一可信区间外、以及离差是否位于第二可信区间外；若预测值位于第一可信区间外或离差位于第二可信区间外，则判定目标指标趋势异常；否则，判定目标指标趋势正常。
[0111]
在又一个实施方式中，本技术所提供的组件分析装置还包括：设置模块，用于设置各个组件的各个指标的输出规范；其中，每个指标的语义明确，不同组件中同一指标的度量单位相同，且指标的度量类型符合预设要求；和/或，每个组件所输出的指标至少包括延迟、流量、错误、饱和度、以及业务对应的自定义指标；和/或，每个指标的属性标签包括组件标签、指标标签以及与业务相关的自定义属性标签；和/或，设置组件上报各个错误码的输出规范；其中，每个错误码的语义明确；和/或，设置组件发生各个异常事件的输出规范；其中，异常事件包括组件崩溃、组件卡死、组件启动异常中至少一个；异常事件的输出数据包括异常事件的属性标签、与异常事件相关联的数据信息、以及异常事件发生时刻的会话参数。
[0112]
在又一个实施方式中，本技术所提供的组件分析装置还包括在线回放模块，用于响应于接收到异常事件在线复现请求，基于异常事件的属性标签，获得异常事件发生时刻的会话参数；将会话参数转化成第一调用请求，并回放第一调用请求；响应于第一调用请求无法回放，接收用户构造的自定义请求参数，基于自定义请求参数生成第二调用请求，并回
放第二调用请求。
[0113]
请参阅图7，图7为本技术电子设备一实施方式的结构示意图。该电子设备包括：相互耦接的存储器32和处理器30，存储器32中存储有程序指令，处理器30用于执行程序指令以实现上述任一组件分析方法。具体地，电子设备包括但不限于：台式计算机、笔记本电脑、平板电脑、服务器等，在此不做限定。此外，处理器30还可以称为cpu(center processing unit,中央处理单元)。处理器30可能是一种集成电路芯片，具有信号处理能力。处理器30还可以是、通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit,asic)、现场可编程门阵列(field-programmable gate array,fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。另外，处理器30可以由集成电路芯片共同实现。
[0114]
请参阅图8，图8为本技术存储装置一实施方式的结构示意图，该存储装置40存储有能够被处理器运行的程序指令400，程序指令400用于实现上述任一组件分析方法。
[0115]
在本技术所提供的几个实施例中，应该理解到，所揭露的方法和装置，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性、机械或其它的形式。
[0116]
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。
[0117]
另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0118]
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本技术各个实施方式方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
[0119]
以上所述仅为本技术的实施例，并非因此限制本技术的专利范围，凡是利用本技术说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本技术的专利保护范围内。