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

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

反思

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

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

sort_desc()文档介绍

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

grafana语句

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

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

- END -