Z
文章
59
分类
14
评论
8

Arthas TT命令：无日志场景下的请求异常排查

| 工具 • 运维 • 基础 •
字数总计 12790 | 阅读时长 31分钟 | 阅读量 3

前言

在与客户进行系统对接的过程中，确保接口的稳定和正确运行是至关重要的。然而，实际情况中常常会遭遇各种问题，其中接口返回异常，如 500 Internal Server Error，却没有打印相关请求日志的情况，让开发人员头疼不已。传统的问题排查手段，大多依赖于日志回溯。通过详细的日志信息，我们可以追踪请求的处理流程，查看各个环节的输入输出数据，从而定位问题的根源。但当日志缺失时，这条重要的排查路径就被切断了。

在这种困境下，我们急需一种新的解决方案，能够在没有日志的情况下，深入了解接口请求的处理过程。这时候，Arthas 的 tt 命令（TimeTunnel）就展现出了它强大的能力。它就像是一个时光隧道，能够记录方法调用的全量数据，包括入参、返回值以及异常信息。通过这些详细的记录，我们可以在请求出现异常后，回溯到当时的方法调用现场，精准定位问题出现在请求处理过程中的哪一个环节。

TT 命令核心能力与适用场景

命令核心价值

TT 命令就像是一个精密的记录仪器，在方法调用的瞬间，它迅速启动，实时捕获指定方法的每次调用记录 ，并将这些关键信息存储下来。这些信息包括：

  1. INDEX：每一次方法调用都会被分配一个唯一的调用编号，就如同每个人都有独一无二的身份证号码，这是精准定位某次调用的关键标识。

  2. TIMESTAMP：精确到毫秒记录调用发生的时间，它如同时间的刻度，让我们能清晰知晓方法调用在时间轴上的位置。

  3. COST：细致记录方法执行所耗费的时间，通过这个数据，我们可以直观了解方法的执行效率，判断其是否存在性能瓶颈。

  4. IS-RET/IS-EXP：明确方法是正常返回还是异常抛出状态，这一信息就像交通信号灯，正常返回是绿灯，异常抛出是红灯，能快速告知我们方法执行的健康状况。

  5. OBJECT/CLASS/METHOD：清晰记录执行对象、类名和方法名，这些信息组合起来，就像一份详细的地图，让我们清楚知道方法调用发生在哪个对象的哪个类的哪个方法中。

  6. 入参 / 返回值 / 异常堆栈：最强大之处在于，它能存储完整的数据快照，还支持 OGNL 表达式提取。当我们需要深入分析问题时，可以利用 OGNL 表达式从这些数据中提取关键信息，找到问题的根源。

典型应用场景

当客户反馈接口异常但无日志时，TT 命令就如同一位经验丰富的侦探，能从细微的线索中找到问题的真相，解决以下几类常见问题：

  1. 参数校验异常：在很多情况下，接口异常是由于参数校验不通过导致的。TT 命令能够捕获那些未被打印的入参非法场景，比如入参为空值，或者格式与预期不符。假设我们有一个用户注册接口，需要接收用户名、密码和邮箱等参数，正常情况下，邮箱格式应该符合特定的正则表达式。如果用户输入的邮箱格式错误，而程序中又没有打印详细的入参日志，此时 TT 命令就能派上用场，它可以记录下这次非法的入参，帮助我们快速发现问题所在。

  2. 业务逻辑异常：在复杂的业务逻辑中，方法执行过程中可能会抛出未捕获的异常，导致接口返回异常。TT 命令会忠实记录下这些异常及堆栈信息，就像留下犯罪现场的证据。通过查看这些记录，我们可以顺着堆栈信息追溯异常发生的源头，了解是哪一段业务逻辑出现了问题，从而进行针对性的修复。

  3. 依赖调用异常：现代应用系统通常会依赖多个下游服务，当接口异常时，有可能是依赖调用出现了问题。TT 命令能够追踪下游服务调用返回的错误码，比如常见的 404（资源未找到）、500（服务器内部错误）等，或者记录下调用超时的信息。通过这些记录，我们可以快速定位到问题出在哪个依赖服务上，是服务本身不可用，还是网络通信出现了故障。

表达式核心变量

无论是匹配表达式也好、观察表达式也罢，他们核心判断变量都是围绕着一个 Arthas 中的通用通知对象 Advice 进行。我们后续的检索条件的核心判断对象都是 Advice 。

