[问题发现]
使用 zabbix 软件监控服务器时发现 cpu 突然异常，在业务主机上使用 top 命令查看系统的整体运行情况，使用 top 命令后发现 mysqld 占用 CPU 特别高，初步判断可能是 mysqld 出现问题，需要排查：

[排查步骤]
Step1:
登录 oneapm ai 平台后可以看到应用列表的总览视图，在总览视图中可以看到所有应用的名称以及相关指标信息，同时我们还可以根据应用颜色变化来判断每个应用的指标变化情况。本例中在 Acmeair 应用的 “用户体验一览” 选项卡下可以看到它的业务在最近一段时间内出现了 71 次失败，我们需要点击此应用查看详情，如图一：

图一

Step2：
利用 top 命令已经基本排查出是数据库导致 CPU 占用过高，我们可以通过查看调用数据库的节点发现问题。
在 AI 平台上点击某个应用进入到该应用的主页，进入之后可以看到该应用的总体拓扑图，总览拓扑图会把应用中所有 Tier、数据库、远程服务与其他应用之间的调用关系描绘出来，并且显示他们的性能情况。当某个节点的颜色为黄色或红色时，代表该 Tier 的健康状态是告警或严重。
点击拓扑图右上侧的 “数据库 - 展开” 选项，可以看到调用 mysql 数据库的节点，点击该节点（例如下图中的 Webapp11 节点），出现的弹框中有总览、节点、Web 事务入口、Web 事务、主机和容器几个选项卡。“Web 事务入口” 可以看到某个应用在应用环境中请求的起始点；而 “Web 事务” 展示了一些用户最关心的的指标，从而让用户对当前查看 Web 事务的健康状况产生总体的了解。
点击 “Web 事务入口” 选项可以看到对应接口的响应时间正常，代表对应接口表现正常，如图二；我们需要继续排查 “Web 事务” 部分。

图二

点击 “Web 事务” 选项，可以给出该节点中所有 Web 事务的响应时间及调用次数，点击 “响应时间” 可以将响应时间从高往低排序，从而确认缓慢的 “Web 事务”，如图三。本例中，点击响应时间最长的 Web 事务查看详情。

图三

Step3：
点击响应时间最长的一个 Web 事务后，左上角 “总览” 下 “Web 事务” 的标签会显示出该 Web 事务的平均响应时间，点击某一响应时间较长的时间点，可以向下钻取到所选时间段，精准定位到问题时间点。同时在 Web 事务的下方可以看到该时间段内的最慢组件，如图四。
在本例中下钻到具体时间点后，可以在 “总览” 界面的 “最慢组件” 下看到是一个 select 语句比较耗时，再次佐证了我们的想法。

图四

Step4：
Trace 是对这段时间内该用户缓慢或错误请求的详细追踪。
钻取到问题时间段后，我们查看该时间范围内的 Trace 列表，如图五。因为同一个 Web 事务调取到的后端信息都是相同的，所以我们只需要选取其中的一条或几条最优代表性（例如响应时间较长）的 Trace 进行问题定位即可。
在本例中我们按响应时间进行排序降序排列后，选择第一条进行 Trace 详情查看。

图五

点击所选 Trace 之后，在 Trace 概要中可以看到该 Trace 中的最慢组件，如图六。例如图六中我们可以在 Trace 的总览页面发现 customer/select 语句耗时较长。

图六

弹框中同样还可以查看该 Trace 中的堆栈调用详情。点击 “详情” 选项卡，如图七，可以看到该 sql 语句对接口的影响，从而进行代码的优化。在本例中，我们可以看到 SQL 语句的耗时百分比较高，可以看出该 SQL 语句对接口影响较大。

图七
点击该 SQL 语句 附加信息栏中的图标，可以查看到耗时较长的的 sql 语句详情。我们也可以弹框左上角中的 “SQL” 选型卡，在弹框中也可以看到语句详情、该语句的响应时间及调用次数，如图八、图九：

图八

图九

至此，发现问题原因以及影响接口已全部排查出来！