問題背景
在一次現(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ù)了正常减江。
