我们常常会遇到这样的困惑，收到用户或者客服的反馈，平台使用有问题，但是测试人员搭建环境后又没办法复现故障，最后导致问题没法解决，眼睁睁地看着用户流失。
这是因为线上生产环境非常复杂、很多时候是偶发性 bug ，但却很难捕捉。特别是随着微服务盛行，系统复杂度增加，线上故障的快速定位和及时分析解决面临着巨大挑战，以前只能靠人来解决。但是人的问题解决能力与速度依赖于经验，有时候甚至需要跨部门的配合，这样的成本非常高，一旦关键人员流失、部门配合不融洽，整个故障的解决速度就会极速下降。
这时候我要给大家带来一款好用的性能分析工具- Application Insight （应用性能管理平台，以下简称 Ai ），至于它能干什么呢？往下看你就知道了～
trace & snapshot 功能介绍
01业务运行中有哪些错误呢？
在代码运行中，常常会遇到这几类型问题：
●JVM
常见的比如 oom 内存溢出、内存泄漏、gc pause 、磁盘运行不足等
● 数据库
常见的比如数据库负载繁忙、数据库服务器超负载、单一 sql 语句执行缓慢、数据库连接池获取时间长、对数据库连接池的访问次数过多等
● 外部服务
常见的比如外部服务网络问题、不同应用之间的调用阻塞、索引设置不合适等
● 其它问题
上面都是我们常见的场景，但是还有一些问题是深深的潜藏在程序中，需要我们深入地分析代码才能找到原因。
线程死锁、循环操作、事务异常、jvm crash 等
02什么是 trace ？
trace 收集程序运行时的信息来查询程序运行情况，定位代码中需要修改和优化的部分，提高代码运行速度，提升用户体验。
业内常用的方法有如下三种：
● 事件方法
在 Java 语言中，使用 jvmti（ jvm tools interface ）api 方法来捕捉诸如方法调用、类载入、类卸载、进入离开线程等事件，然后再基于这些事件进行代码行为的分析。
● 统计抽样
每隔一段事件中断调用系统，收集当前的调用栈信息，记录调用栈中出现的函数及这些函数的调用结构，基于这些信息得到函数的调用关系图及每个函数的 cpu 使用信息。
● 插码
在目标程序中插入指令代码，这些指令代码会记录程序运行的开始时间、结束时间等，再经过统计得出函数调用情况、函数 cpu 使用情况。
03 AI 的 trace
Ai 采用插码与快照（统计抽样）的方式来实现 trace ，trace 包括慢 trace 、错误 trace 、sql trace 、snapshot 四类：
● 慢 trace
在用户的事务响应时间超过阈值的时候去进行采集。系统默认是2秒，但用户可以根据自己实际情况在 Ai 的“设置-慢事务”处进行设置。
● 错误 trace
当程序运行异常或直接报错时，我们会直接采集错误 trace，还原现场。