CN107968833A - 一种基于执行路径的云应用性能监测方法 - Google Patents

Abstract

发明涉及一种基于执行路径的云应用性能监测方法。提出了基于程序分析的自动化细粒度监测算法，实现了监测粒度的自动控制，在无需开发人员配置的情况下，对事务在服务节点上的执行过程进行更细粒度的监测，为了避免产生大量的冗余数据，植入的拦截器能够利用运行时信息对监测进行开关。

Description

一种基于执行路径的云应用性能监测方法

技术领域

本发明涉及一种基于执行路径的云应用性能监测方法，属于软件技术领域。

背景技术

当前，随着云计算、虚拟化及相关运维管理工具的产生，有着更低耦合度和更好扩展性的微服务架构成为主流。在微服务架构下，上层应用的用户访问请求需要经过多种服务组件才能完成。例如：Google Search在用户输入检索关键词之后会调用拼写检查、自动补全、及时搜索、广告等一系列服务最终将结果反馈给用户。这些服务组件由不同的开发团队维护，部署在数以百记的服务器上，甚至跨越数个集群。应用程序性能监测分析可以追溯到早期程序性能分析器的研究，其中调用关系图的生成最早被用于编译器开发中。调用关系图是用一个有向图，更准确的说是流程图来表示程序中子例程之间的调用关系。编译器通过分析待编译源代码中的调用关系图，可以找到需要做内联优化的代码片段。调用关系图的分析是对程序理解的一个基本手段，可以用来追踪方法的调用次数，执行时间，或者是子例程间值的流动。调用关系图可以是动态的或静态的，动态的调用关系图是对程序执行的记录，这种思路往往用于程序分析器的开发。同时调用关系图的准确性也可以是多样的，对程序运行时调用关系图的准确记录，意味着程序执行的完整上下文信息，调用栈中的每个执行单元都会用一个节点在调用关系图中表示出来。一个上下文高度敏感的调用关系图被称为调用上下文树。最低准确性的调用关系图对执行上下文不敏感，粒度控制在子例程级别。

基于调用关系图的技术思路，出现了大量面向企业应用的工具产品，通过调用关系图、运行时系统提供的钩子实现对程序进行多角度分析，如线程信息、调用栈信息、方法执行时间、异常的堆栈信息等。这类工具往往用于开发环境下的本地调试，与集成开发环境的有机结合能够帮助开发人员对性能问题进行隔离和修复。面向方面编程对调用关系图分析工具的实现，提供了编程范式的指导。通过对切入点和通知的定义，能很好实现节点的产生过程。而AOP的实现需要代码修改来实现代理，于是推动语言发展了动态代理和字节码插桩技术，这一切对性能分析工具提供了必要的理论基础和技术手段。在本文中，事务指的是用户在客户端发起页面请求，经过后端多个服务组件的一系列处理过程得到响应并经过网络传输到达浏览器，浏览器开始解析HTML文档并执行JavaScript完成整个页面的渲染，达成一个业务要求。端到端的性能监测指的就是事务过程中客户端和服务端处理过程中性能数据的收集和管理。然而，传统单机的程序分析工具难以满足微服务架构应用执行过程监测的需求，由此产生了新的系统形态概念——应用性能管理。现有开源性能监测应用和传统的性能分析方法具有以下局限性：

仅能用于本地程序的性能调试，无法对分布式应用进行监测：利用调试接口性能监测工具能够获取被监测程序运行时的堆栈信息、内存使用信息等，与IDE进行集成用于开发时的本地调试可以对简单场景进行测试。但是缺乏分布式应用整体监测的能力，无法对线上系统进行全面监测。

配置繁琐，维护代价高：针对粗粒度的问题，传统工具也支持用户配置的方式对插桩粒度进行调整。但随着应用复杂度的提高，配置的维护代价变得昂贵。不仅依赖于应用开发人员对于系统的理解，手工的方式也很难避免错误。

不具备客户端监测的功能：运行时插桩使得监测代理与应用解耦，有效降低了服务端监测代理的开发成本。同时服务端是高度受控的，部署在受控的硬件环境、系统和网络环境中，监测数据会更有效。这也导致了传统APM工具不够关注客户端的监测，而真实用户体验不仅受到服务器端处理性能的影响。