它的简略代码结构如下

public class Advice {

    // 本次调用类所在的 ClassLoader
    private final ClassLoader loader;
    // 本次调用类的 Class 引用
    private final Class<?> clazz;
    // 本次调用方法反射引用
    private final ArthasMethod method;
    // 本次调用类的实例
    private final Object target;
    // 本次调用参数列表，这是一个数组，如果方法是无参方法则为空数组
    private final Object[] params;
    // 本次调用返回的对象。当且仅当 isReturn==true 成立时候有效，表明方法调用是以正常返回的方式结束。如果当前方法无返回值 void，则值为 null
    private final Object returnObj;
    // 本次调用抛出的异常。当且仅当 isThrow==true 成立时有效，表明方法调用是以抛出异常的方式结束。
    private final Throwable throwExp;
    // 辅助判断标记，当前的通知节点有可能是在方法一开始就通知，此时 isBefore==true 成立，同时 isThrow==false 和 isReturn==false，因为在方法刚开始时，还无法确定方法调用将会如何结束。
    private final boolean isBefore;
    // 辅助判断标记，当前的方法调用以抛异常的形式结束。
    private final boolean isThrow;
    // 辅助判断标记，当前的方法调用以正常返回的形式结束。
    private final boolean isReturn;
}

TT 命令实操步骤：从捕获到定位

当面临客户反馈接口异常但无日志的困境时，Arthas 的 TT 命令能提供一套高效的问题排查流程，帮助我们快速定位和解决问题。下面将通过一个实际案例，详细介绍 TT 命令的实操步骤。

第一步：激活 TT 记录器（实时捕获请求数据）

在 Arthas 命令行中，执行激活 TT 记录器的命令，指定需要记录的类和方法，以及限制记录次数，以避免高并发下内存溢出。

# 记录CustomerController类的list方法的调用记录
# 系统调用量特别大时，防止内存溢出，一定要加-n参数，指定记录请求次数
# 查找类名时，可以用*进行匹配，防止类匹配过多，可以使用-m参数
tt -t com.cly.sms.admin.web.controller.CustomerController* *list -n 10 -m 3
# 当类中有重载方法时，我们可以根据方法的参数数量、参数类型过滤 
# 例如：params.length==1，'params[1] instanceof Integer'，params[0].mobile=="13989838402"
# 记录参数下标为2的，userName值为33的请求，这样可以更精确的拦截到我们需要的请求记录
tt -t com.cly.sms.admin.web.controller.CustomerController list -n 10 params[2].userName=="33"

  • -t参数：指定记录的类和方法，这里使用通配符CustomerController*匹配所有控制器类，*list匹配所有list结尾的方法，确保捕获到所有可能的接口请求。

  • -n参数：限制记录次数为 10 次，在高并发场景下，默认的 100 次记录可能会导致内存占用过高，根据实际情况调整记录次数，既能满足排查需求，又能保证系统的稳定运行。

当客户再次触发异常接口时，TT 命令就像一个敏锐的观察者，自动记录下最多 10 次的调用数据。这些数据会被存储在jvm中供我们后续查询，使用完以后一定要清除这些记录。

第二步：筛选异常调用记录（快速定位问题请求）

激活记录器后，我们可以通过执行tt -l命令来查看所有记录列表。这个列表就像一份详细的清单，展示了每次调用的关键信息，包括调用编号、时间戳、耗时、是否正常返回以及是否抛出异常等。我们还可以使用 tt -s 命令来检索记录。检索时使用ognl表达式以及arthas的内置advice对象。

# 查看所有记录列表
tt -l
# 根据请求参数检索，参数长度大于2，下标为2的参数是Customer类的示例，并且下标为2的参数的userName的值为33
tt -s 'params.length > 2 && params[2] instanceof com.cly.sms.admin.model.app.Customer && params[2] .userName=="33"'
# 检索请求方法名为 toUpdate 的记录
tt -s 'method.name=="toUpdate"'

通过IS-EXP标识，我们可以快速定位到异常调用，true表示该次调用抛出了异常。结合客户反馈的异常时间点，通过TIMESTAMP字段进行精确匹配，进一步缩小排查范围。例如，在查看记录列表时，发现编号为 1003 的调用在 2025-08-05 14:30:15 抛出了NullPointerException异常，而这个时间点与客户反馈的时间一致，这就为我们找到了关键的线索。

