一次流量不均衡問題的排查記錄

講一個這周排查的訪問流量不均的事兒。

下游同學(xué)反饋我們的服務(wù)調(diào)用流量不均，最高的實例有 1k+ QPS，最低的才 400+ QPS，相差太大。

于是拉了平臺的 oncall，詢問是否開了 mesh，沒開。那就是框架的事了。

再拉框架的 oncall，詢問是否自己加了流量均衡的策略，也沒加。那就是用的默認(rèn)的流量調(diào)度策略：“加權(quán)隨機”。

什么是加權(quán)隨機？

加權(quán)是指按節(jié)點權(quán)重進(jìn)行流量分配，隨機意味著相同權(quán)重下的實例隨機選擇。

去查下游各個 host 的 weight 值。發(fā)現(xiàn)確實有些 host 的 weight 值相差比較大。有的值是 10，有的值是 50。看起來是符合預(yù)期的。

這時又提出有兩個 host 的 weight 值一樣，但 QPS 相差 4 倍。

有同學(xué)說，直接去 access 日志里撈一下就行了。一行日志代表一個訪問，積累出每秒鐘的訪問量，結(jié)果不就出來了嗎？

grep?'2021-11-20?10:01'?xxx.log?|?awk?'{print?substr($3,1,8)}'?|?sort?|?uniq?-c

結(jié)果會打印出在 10:01 這一分鐘每秒的請求數(shù)，即 QPS。

果然，前面提到的這兩臺 host 訪問量基本相同。看起來是監(jiān)控打點出了問題。

找到其中 QPS 比較低的這一臺機器，發(fā)現(xiàn)部署的 metricsserver CPU 受限很嚴(yán)重，說明丟了很多點，于是就造成了流量不均衡的假象。

之后找 metrics 的同學(xué)升級了套餐，上線完成之后，打點恢復(fù)正常。流量是均衡的。

這樣一個簡單的問題，還花費了一點時間。以后碰到類似的問題，第一時間看監(jiān)控是否有問題。有些機器上的服務(wù)打點多，metricsserver 扛不住，丟點是在所難免的。

之前也碰到過幾次打點不準(zhǔn)的問題，查了半天，最后發(fā)現(xiàn)烏龍了。因此對于一些不太符合常理（例如本文的訪問流量不均）的問題，先要確定打點沒有問題。