这些局限性使得现有性能监测工具往往只能用于开发环境中的性能调试，或者需要开发人员维护复杂的监测配置，没有显著降低性能问题的修复周期，同时也不能帮助运维和开发人员理解系统端到端的应用表现。

发明内容

本发明的目的：提出一种支持事务追踪、分布式架构、低运行时开销、易于水平扩展的端到端的分布式应用性能监测方法。

本发明的原理：建立分析性能监测工具数据模型，提出面向分布式应用事务追踪的数据结构，并结合程序插桩的技术手段加以实现。提出了一种基于程序分析的动态插桩算法，具有避免用户对于监测应用代码的配置，实现细粒度追踪自动化的特点。

本发明技术解决方案：一种基于执行路径的云应用性能监测方法，其特点在于实现步骤如下：

对于大规模分布式应用，一个事务的执行过程会涉及到集群中的多个节点甚是跨越集群边界，进行多个服务调用。事务的执行路径可能会因为请求参数的不同而有所差异，所以对于执行路径进行追踪也是一个动态的过程，随着请求次数的增加而收敛。尽可能的对出现异常的事务执行进行记录，首先需要将事务相关的所有服务调用的上下文信息进行记录，然后需要将所有相关的服务调用片段进行关联。

第一步，建立追踪树。

采用基于标注的事务追踪方法，用树来表示一个分布式应用事务的执行过程。对于事务给予集群内的唯一标识，服务调用有着事务范围内的唯一标识，并通过调用者id进行相邻服务调用的关联，并以服务调用为基本单元进行记录和存储。以查询的方式对完全的事务调用进行刻画，即通过节点构造树的过程。这与给出的span在追踪树中的关联方式一样，图中对于SpanId是自增的有着极强的暗示意味，但事实上这是不合理的，如果一棵树中出现了相同的SpanId，是没有办法正确构造出追踪树的。SpanId应该在追踪树中这个范围内唯一。下表中给出追踪树中的主要信息。

TransactionId通过监测代理本地产生，避免了中心化生机制带来的性能和网络问题，生成方式为AgentId^AgentStartTime^AgentSequence，AgentId监测代理的配置项，AgentStartTime是Agent的启动时间，AgentSequence是自增序列，这种方式能极快的生成TransactionId，同时能有效避免TransactionId的冲突。用中心化的方式，比如用ZooKeeper来产生，可能产生网络问题，同时性能也不满足线上系统的监测。SpanId由监测代理的ThreadLocal对象来产生随机数，用64位长整型表示，生成时仅避免与ParentSpanId相同，同样也是出于性能考虑的结果。

第二步，生成Span结构。

Span是整个事务追踪过程中的基本单元，因此解决了Span的生成问题就解决了分布式应用追踪的问题。分布式应用的事务可以看作是一系列RPC的集合，一个Span同时也对应着一个RPC的处理过程。基于标注的方式需要植入代码。开发独立的用于监测的API提供给应用层，这样对已有应用无法监测，而且实现不了应用透明性。为了实现前文提到的对运行时库和开发人员透明，可以使用字节码插桩技术来实现。利用Java5的特定JavaInstrumentation Interface，可以用来开发Java Agent，在JVM进行类加载的时候对字节码进行插桩。

Java Agent是一个包含premain()方法或者被称为agent main方法的jar包，通过利用Instrumentation向JVM注册ClassFileTransformer来实现运行时的字节码增强。所有被JVM加载的类，在对类文件进行定义时，都会调用ClassFileTransformer的transform()方法，根据一定规则，可以向指定类或者方法作为目标进行Interceptor的注入。Interceptor用于Span数据的生成，分别在before()和after()方法中记录时间戳，而JavaAgent则是监测代理的服务端实现。监测代理将声场的Span以一定策略发送给Collector，后者将Span按照TransactionId进行持久化。

第三步，生成追踪树。

