?Top99 超时排查思路

这篇文章想分享 Top99 超时排查的思路和在工作中主动向身边的同事学习的一种意识

背景介绍

我们的系统 Top90 稳定在 19ms 左右，Top99 稳定在 46 ms 左右，Top999 稳定在 50ms 左右，监控报警主要用的 Prometheus Grafana 自研报警平台

报警

晚上和小伙伴们出去吃饭了，突然收到了报警，一个工程的 top99 超过了 200 ms，持续时间大于了 10 分钟。同时合作方 ADX 那边反馈我们的 DSP 延迟比较严重。

分析

在开始排查这个问题时，先看当时有没有人上线了，确实有同事在报警发生时间点上线了，但通过查看 CR ，并没有什么问题

开始时我做了很多无用功，查看该服务所有的一台机器的日志，也没看出啥问题，从服务管理平台检查调用依赖服务是否超时严重，经排查依赖服务都是正常的，顿时没啥思路了

我同事找到了一个突破口，我们系统 Top90 稳定在 19ms 左右，Top99 稳定在 46 ms 左右，Top999 稳定在 50ms 左右，而这次报警发生时，Top99 和 Top999 都达到了 200ms，而 Top90 是 20ms，显然 Top90 没怎么波动，这是非常重要的一个线索，从这些指标可以推断出只有部分流量或节点出了问题

排查

我们的业务指标监控用的 Prometheus，在工程中埋点，数据收集到 Prometheus，然后在 Grafana 中展示，目前只是显示了集群的 Top90、Top99、Top999 指标，同事在 Grafana 中操作了一番，然后发了一张图（图未截全）

原来他将 Top999 按实例分组，并将值按倒序排序了，发现确实只有很小一部分节点出了问题，然后就留了一个节点保留现场用于排查，将剩余超时的节点重启了，随后 Top999 就降下来了

后面通过排查保留现场的那个节点，发现是服务初始化时，调用一个依赖服务超时了，然后有问题的节点就一直超时了，这个主要是因为上线时并行上线的节点数比较多，且间隔时间有点短，对依赖服务方造成了压力

反思

首先我从同事身上学到了一种排查思路，Top99 和 Top999 超时比较严重，但 Top90 几乎没怎么变化，这就说明只是部分节点或部分流量出了问题，集群的大部分都是正常工作的。然后就顺藤摸瓜，按实例分组展示指标，并做排序找到有问题的节点，然后有针对性的处理和排查

虽然问题解决了，但同事在 Grafana 上操作了什么我不得而知，确实有冲动想问他那个语句怎么写的，但都被自己打住了，在请教别人问题前，还是需要自己好好先查查的，然后我就看 Prometheus 官方文档中的 Functions 部分

然后开始在 Grafana 上操作，最后终于自己整出来了，对应的语句和操作如下所示

我搞出来后，这个排查思路我就掌握了，然后第二天又有了相同的报警，我第一时间介入了，快速处理了问题

工作中要主动向身边的同事学习，将其技能内化成自己的！

- END -