第三步：解析异常详情（还原请求上下文）

定位到异常调用后，执行tt -i 1003命令，查看该次调用的详细信息，还原请求上下文。

tt -i 1003

  • 入参分析：仔细查看方法的入参，判断是否存在非法参数。比如在用户注册接口中，如果入参的用户名或密码为空，或者邮箱格式不符合要求，都可能导致接口异常。通过 TT 命令记录的入参信息，我们可以清晰地看到当时的输入情况，从而判断是否是参数问题导致的异常。

  • 异常堆栈：深入分析异常堆栈信息，了解异常产生的具体原因。异常堆栈就像一张地图，展示了异常发生的路径和位置。通过它，我们可以追踪到是哪一行代码抛出了异常，以及异常的类型和详细描述，为解决问题提供关键的依据。

  • 耗时分析：从记录中获取方法执行的耗时，判断是否存在超时问题。如果耗时过长，可能是业务逻辑复杂、数据库查询缓慢或者网络延迟等原因导致的。例如，发现本次调用的耗时为COST=237ms，与系统的正常响应时间相比，这个耗时在合理范围内，因此可以确认不是超时问题，而是逻辑异常。

第四步：重放调用验证修复（可选操作）

在修复代码后，为了确保问题得到彻底解决，我们可以通过重放原始入参来验证逻辑的正确性。这一步就像进行一次模拟考试，通过模拟客户请求参数，复现异常场景，而无需客户再次触发请求，节省了时间和精力。

tt -i 1003 -p

执行上述命令，重放编号为 1003 的调用。观察重放结果，如果一切正常，说明修复有效；如果仍然出现异常，我们需要重新审视代码，进一步排查问题。通过重放调用，我们可以在开发环境中对修复进行充分验证，确保上线后系统的稳定性和可靠性。

进阶技巧：结合 Arthas 生态提升排查效率

联合 watch 命令快速预研

在激活 TT 命令之前，我们可以先使用watch -e命令实时打印异常信息，这就像在黑暗中打开了一盏明灯，帮助我们快速确认异常发生的方法范围，从而更有针对性地启用 TT 命令记录。例如，在排查一个复杂的订单处理接口时，我们可以先执行：

watch -e com.example.demo.service.OrderService *

这个命令会在OrderService类的任何方法抛出异常时，实时打印出异常信息，包括入参、返回值和异常堆栈。通过观察这些实时信息，我们可以初步判断出异常发生在哪个方法中，比如发现是createOrder方法频繁抛出SQLException异常。此时，我们再针对性地启用 TT 命令记录createOrder方法的调用，这样可以避免不必要的记录，提高排查效率。

通过 sc 命令定位类加载器

在复杂的 Java 应用环境中，可能存在多版本类加载的情况。这时候，确保 TT 记录的是当前运行的类至关重要，否则可能会因为加载路径错误而导致记录的数据偏差，从而误导问题排查方向。我们可以使用sc命令来定位类加载器，例如：

sc -d com.example.demo.controller.UserController

这个命令会显示UserController类的详细信息，包括类加载器的相关信息。通过查看classLoaderHash字段，我们可以确定当前运行的类的加载器。在启用 TT 命令时，使用-c参数指定正确的类加载器，确保记录的是准确的数据，例如：

tt -t com.example.demo.controller.UserController login -c <classLoaderHash>

这样就能保证 TT 命令记录的是当前正确加载的UserController类的login方法的调用信息，避免因类加载问题导致的数据不准确。

利用 ognl 提取深层数据

在处理复杂对象时，比如 Spring MVC 中的HttpServletRequest对象，通过 OGNL 表达式穿透获取深层字段是非常实用的技巧。OGNL 表达式就像一把万能钥匙，能够打开复杂对象的深层数据之门。例如，我们想要获取HttpServletRequest中的User-Agent头信息，假设在某个接口方法中，HttpServletRequest对象作为参数传入，我们可以使用 TT 命令结合 OGNL 表达式来实现：

# 实时跟踪HomeController的index方法的每次调用，不仅记录方法的基本调用信息（如调用时间、耗时、是否异常等），还会额外显示该方法第一个参数（HttpServletRequest）中的User-Agent请求头信息。
tt -t com.example.demo.controller.HomeController index -w 'params[0].getHeader("User-Agent")'

