应用 SQL 性能风险识别与预警，携程金融支付 AppTrace 落地实践

一、应用性能问题

在我们过往的测试及生产问题的分析中，常常可以发现应用执行数据库操作导致出现性能问题的情况。而这些情况中最常见的原因是 SQL 执行时，索引未能恰当的使用，例如未建索引、SQL 条件没有利用索引、索引失效等。这些问题往往占据了性能问题的 60%~80%原因。

为了应用在性能方面能安全上线，通常需要专业的性能测试及分析人员通过冗长的测试过程来进行保障，对测试人员、数据环境、测试时间等多个方面均提出了较高的要求。而组织内部往往缺乏这样的专业人员，同时互联网模式下高速的系统迭代上线也很难为专门的性能测试开展提供充足的时间资源。

为了解决这些问题，我们提出了 AppTrace 这套系统的设计。期望以简单、自动化、高效的手段达成在测试阶段把应用性能的这 60%~80%的问题都解决掉。

二、AppTrace 目标

• 发现应用性能问题中最主要的原因之一：慢 SQL

• 以简便的手段获取应用可能存在的 SQL 性能问题点

• 降低测试人员发现慢 SQL 的技术难度

• 使应用 SQL 的性能侦测覆盖率达到近乎 100%

• 侦测分析结果与生产真实情况接近

三、目标实现基本过程

1）功能测试和接口测试时，AppTrace 抓取测试执行过程中的所有 SQL。通过功能和接口测试实现对应用功能的全量覆盖，使得应用中的 SQL 几乎都会被抓取到。

2）AppTrace 将抓取到的 SQL 请求到生产 mirror 库中去获取执行计划，以此获得与生产近似的执行分析结果。

3）对分析结果为疑似存在性能问题的 SQL 进行告警，由人工确认、优化。

四、AppTrace 原理及实现

4.1 AppTrace 结构简介

AppTrace 分为三大组件：

• CPTrace（CtripPaymentTrace）组件 ：该组件基于 BTrace 改造而来，用于抓取应用执行的 SQL 语句，并进行存储。此组件核心为两部分：

• CPTraceClient：作用为编译通用监控脚本，使得 CPTrace Agent 具备抓取应用 SQL 的能力。

• CPTraceAgent：功能为抓取应用的 SQL，并将其持久化保存。

• AppTraceAgent 组件 ：该组件用于将 CPTrace 抓取到的 SQL 进行解析，并通讯至 AppTrace Server 供其进行分析（采用 MQ 进行数据传输）。

• AppTraceServer 组件 ：对接收到的 SQL 调用生产 mirror 库的执行计划进行解析，对解析结果按照预设规则进行性能风险判定。

4.2 AppTrace 处理流程

如上图所示，通过这三大组件的协同工作将应用的 SQL 自动捕获并持久化存储，然后交由 AppTrace Server 完成执行计划的分析，根据分析结果并结合风险告警规则进行告警通知。

4.3. AppTrace 的技术方案

1）动态追踪目标系统中的 SQL

使用安全的 JVM 动态追踪工具 Btrace, 按照 Btrace 语法编写追踪的 SQL Java 脚本,指定方式如下：

• 方法上的注解 @OnMethod

Btrace 使用 @OnMethod 注解定义需要分析的方法入口，在 @OnMethod 注解中，需要指定 class、method 以及 location 等，class 表明需要监控的类，method 表明需要监控的方法。

• 属性上的注解

TLS 将一个脚本变量与一个 ThreadLocal 变量关联。

将 Btrace 脚本编译成字节码文件，执行命令 btrace <pid>btrace 脚本，Attach API 把代理包动态附加到待监控的 JVM 上去，通过代理包解析 SQL Java 脚本。使用 ASM(Java 字节码操作和分析框架)修改类 java.sql.Connection，java.sql.PreparedStatement，利用 JDK Instrumentation 动态替换类，最后将追踪到的 SQL 以及参数记录到 sqltrace.txt 文件中，追踪的 SQL 如下：

2）分析 SQL 风险逻辑与追踪 SQL 逻辑的隔离

通常情况下，追踪的应用部署成功后自动运行 SQL 追踪插件（apptrace-agent），SQL 追踪插件主要关注的是监控应用 SQL 以及参数，并且进行 SQL 与参数的匹配，最后将 SQL 语句存储在高速读写中间件里。对于分析队列中的 SQL 是否有性能风险以及告知相关负责人优化 SQL，这一部分逻辑，交由 SQL 风险分析系统（apptrace-server）去处理。

3）分析执行计划结果以及推送告警邮件

通过 DB 提供的 explain 接口在生产备库执行 explain sql，根据危险阈值分析执行计划结果确定 SQL 性能风险。对于分析执行计划的危险阈值需要可配置，我们提供了 SQL 风险告警客户端，危险阈值模块支持人工灵活修改。那么对于存在风险的 SQL,采用 soa email 方式推送告警到测试人员以及开发负责人，直到 SQL 优化无风险后终止告警。

4.4 性能分析判定手段简析

对于 SQL 性能是否存在问题的基础判定数据，我们采用了 SQL 的执行计划结果。以此数据结合我们的风险阈值进行判定。

当系统上线后数据库的记录不断增加，之前写的一些 SQL 语句或者一些 ORM 操作效率变得非常低。我们会考虑 SQL 优化，其优化大致的流程包括：

• 定位执行效率低的 SQL 语句（定位）

• 分析为什么这段 SQL 执行的效率比较低（分析）

• 根据第二步分析的结果采取优化措施（解决）

而 EXPLAIN 命令的作用就是帮助我们分析 SQL 的执行情况，属于第二步。说的规范一点就是：EXPLAIN 命令是查看查询优化器如何决定执行查询的主要的方法。学会解释 EXPLAIN 将帮助我们了解 SQL 优化器是如何工作的。执行计划可以告诉我们 SQL 如何使用索引，连接查询的执行顺序，查询的数据行数，所以通过 EXPLAIN 可以反映出 SQL 存在的风险，以及指引我们优化方向。

4.5 SQL 捕获手段简析

AppTrace 系统对 SQL 捕获的核心采用的是 BTrace，根据自身需求对其进行了部分改写。

BTrace 是一个为 Java 平台开发的安全的动态追踪工具，它为用户提供了很多注解。依靠这些注解，我们可以编写 BTrace 脚本（简单的 Java 代码），它可以在不修改原有代码的情况下动态地追踪 java 运行程序，通过 hotswap 技术，动态将跟踪字节码注入到运行类中，而不必深陷于 ASM 对字节码的操作中不可自拔。同时它对运行代码侵入较小，对性能上的影响可以忽略不计，所以通过 Btrace 在不影响应用运行前提下实时追踪程序运行的 SQL，是我们后续分析 SQL 的基础。

五、小结

追踪插件与发布平台系统集成完成，应用发布成功后自动启动插件，无需人工部署插件即可追踪 SQL。目前许多应用接入了追踪插件，AppTrace 确实识别到 SQL 风险并得到了解决，同时我们也发现了些问题。随着接入的应用越来越多，后端服务处理的数据量越来越大，服务需要进一步拓展与迭代，相信在后面的迭代中 AppTrace 识别 SQL 风险能力更精准、更全面。

作者介绍：

Sedro，携程资深测试工程师，专注于测试技术探索及测试工具研发。

本文转载自公众号携程技术（ID：ctriptech）。

原文链接：

应用SQL性能风险识别与预警，携程金融支付AppTrace落地实践