問題背景
在一次現(xiàn)場(chǎng)硬件部署實(shí)施過程中洪橘,實(shí)施人員突然發(fā)現(xiàn)網(wǎng)絡(luò)大批量請(qǐng)求超時(shí)的情況,在確認(rèn)現(xiàn)場(chǎng)網(wǎng)絡(luò)通暢的情況下,立刻通知給了我們開發(fā)人員而姐。經(jīng)過調(diào)試,發(fā)現(xiàn)所有接口均出現(xiàn)了斷斷續(xù)續(xù)無法訪問的情況划咐,基本上完全處于不可用狀態(tài)。出現(xiàn)這種情況第一反應(yīng)是網(wǎng)絡(luò)問題钧萍,因?yàn)榫€上機(jī)房位于位于電政辦褐缠,之前有過網(wǎng)路不穩(wěn)定的情況,在電話溝通后得知對(duì)方此時(shí)網(wǎng)絡(luò)也異常慢风瘦,此時(shí)已無力吐槽這貸款了队魏。
但是問題真的就只是網(wǎng)絡(luò)帶寬這么簡(jiǎn)單嗎?
通過Zabbix排查問題
線上集群幾乎每個(gè)節(jié)點(diǎn)都部署了Zabbix集群監(jiān)控万搔,通過NetWork監(jiān)控項(xiàng)可以排查網(wǎng)絡(luò)問題胡桨,大體流量圖如下:
可以發(fā)現(xiàn),除了部分時(shí)刻網(wǎng)絡(luò)流量驟增之外瞬雹,大部分時(shí)間還是比較平穩(wěn)的昧谊,其中綠色代表incoming流量,藍(lán)色代表outgoing流量酗捌。根據(jù)此圖(主要是沒有流量斷點(diǎn))可以大致判斷并非完全是由于網(wǎng)絡(luò)問題導(dǎo)致的問題呢诬。
但是再仔細(xì)想想,整個(gè)系統(tǒng)采用的是分布式架構(gòu)胖缤,各節(jié)點(diǎn)間的調(diào)用均通過RPC調(diào)用尚镰,只有幾個(gè)節(jié)點(diǎn)是對(duì)外通過Nginx代理訪問的,也就是說Nginx節(jié)點(diǎn)入口是導(dǎo)致問題的關(guān)鍵哪廓。然而遺憾的是Nginx節(jié)點(diǎn)上并沒有部署Zabbix狗唉,只能手動(dòng)排查了。
發(fā)現(xiàn)真實(shí)問題原因
首先在Nginx節(jié)點(diǎn)上執(zhí)行已下命令
netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"t",state[key]}'
可以發(fā)現(xiàn)等待請(qǐng)求在不斷增加涡真,說明有較多請(qǐng)求阻塞了分俯。很自然的聯(lián)系到Nginx的配置,
這里修改了worker_processes 哆料、worker_connections配置澳迫,重啟Nginx,再次執(zhí)行命令剧劝,此時(shí)發(fā)現(xiàn)阻塞的請(qǐng)求數(shù)量有所下降橄登,但是還是一直不斷的在增加。
好吧到這里基本已經(jīng)開始懷疑服務(wù)器跟帶寬已經(jīng)跟不上了,但是究竟是啥請(qǐng)求在一直訪問呢拢锹?
執(zhí)行netstat -t查看一下谣妻,發(fā)現(xiàn)所有的請(qǐng)求均來自與39節(jié)點(diǎn),該節(jié)點(diǎn)上最近剛剛部署了C/S端的程序卒稳,于是通知C部門排查蹋半,最終確認(rèn)了問題。停掉C/S端后充坑,其他請(qǐng)求陸續(xù)恢復(fù)了正常减江。