这里params[0]表示方法的第一个参数，即HttpServletRequest对象，通过getHeader("User-Agent")方法获取User-Agent头信息。通过这种方式，我们可以深入挖掘复杂对象中的关键信息，为问题排查提供更全面的数据支持。

注意事项

性能影响与资源管理

  1. 内存占用：在使用 TT 命令时，需要特别关注内存占用问题。每条记录大约会占用 1 - 2KB 的内存空间。在高并发场景下，如果不加限制地记录方法调用，可能会导致内存迅速耗尽，从而影响系统的正常运行。因此，务必严格限制-n参数的值，根据实际经验，建议将其设置为小于等于 200，以确保系统在记录数据的同时，不会因为内存压力过大而出现性能问题。例如，在一个每秒有数百次接口调用的高并发系统中，如果不限制-n参数，默认的 100 次记录很快就会被填满，并且随着时间的推移，记录不断增加，可能会导致 JVM 内存溢出，使整个系统瘫痪。通过合理设置-n参数为 100 或更低，可以有效控制内存占用，保证系统的稳定性。

  2. 生命周期：TT 记录并不会随着 Arthas 的退出而自动清除。这意味着，如果在排查问题结束后，不及时清理这些记录，它们将一直占用内存空间。因此，在完成问题排查后，务必执行tt --delete-all命令，释放这些占用的内存，确保系统资源得到合理利用。比如，在一次短暂的接口异常排查中，使用 TT 命令记录了相关方法调用，排查结束后，如果不执行tt --delete-all命令，这些记录会一直存在于内存中，随着多次类似的排查操作，内存中积累的无用记录会越来越多，最终影响系统性能。

生产环境使用规范

  1. 白名单机制：在生产环境中，为了避免对系统性能产生不必要的影响，应仅对客户反馈的具体接口方法启用 TT 命令。避免对所有方法进行全局记录，因为这不仅会消耗大量的系统资源，还可能会产生大量无关的数据，增加排查问题的难度。例如，在一个大型电商系统中，接口众多，如果对所有接口都启用 TT 记录，可能会导致系统性能大幅下降，并且在查看记录时，会被大量无关的信息淹没，无法快速定位到问题所在。通过设置白名单，只对出现问题的订单提交接口或用户登录接口等进行记录，可以精准地获取有用信息，同时减少对系统的影响。

  2. 时间窗口：结合客户反馈的时间点，通过-n参数和TIMESTAMP字段来缩小记录范围是非常关键的。-n参数可以限制记录的次数，避免记录过多无用的数据；而TIMESTAMP字段则可以帮助我们精确筛选出在客户反馈时间附近的调用记录，提高排查效率。比如，客户反馈在上午 10 点到 10 点 10 分之间某个接口出现异常，我们可以设置-n 50（根据实际情况调整），并在查看记录时，通过TIMESTAMP字段筛选出这个时间段内的调用，这样可以快速定位到问题相关的记录，而不会被其他时间段的大量记录干扰。

  3. 风险提示：需要注意的是，TT 命令可能会对方法执行性能产生一定的影响，通常会使方法执行耗时增加 5% - 10%。因此，建议在非高峰时段使用 TT 命令进行问题排查，以减少对业务的影响。例如，在电商系统的促销活动期间，系统处于高负载运行状态，此时如果使用 TT 命令，可能会进一步加重系统负担，导致接口响应变慢，影响用户体验。而在凌晨等业务量较低的时段使用 TT 命令，可以在不影响业务正常运行的前提下，完成问题排查工作。

总结

当传统日志体系在对接场景中 “失效” 时，Arthas 的 TT 命令通过 “记录 - 筛选 - 解析 - 验证” 四步流程，为开发工程师提供了一套完整的异常追溯方案。其核心优势在于：

1. 零侵入性：无需修改代码或重启服务，实时捕获运行时数据

2. 精准定位：通过唯一调用编号关联全链路信息，避免日志碎片化问题

3. 动态验证：支持请求重放，快速验证修复方案的有效性掌握 TT 命令的核心用法，不仅能提升客户对接问题的排查效率，更能构建应对 “无日志困境” 的技术储备，确保在复杂生产环境中快速响应、精准定位、高效解决异常问题。

文章作者： Z
本文链接：
版权声明： 本站所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 微博客！
工具 运维 基础
喜欢就支持一下吧