[原]​Top99 超时排查思路

2021-09-17 08:35:45 Author: blog.csdn.net 阅读量: 12 收藏

583320b7f417cb522f60a63934243557.png

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

背景介绍

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

报警

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

cadc166b535461ffa96e288bd7fdb1f5.png

报警

分析

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

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

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

排查

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

b0d93ec63db60599c0b8416de94f3a7f.png

排序后的Top999

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

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

反思

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

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

dc548032375bb5285629f0f4c1836b53.png

sort_desc()文档介绍

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

d096f93bb6ac820977290fa25ea73f6b.png

grafana语句

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

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

- END -



觉得文章还不错?,点我收藏



如果文章侵犯到您的版权,请联系我:buaq.net[#]pm.me