记一次线上延时问题，主要讲如何进行延时分析。
记一次线上延时分析
问题爆发
今天九点钟的时候，本来在开开心心写着代码准备验证的时候，运营人员突然发来钉钉说App偶然间出现卡顿问题，有一些页面加载不出来，同时举报入口、聊天页面均出现了部分异常。考虑到九点钟正值高峰期，且安排了一场引流活动，我们便开始了一轮排查
第一站：Prometheus
由于大部分服务均使用了 Gateway 来转发流量，我们可以直接查询 Geteway 去分析所有后端服务的延时情况。果不其然，Gateway 服务 p50 p75 均小于200ms(虽然也不低)的延时，但是还在可以接受的范围之内。但是 p99 已经严重超时，达到了 2000ms 的延时，于此同时 Prometheus 终于向我们发出了警告，提醒我们有服务超时。
第二站：K8S Node Pod资源不足
其实这点我们是不相信的，很少会出现 k8s node 资源不足的情况，即使之前的顶峰也没有占用到 70% 的资源，一场引流活动不可能直接把 node 全部打死，并且我们还做了 k8s 的节点池，如果进行了节点池的补充我们应该是会第一个知道的，它的报警会比 Prometheus 还要及时。我们接着使用了 kubectl -n namespace top nodes 查看资源占用情况，很不幸，所有的节点资源均在正常范围之内。
接下来我们开始怀疑一些热点服务Pod资源不足，我们虽然使用了 HPA 来进行 pod 伸缩，但是规定了最大节点数为30个，我们怀疑是最大节点数达到了限制导致资源不足的情况。然后我们检查了几个重点服务: account等，发现资源的占用都在正常的范围之内。
第三站：MySQL 服务
这点我也是不太相信的，之前遇到过一次宕机问题之后，我们对线上的 MySQL 数据库进行了读写分离，并且分离了一些非重点仓库，升级了 MySQL 数据库的配置（云原生真的很方便）。我们查看了 MySQL 的重点资源，发现均在正常范围之内，并且之前的工作也是很有成效的，目前 MySQL 的CPU、磁盘等均在 20% 的占用(感觉会缩容了)。并且仅存的几个慢查询日志均为定时任务查询，在运行的范围之内。
第四站： Mongo 服务
当我打开的 Mongo 的监控时，发现 Mongo 服务出现了大量的慢查询，且 CPU 占用达到了 80% 。由于 IM 服务和 account 服务均使用了 mongo作为数据库(哪位小可爱把用户数据存mongo的 :) )，并且 IM 服务的一些表没有走有效的索引，导致了大量的全量扫表，最多的达到了三百万行数据，延时达到了一秒！！！之前没有暴露的原因在于不存在瞬时的 IM 访问，为什么IM服务会出现大量访问的原因就不说那么具体了，感觉是被友商搞了。
第五站：加索引！！！！
没有什么好说的。
写在最后
其实总结这篇文章的原因在于为下一篇文章(准备写一个SQL质量分析插件)做个开始，当然这里也给大家展示了解决卡顿问题的基本思路(查日志定位具体服务延时这里没有说)，也没什么好说的，睡觉😪，希望明天可以开心上班。