追踪树是Span的集合，通过一系列TransactionId关联的Span可以生成一颗追踪树，用于表示一个分布式应用事务。监测代理首先不应该，其次也不可能实现追踪树的生成，前者是因为性能开销的考虑，后者是因为监测代理无法获取TransactionId关联的所有Span。而Collector无法确定追踪树的计算时机，因为无法确定一个事务的最后一个Span。所以追踪树生成的计算被延迟到用户通过接口查看它时才发生，计算时根据TransactionId选出对应行的Span列族，对于所有Span。

首先确定生成树的根，如果根据ParentSpanId确定根Span，如果有且仅有一个，则根据此Span作为根进行树的生成。根据此条件进行判断可能出现0个或者多个根Span。0个意味着监测代理还没有发送根Span，Collector没有收到根Span或者向HBase进行存储时发生错误，多个意味着出现了TransactionId出现了冲突。Web接口会产生一个时间戳参数作为判断根Span的另一个条件，如果Span的时间戳能与之匹配，则同样认为是根Span，确定根之后递归的完成追踪树的构建。

本发明与现有技术相比具有如下优点：

1 、针对细粒度自动化追踪、端到端性能监测等关键技术提出了解决方案，提高了系统用于性能分析的有效性；

2、提出了基于程序分析的细粒度自动化追踪算法，实现了更智能的监测粒度控制。

附图说明

图1为云应用性能监测系统架构。

具体实施方式

以下结合具体实施例和附图对本发明进行详细说明，如图1所示，本发明实施例方法流程：

系统的总体目标是实现一个可支持线上系统的端到端分布式应用性能监测工具，对运行时库和开发人员透明。端到端的分布式应用性能监测工具主要分为服务端Agent、浏览器端Agent、数据采集器Collector和Web管理界面。

服务端代理具备服务类型识别、插件管理、拦截器管理和监测数据采集管理的功能。服务端Agent在启动的时候会加载插件，并通过插件里定义的元数据进行服务类型的识别，如Tomcat应用、Jetty应用、Memcached缓存，这将用于分布式应用中组件拓扑的绘制。插件同时定义了拦截器的生成规则，并由拦截器中心进行统一管理，拦截器会产生Span，并由监测数据采集模块发送给Collector。

浏览器代理与服务端代理功能类似，但是功能更简单，如不会获取方法签名。

Collector主要有收集监测数据和路由Web消息的功能。对于监测数据和监测元数据（应用名称、代码摘要等），Collector统一收集并利用HBase进行持久化存储。服务端代理会对线程信息进行监测，并在Web管理界面实时展示。线程信息并不会进行持久化，而是经过Collector转发送达Web管理界面。

Web管理界面是对运维开发人员的管理和监测数据的可视化展示，通过界面进行人员信息的添加可以做到预警，当应用遭遇性能问题时可以用邮件的方式及时通知开发和运维人员。在可视化方面主要有组件拓扑图、活动线程实时监测、事务散点图、事务调用栈信息以及JVM监视器。

Claims (1)

1.方法特征在于实现步骤如下：

第一步，建立追踪树：采用基于标注的事务追踪方法，用树来表示一个分布式应用事务的执行过程；对于事务给予集群内的唯一标识，服务调用有着事务范围内的唯一标识，并通过调用者id进行相邻服务调用的关联，并以服务调用为基本单元进行记录和存储；以查询的方式对完全的事务调用进行刻画，即通过节点构造树的过程；

第二步，生成Span结构：分布式应用的事务可以看作是一系列RPC的集合，一个Span同时也对应着一个RPC的处理过程；基于标注的方式需要植入代码，开发独立的用于监测的API提供给应用层，这样对已有应用无法监测，而且实现不了应用透明性；为了实现前文提到的对运行时库和开发人员透明，可以使用字节码插桩技术来实现；

第三步，生成追踪树：追踪树是Span的集合，通过一系列TransactionId关联的Span可以生成一颗追踪树，用于表示一个分布式应用事务；追踪树生成的计算被延迟到用户通过接口查看它时才发生，计算时根据TransactionId选出对应行的Span列族；确定生成树的根，如果根据ParentSpanId确定根Span，如果有且仅有一个，则根据此Span作为根进行树的生成。