這篇文章想分享 Top99 超時排查的思路和在工作中主動向身邊的同事學(xué)習(xí)的一種意識

背景介紹

我們的系統(tǒng) Top90 穩(wěn)定在 19ms 左右，Top99 穩(wěn)定在 46 ms 左右，Top999 穩(wěn)定在 50ms 左右，監(jiān)控報警主要用的 Prometheus Grafana 自研報警平臺

報警

晚上和小伙伴們出去吃飯了，突然收到了報警，一個工程的 top99 超過了 200 ms，持續(xù)時間大于了 10 分鐘。同時合作方 ADX 那邊反饋我們的 DSP 延遲比較嚴重。

分析

在開始排查這個問題時，先看當時有沒有人上線了，確實有同事在報警發(fā)生時間點上線了，但通過查看 CR ，并沒有什么問題

開始時我做了很多無用功，查看該服務(wù)所有的一臺機器的日志，也沒看出啥問題，從服務(wù)管理平臺檢查調(diào)用依賴服務(wù)是否超時嚴重，經(jīng)排查依賴服務(wù)都是正常的，頓時沒啥思路了

我同事找到了一個突破口，我們系統(tǒng) Top90 穩(wěn)定在 19ms 左右，Top99 穩(wěn)定在 46 ms 左右，Top999 穩(wěn)定在 50ms 左右，而這次報警發(fā)生時，Top99 和 Top999 都達到了 200ms，而 Top90 是 20ms，顯然 Top90 沒怎么波動，這是非常重要的一個線索，從這些指標可以推斷出只有部分流量或節(jié)點出了問題

排查

我們的業(yè)務(wù)指標監(jiān)控用的 Prometheus，在工程中埋點，數(shù)據(jù)收集到 Prometheus，然后在 Grafana 中展示，目前只是顯示了集群的 Top90、Top99、Top999 指標，同事在 Grafana 中操作了一番，然后發(fā)了一張圖（圖未截全）

原來他將 Top999 按實例分組，并將值按倒序排序了，發(fā)現(xiàn)確實只有很小一部分節(jié)點出了問題，然后就留了一個節(jié)點保留現(xiàn)場用于排查，將剩余超時的節(jié)點重啟了，隨后 Top999 就降下來了

后面通過排查保留現(xiàn)場的那個節(jié)點，發(fā)現(xiàn)是服務(wù)初始化時，調(diào)用一個依賴服務(wù)超時了，然后有問題的節(jié)點就一直超時了，這個主要是因為上線時并行上線的節(jié)點數(shù)比較多，且間隔時間有點短，對依賴服務(wù)方造成了壓力

反思

首先我從同事身上學(xué)到了一種排查思路，Top99 和 Top999 超時比較嚴重，但 Top90 幾乎沒怎么變化，這就說明只是部分節(jié)點或部分流量出了問題，集群的大部分都是正常工作的。然后就順藤摸瓜，按實例分組展示指標，并做排序找到有問題的節(jié)點，然后有針對性的處理和排查

雖然問題解決了，但同事在 Grafana 上操作了什么我不得而知，確實有沖動想問他那個語句怎么寫的，但都被自己打住了，在請教別人問題前，還是需要自己好好先查查的，然后我就看 Prometheus 官方文檔中的 Functions 部分

然后開始在 Grafana 上操作，最后終于自己整出來了，對應(yīng)的語句和操作如下所示

我搞出來后，這個排查思路我就掌握了，然后第二天又有了相同的報警，我第一時間介入了，快速處理了問題

工作中要主動向身邊的同事學(xué)習(xí)，將其技能內(nèi)化成自己的！

- END -