一种应用组件的诊断方法、系统、电子设备及存储介质与流程

1.本技术涉及计算机技术领域，特别涉及一种应用组件的诊断方法、系统、电子设备及存储介质。


背景技术：

2.容器技术是一种比虚拟机技术更加节省计算资源也更加灵活的虚拟化技术。随着容器技术的发展，出现了很多用于对容器进行管理的容器编排引擎。在云时代，分布式微服务架构下的应用日益丰富，纷杂的应用异常问题接踵而至，分析定位问题极其困难，给企业造成了很大的人力维护以及时间成本。
3.慢请求方法为应用组件代码中执行耗时较长的部分，通过对慢请求方法进行定位有利于优化代码、提高应用组件的执行效率，目前尚不存在自动确定应用组件代码中慢请求方法的方案。
4.因此，如何对应用组件中慢请求方法进行自动定位，提高应用组件的运行效率是本领域技术人员目前需要解决的技术问题。


技术实现要素：

5.本技术的目的是提供一种应用组件的诊断方法、一种应用组件的诊断系统、一种电子设备及一种存储介质，能够对应用组件中慢请求方法进行自动定位，提高应用组件的运行效率。
6.为解决上述技术问题，本技术提供一种应用组件的诊断方法，该应用组件的诊断方法包括：
7.向应用组件中注入java采集探针；
8.接收信息采集任务，并根据所述信息采集任务确定待检测span；
9.利用所述java采集探针根据线程栈快照确定每一所述待检测span的耗时时长；其中，所述耗时时长为线程执行所述待检测span对应的代码所消耗的时长；
10.将所述耗时时长大于预设值的待检测span设置为慢请求方法，并将所述慢请求方法对应的代码作为诊断结果进行标记。
11.可选的，在向应用组件中注入java采集探针之后，还包括：
12.在所述应用组件加载jvm时通过匹配类名和方法名修改所述应用组件的类代码，以使每一类代码被执行时在线程栈中记录执行起始时刻和执行结束时刻。
13.可选的，利用所述java采集探针根据线程栈快照确定每一所述待检测span的耗时时长，包括：
14.按照预设周期采集所述线程栈快照；
15.利用所述java采集探针根据当前周期的线程栈快照确定每一所述待检测span的耗时时长。
16.可选的，在利用所述java采集探针根据线程栈快照确定每一所述待检测span的耗
时时长之后，还包括：
17.汇总所有所述待检测span与耗时时长的对应关系；
18.按照待检测span在应用组件中的执行顺序在用户界面中依次显示所有所述待检测span与耗时时长的对应关系。
19.可选的，将所述慢请求方法对应的代码在所述应用组件的代码中进行标记，包括：
20.在可视化平台显示所述应用组件的代码，并将所述慢请求方法对应的代码在所述应用组件的代码中设置为预设颜色。
21.可选的，在将所述慢请求方法对应的代码在所述应用组件的代码中进行标记之后，还包括：
22.向目标设备上传所述慢请求方法对应的代码和耗时时长，以便所述目标设备对所述慢请求方法对应的代码进行修改。
23.可选的，在利用所述java采集探针根据线程栈快照确定每一所述待检测span的耗时时长之后，还包括：
24.根据所有所述待检测span的耗时时长确定所述应用组件的总体耗时；
25.判断所述应用组件的总体耗时是否在标准耗时区间内；
26.若是，则进入将所述耗时时长大于预设值的待检测span设置为慢请求方法的步骤；
27.若否，则将所述待检测span的耗时时长设置为无效数据，并进入利用所述java采集探针根据线程栈快照确定每一所述待检测span的耗时时长的步骤。
28.本技术还提供了一种应用组件的诊断系统，该系统包括：
29.探针注入模块，用于向应用组件中注入java采集探针；
30.span确定模块，用于接收信息采集任务，并根据所述信息采集任务确定待检测span；
31.耗时确定模块，用于利用所述java采集探针根据线程栈快照确定每一所述待检测span的耗时时长；其中，所述耗时时长为线程执行所述待检测span对应的代码所消耗的时长；
32.慢请求标记模块，用于将所述耗时时长大于预设值的待检测span设置为慢请求方法，并将所述慢请求方法对应的代码作为诊断结果进行标记。
33.本技术还提供了一种存储介质，其上存储有计算机程序，所述计算机程序执行时实现上述应用组件的诊断方法执行的步骤。
34.本技术还提供了一种电子设备，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器调用所述存储器中的计算机程序时实现上述应用组件的诊断方法执行的步骤。
35.本技术提供了一种应用组件的诊断方法，包括：向应用组件中注入java采集探针；接收信息采集任务，并根据所述信息采集任务确定待检测span；利用所述java采集探针根据线程栈快照确定每一所述待检测span的耗时时长；其中，所述耗时时长为线程执行所述待检测span对应的代码所消耗的时长；将所述耗时时长大于预设值的待检测span设置为慢请求方法，并将所述慢请求方法对应的代码作为诊断结果进行标记。
36.本技术向应用组件中注入java采集探针，应用组件包括多个span的代码。在接收
到信息采集任务之后，通过java采集探针对待检测span的耗时时长进行检测，并将耗时时长大于预设值的待检测span设置为慢请求方法，进而将慢请求方法对应的代码进行标记以实现对应用组件中慢请求方法的定位。本技术借助低性能消耗、低入侵性的java采集探针确定慢请求方法，可以应用组件中慢请求方法进行自动定位，提高应用组件的运行效率。本技术同时还提供了一种应用组件的诊断系统、一种电子设备和一种存储介质，具有上述有益效果，在此不再赘述。
附图说明
37.为了更清楚地说明本技术实施例，下面将对实施例中所需要使用的附图做简单的介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
38.图1为本技术实施例所提供的一种应用组件的诊断方法的流程图；
39.图2为本技术实施例所提供的一种基于线程栈快照的代码级慢请求分析方案的原理示意图；
40.图3为本技术实施例所提供的一种应用组件的诊断系统的结构示意图。
具体实施方式
41.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
42.下面请参见图1，图1为本技术实施例所提供的一种应用组件的诊断方法的流程图。
43.具体步骤可以包括：
44.s101：向应用组件中注入java采集探针；
45.其中，本实施例可以用于部署有kubernetes的电子设备，上述应用组件具体为kubernetes中部署的应用组件，用户可以在页面中选择需要监测的应用组件，并在该选中的应用组件中注入java采集探针。kubernetes是用于自动部署、扩展和管理容器化应用程序的开源系统。
46.java采集探针又称java探针(java agent)，基于bytebuddy字节码增强技术实现。java采集探针是一种可以动态修改java字节码的技术。java类编译之后形成字节码被jvm执行，在jvm执行这些字节码之前获取这些字节码信息，并且通过字节码转换器对这些字节码进行修改，来完成一些额外的功能。java采集探针通过jvm的agent参数加载，并在程序启动时拦截指定的方法来收集数据，并定时上报给平台后端。byte buddy是一个开源java库，提供了一套类型安全的api和注解，帮助开发人员轻松实现负载的字节码操作。
47.s102：接收信息采集任务，并根据所述信息采集任务确定待检测span；
48.其中，本实施例中的应用组件的代码中包括多个span(区域)，每一span对应一部分应用组建的代码，即：应用组件的代码按照span被划分为多个代码区域，每一span对应的代码用于实现应用组件的部分功能。
49.上述信息采集任务可以为用户下发的任务，也可以为其他设备发送的任务；任务中可以包括待检测span的名称、监控间隔(即周期)、以及用于评价待检测span的耗时时长是否超时的耗时阈值(即本文中的预设值)。
50.信息采集任务为用于采集特定span的耗时时长的任务，在接收到耗时时长后，可以根据需要进行慢请求方法检测的span的名称确定待检测span。上述待检测span的数量可以为任意值。
51.s103：利用所述java采集探针根据线程栈快照确定每一所述待检测span的耗时时长；
52.其中，在应用组件的代码被执行时，每一类代码的执行起始时刻和执行结束时刻记录至线程栈中，因此java采集探针可以根据线程栈快照中记录的执行起始时刻和执行结束时刻确定每一所述待检测span的耗时时长。上述耗时时长为线程执行所述待检测span对应的代码所消耗的时长；具体的，待检测span对应的代码中包括任意数量个类代码，根据线程栈快照中记录的执行起始时刻和执行结束时刻确定可以确定每一类代码的耗时时长，进而将类代码的耗时时长求和得到所述待检测span的耗时时长。
53.作为一种可行的实施方式，在向应用组件中注入java采集探针之后，还可以在所述应用组件加载jvm时通过匹配类名和方法名修改所述应用组件的类代码，以使每一类代码被执行时在线程栈中记录执行起始时刻和执行结束时刻。
54.s104：将所述耗时时长大于预设值的待检测span设置为慢请求方法，并将所述慢请求方法对应的代码作为诊断结果进行标记。
55.其中，在得到每一待检测span的耗时时长后，可以将耗时时长与对应的预设值进行对比；如果耗时时长大于预设值，则说明待检测span对应代码的耗时过长，判定待检测span的代码为慢请求方法对应的代码，待检测span设置为慢请求方法，以便将所述慢请求方法对应的代码在所述应用组件的代码中进行标记。
56.本步骤可以在可视化平台显示所述应用组件的代码，并将所述慢请求方法对应的代码在所述应用组件的代码中设置为预设颜色(如红色)。
57.具体的，本实施例可以通过在kubernetes上部署被监测的应用，注入采集数据的java采集探针并定时上报线程栈，平台后端聚合汇总监测数据，实现全链路追踪和慢请求信息的展示。本实施例通过java采集探针自动注入并获取慢请求采集任务，根据任务详情的配置参数，按照监控间隔定时检测和采集线程栈，当匹配的span的耗时大于设置的阈值时将上报给平台后端，最终将慢请求方法展现在页面中。本实施例既节省了人力和时间成本，也方便了开发人员在线快速分析并精确定位慢请求的根源。上述实施例可以包括如下几个步骤：(1)用户在平台应用界面创建java应用组件后，则执行(2)；如果已注入java采集探针则执行(3)；(2)对部署的应用注入java采集探针；(3)新建慢请求采集任务，添加要采集的span名称、持续监控事件、span耗时阈值、监控间隔；(4)请求应用服务，制造访问流量进行数据采集及监测；(5)在方法级链路追踪页面，点击应用组件查看链路追踪详情，结合(3)中的关联的慢请求采集任务，耗时超过所设置阈值的方法会以红色字体现在追踪链路中。
58.本实施例向应用组件中注入java采集探针，应用组件包括多个span的代码。在接收到信息采集任务之后，通过java采集探针对待检测span的耗时时长进行检测，并将耗时
时长大于预设值的待检测span设置为慢请求方法，进而将慢请求方法对应的代码进行标记以实现对应用组件中慢请求方法的定位。本实施例借助低性能消耗、低入侵性的java采集探针确定慢请求方法，可以应用组件中慢请求方法进行自动定位，提高应用组件的运行效率。
59.作为对于图1对应实施例的进一步介绍，可以java采集探针可以按照预设周期采集线程栈快照并更新每一待检测span的耗时时长，具体过程如下：按照预设周期采集所述线程栈快照；利用所述java采集探针根据当前周期的线程栈快照确定每一所述待检测span的耗时时长。
60.作为对于图1对应实施例的进一步介绍，在利用所述java采集探针根据线程栈快照确定每一所述待检测span的耗时时长之后，还可以汇总所有所述待检测span与耗时时长的对应关系；按照待检测span在应用组件中的执行顺序在用户界面中依次显示所有所述待检测span与耗时时长的对应关系。通过上述方式有利于工作人员优先处理耗时较长的慢请求方法，提高应用组件的代码优化效率。
61.进一步的，在将所述慢请求方法对应的代码在所述应用组件的代码中进行标记之后，还可以向目标设备上传所述慢请求方法对应的代码和耗时时长，以便所述目标设备对所述慢请求方法对应的代码进行修改。通过上述过程能够实现慢请求方法的自动定位和自动修复。
62.可以理解的是，应用组件的运行状态受多种因素干扰，当其他组件占用较多资源时，应用组件中各个span的耗时将会增加，因此作为一种可行的实施方式，还可以存在判断应用组件的总体耗时是否正常的操作，以便在应用组件正常运行的情况下进行慢请求方法定位，具体过程如下：
63.步骤1：利用所述java采集探针根据线程栈快照确定每一所述待检测span的耗时时长之后，根据所有所述待检测span的耗时时长确定所述应用组件的总体耗时；
64.步骤2：判断所述应用组件的总体耗时是否在标准耗时区间内；若是，则进入图1对应实施例中s104将所述耗时时长大于预设值的待检测span设置为慢请求方法的步骤；若否，则进入步骤3；
65.步骤3：将所述待检测span的耗时时长设置为无效数据，并进入s103中利用java采集探针根据线程栈快照确定每一所述待检测span的耗时时长的步骤。
66.下面通过在实际应用中的实施例说明上述实施例描述的流程，本实施例提供了一种基于线程栈快照的代码级慢请求分析方案，能够帮助应用的开发人员在线快速分析和诊断代码级的慢请求问题。本实施例基于线程栈快照在分布式链路追踪的基础上进行更深层次下探到编程语言层面的代码级性能剖析方法，借助低性能消耗、低侵入性的探针采集方法的上下文信息，并按照检测间隔采集线程栈信息，最终上报汇总展现在调用链页面中，方便快速在线诊断应用的慢请求问题，降低了慢请求的精确定位难度，极大地节省了人力和时间成本。上文中，应用指：一组可对外提供服务的应用组件及相关附属信息的集合，在实际使用场景中可以对应用户的具体应用系统，通常包括一个或多个应用组件、访问地址、安全组等；分布式链路追踪指：为分布式应用的开发者提供了完整的调用链路还原、调用请求量统计、链路拓扑、应用依赖分析等功能的工具。
67.请参见图2，图2为本技术实施例所提供的一种基于线程栈快照的代码级慢请求分
析方案的原理示意图，本方案的实现依赖于kubernetes上部署被监测的应用组件，采集数据的java采集探针，收集并分析监测数据的平台后端，展示全链路追踪的界面。图2中的平台后端用于支持数据聚合、数据分析以及驱动数据流从探针到用户界面的流程；用户界面ui用于从平台后端获取数据并进行整合，并实时展示应用的全链路追踪信息及慢请求的界面。
68.本方案的基本思想如下：用户在页面选择要监测的应用组件，注入java采集探针；新建慢请求采集任务(即信息采集任务)，添加要采集的span名称、持续监控事件、span耗时阈值、监控间隔；请求应用服务，制造访问流量进行数据采集及监测；在方法级链路追踪页面，点击目标任务查看慢请求详情。本方案的具体实施过程如下：
69.步骤1、用户在平台应用界面创建java应用组件，并注入java采集探针。
70.步骤2、应用程序加载jvm时，基于java字节码增强技术，通过agent在类被加载入java虚拟机时匹配类名和方法名动态修改类代码。
71.步骤3、新建慢请求采集任务(即信息采集任务)，添加要采集的span名称、持续监控事件、span耗时阈值、监控间隔。
72.步骤4、java采集探针获取到慢请求采集任务后，会根据任务详情的配置参数，按照监控间隔定时检测和采集线程栈快照，当匹配的span的耗时大于设置的阈值时将上报给平台后端。
73.进一步的，在检测到慢请求方法后，可以缩短检测和采集线程栈快照的监控间隔，提高检测慢请求方法的准确度。
74.步骤5、平台后端接收到探针上报的数据后会进行聚合和汇总，通过trace id将整个链路串联起来，并将慢请求span特殊标记保存到存储空间中。
75.用户在方法级链路追踪页面会查看到整个应用组件的链路信息，以红色字体显示的方法名即为耗时超过所设置阈值的span，可以针对性的优化这些方法。
76.如图2所示，将java采集探针的探测代码注入至应用组件中，以便对方法a进行方法增强。用户可以向平台后端下创建的任务，java采集探针从平台后端获取任务并检测和采集线程栈快照，并在span的耗时大于阈值时按照监控间隔采集线程栈。java采集探针可以向平台后端上报线程栈中采集的各span的耗时时长。平台后端可以将耗时时长大于阈值的span设置为慢请求方法，还可以将上述耗时时长进行存储。
77.本方案提供了一种从代码层级帮助应用的开发人员快速精准定位以及分析和诊断慢请求的方案。通过本方案基于java字节码增强技术将追踪代码自动注入到需要采集的应用的代码中，利用线程栈快照，并对方法执行情况进行分析和汇总，结合分布式链路追踪span上下文，对代码执行速度进行估算，最终将慢请求方法展现在页面中。本方案既节省了人力和时间成本，又可以对部署的应用进行实时的性能诊断，方便开发人员在线快速分析并精确定位慢请求的根源，具有较高的应用价值。
78.请参见图3，图3为本技术实施例所提供的一种应用组件的诊断系统的结构示意图，该系统可以包括：
79.探针注入模块301，用于向应用组件中注入java采集探针；
80.span确定模块302，用于接收信息采集任务，并根据所述信息采集任务确定待检测span；
81.耗时确定模块303，用于利用所述java采集探针根据线程栈快照确定每一所述待检测span的耗时时长；其中，所述耗时时长为线程执行所述待检测span对应的代码所消耗的时长；
82.慢请求标记模块304，用于将所述耗时时长大于预设值的待检测span设置为慢请求方法，并将所述慢请求方法对应的代码作为诊断结果进行标记。
83.本实施例向应用组件中注入java采集探针，应用组件包括多个span的代码。在接收到信息采集任务之后，通过java采集探针对待检测span的耗时时长进行检测，并将耗时时长大于预设值的待检测span设置为慢请求方法，进而将慢请求方法对应的代码进行标记以实现对应用组件中慢请求方法的定位。本实施例借助低性能消耗、低入侵性的java采集探针确定慢请求方法，可以应用组件中慢请求方法进行自动定位，提高应用组件的运行效率。
84.进一步的，还包括：
85.代码修改模块，用于在向应用组件中注入java采集探针之后，在所述应用组件加载jvm时通过匹配类名和方法名修改所述应用组件的类代码，以使每一类代码被执行时在线程栈中记录执行起始时刻和执行结束时刻。
86.进一步的，耗时确定模块303，用于按照预设周期采集所述线程栈快照；还用于利用所述java采集探针根据当前周期的线程栈快照确定每一所述待检测span的耗时时长。
87.进一步的，还包括：
88.显示模块，用于在利用所述java采集探针根据线程栈快照确定每一所述待检测span的耗时时长之后，汇总所有所述待检测span与耗时时长的对应关系；还用于按照待检测span在应用组件中的执行顺序在用户界面中依次显示所有所述待检测span与耗时时长的对应关系。
89.进一步的，慢请求标记模块304用于在可视化平台显示所述应用组件的代码，并将所述慢请求方法对应的代码在所述应用组件的代码中设置为预设颜色。
90.进一步的，还包括：
91.信息上传模块，用于在将所述慢请求方法对应的代码在所述应用组件的代码中进行标记之后，向目标设备上传所述慢请求方法对应的代码和耗时时长，以便所述目标设备对所述慢请求方法对应的代码进行修改。
92.进一步的，还包括：
93.组件运行监测模块，用于在利用所述java采集探针根据线程栈快照确定每一所述待检测span的耗时时长之后，根据所有所述待检测span的耗时时长确定所述应用组件的总体耗时；还用于判断所述应用组件的总体耗时是否在标准耗时区间内；若是，则启动所述慢请求标记模块304对应的工作流程；若否，则将所述待检测span的耗时时长设置为无效数据，并启动耗时确定模块303对应的工作流程。
94.由于系统部分的实施例与方法部分的实施例相互对应，因此系统部分的实施例请参见方法部分的实施例的描述，这里暂不赘述。
95.本技术还提供了一种存储介质，其上存有计算机程序，该计算机程序被执行时可以实现上述实施例所提供的步骤。该存储介质可以包括：u盘、移动硬盘、只读存储器(read
‑
only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种
可以存储程序代码的介质。
96.本技术还提供了一种电子设备，可以包括存储器和处理器，所述存储器中存有计算机程序，所述处理器调用所述存储器中的计算机程序时，可以实现上述实施例所提供的步骤。当然所述电子设备还可以包括各种网络接口，电源等组件。
97.说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本技术原理的前提下，还可以对本技术进行若干改进和修饰，这些改进和修饰也落入本技术权利要求的保护范围内。
98.还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的状况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。