問題：
上周開始公司托管在IDC機(jī)房的一臺(tái)服務(wù)器頻繁掉線，導(dǎo)致ssh連接不上，過幾分鐘又恢復(fù)。通過監(jiān)控查看，沒有什么有價(jià)值的結(jié)果，因?yàn)槭菍?duì)公網(wǎng)IP監(jiān)控的，當(dāng)時(shí)監(jiān)控是沒有數(shù)據(jù)的，唯一有價(jià)值的就是通過監(jiān)控的No data 時(shí)間來看，是不定時(shí)觸發(fā)的，排除了因某些定時(shí)任務(wù)導(dǎo)致。
過程：
0. 詢問機(jī)房人員調(diào)取監(jiān)控圖
監(jiān)控排查無果后，果斷詢問機(jī)房人員，調(diào)取問題發(fā)生的時(shí)間段流量監(jiān)控，發(fā)現(xiàn)交換機(jī)的入口流量已經(jīng)超過了100M（百兆交換）導(dǎo)致流量驟增，公網(wǎng)無法訪問。 機(jī)房那邊的的入流量徒增也就是我們服務(wù)器這邊的出流量，猜測(cè)有大量上傳操作或者cpu飆升的現(xiàn)象。
1. 排查機(jī)器存活
ssh連接不上我們先要確定是 機(jī)器確實(shí)宕機(jī)了 還是 ssh斷掉了 還是公網(wǎng)IP無法連接了 ？
問題再次出現(xiàn)時(shí)，通過托管在機(jī)房的集群環(huán)境中其他機(jī)器，用內(nèi)網(wǎng)IP嘗試登陸，成功！ 機(jī)器是存活的，ssh服務(wù)也沒有掛！所以就是結(jié)合前面的結(jié)果，問題就在帶寬流量打滿了，無法連接。
2. 排查機(jī)器CPU，內(nèi)存情況
登錄上去以后，top命令 C ， 果斷找到"罪魁禍?zhǔn)?
根據(jù)PID，找到程序父ID，直接定位是哪個(gè)進(jìn)程引起的
ps -ef|grep id
3.找到“涉事”進(jìn)程
根據(jù)公司業(yè)務(wù)邏輯java程序都以容器的方式運(yùn)行，并且可以看到運(yùn)行信息帶有env為prod的字樣，用docker ps 找出這個(gè)容器
user@ubuntu:/home1/ALG/identification/upload$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ea271034d32b harbor.hw.xxxx.com:5000/health-cloud-server/health-cloud-ai-manager:883e2fc9-prod "/bin/sh -c 'java -D…" 11 days ago Up 11 days 0.0.0.0:8004->9000/tcp health-cloud-ai-manager-prod_health-cloud-ai-manager_1
8f6accb9cd0c harbor.hw.xxx.com:5000/health-cloud-server/health-cloud-ai-manager:c9a69dcb-k8s-dev "/bin/sh -c 'java -D…" 2 weeks ago Up 2 weeks 0.0.0.0:8001->9000/tcp health-cloud-ai-manager-dev_health-cloud-ai-manager_1
4.進(jìn)入容器排查(容器ID-ea271034d32b)
ss命令看soket連接情況
root@ea271034d32b:/# ss
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
u_str ESTAB 0 0 * 694692659 * 0
u_str ESTAB 0 0 * 694686601 * 0
udp ESTAB 0 0 172.24.0.2:48273 8.8.8.8:domain
udp ESTAB 0 0 172.24.0.2:60631 202.106.0.20:domain
tcp ESTAB 0 285 172.24.0.2:46840 121.36.25.185:8635
tcp SYN-SENT 0 1 172.24.0.2:39208 124.70.70.103:8635
tcp SYN-SENT 0 1 172.24.0.2:47412 121.36.25.185:8635
tcp CLOSE-WAIT 0 0 172.24.0.2:44428 119.3.214.140:8848
tcp SYN-SENT 0 1 172.24.0.2:47386 121.36.25.185:8635
tcp ESTAB 0 36844 172.24.0.2:35628 216.118.240.74:http-alt
tcp CLOSE-WAIT 1 0 172.24.0.2:48802 119.3.214.140:8848
tcp ESTAB 0 33184 172.24.0.2:35634 216.118.240.74:http-alt
tcp SYN-SENT 0 1 172.24.0.2:39218 124.70.70.103:8635
tcp SYN-SENT 0 1 172.24.0.2:33382 119.3.214.140:8848
tcp ESTAB 0 484 172.24.0.2:33378 119.3.214.140:8848
tcp ESTAB 0 285 172.24.0.2:38096 124.70.70.103:8635
tcp SYN-SENT 0 1 172.24.0.2:52370 216.118.240.74:http-alt
tcp CLOSE-WAIT 1 0 172.24.0.2:37550 119.3.214.140:8848
tcp ESTAB 0 0 172.24.0.2:43842 119.3.221.159:8501
結(jié)果上看有兩處 ESTAB狀態(tài)時(shí)，Send-Q 堆積過多，這肯定是不正常的
tcp ESTAB 0 36844 172.24.0.2:35628 216.118.240.74:http-alt
這個(gè)客戶端IP也比較可疑，來自香港，因?yàn)檫@個(gè)服務(wù)只是公司內(nèi)部調(diào)用 ，集群機(jī)器也沒有香港的機(jī)器。
5. 詢問相關(guān)業(yè)務(wù)人員，是否可以重啟
當(dāng)務(wù)之急的解決辦法最快清除這些堆積的包與鏈接，就是重啟容器，詢問相關(guān)業(yè)務(wù)人員，進(jìn)行了重啟后，再次查看CPU狀態(tài)已經(jīng)恢復(fù)正常，通過公網(wǎng)IP也可以立刻鏈接上了，目前需要多觀察幾天，是否還會(huì)復(fù)發(fā)。
總結(jié)：
1.recv-Q 表示網(wǎng)絡(luò)接收隊(duì)列
表示收到的數(shù)據(jù)已經(jīng)在本地接收緩沖，但是還有多少?zèng)]有被進(jìn)程取走，recv()
如果接收隊(duì)列Recv-Q一直處于阻塞狀態(tài)，可能是遭受了拒絕服務(wù) denial-of-service 攻擊。
2.send-Q 表示網(wǎng)絡(luò)發(fā)送隊(duì)列
對(duì)方?jīng)]有收到的數(shù)據(jù)或者說沒有Ack的,還是本地緩沖區(qū).
如果發(fā)送隊(duì)列Send-Q不能很快的清零，可能是有應(yīng)用向外發(fā)送數(shù)據(jù)包過快，或者是對(duì)方接收數(shù)據(jù)包不夠快。
從圖中可以看到是大量的 send-Q ,可以判定是發(fā)送數(shù)據(jù)給目的地址的時(shí)候出現(xiàn)了阻塞的問題，導(dǎo)致了包堆積在本地緩存中，不能成功發(fā)出去。那么問題就產(chǎn)生在了客戶端， 重啟了容器，清掉正發(fā)送的隊(duì)列，再次觀察。
3.關(guān)于ss 命令和 netstat 命令都是排查網(wǎng)絡(luò)連接的利器，Recv-Q ，Send-Q的值是如何進(jìn)行分析的呢？
一. Established狀態(tài)時(shí)：
- Recv-Q："OS持有的，尚未交付給應(yīng)用的 數(shù)據(jù)的 【字節(jié)數(shù)】"
- Send-Q："已經(jīng)發(fā)送給對(duì)端應(yīng)用，但對(duì)端應(yīng)用尚未ack(確認(rèn))的【字節(jié)數(shù)】。此時(shí)，這些數(shù)據(jù)依然要由OS持有"
二. Listen狀態(tài)時(shí)：
- Recv-Q："服務(wù)端已經(jīng)接收到的，但尚未交付給應(yīng)用的【 tcp連接的數(shù)量】"
（客戶端通過 connect() 去連接正在 listen() 的服務(wù)端時(shí)，這些連接會(huì)一直處于這個(gè) queue 里面直到被服務(wù)端 accept()調(diào)用派給應(yīng)用） - Send-Q：listen時(shí)，backlog的大小,其值為min(backlog, somaxconn)，簡(jiǎn)單理解為在等待區(qū)等待的【連接數(shù)】最大值
補(bǔ)充
包括在tomcat調(diào)優(yōu)時(shí)會(huì)有accept-count ，max-connections 參數(shù)
- max-connections : 允許的最大連接數(shù)
- accept-count ： 當(dāng)超過最大連接數(shù)后，將超額的連接放入accept（）隊(duì)列中，等待前面空閑后，os從這里面調(diào)用正在等待的連接，如果accept滿了，將不會(huì)接受任何請(qǐng)求，也就是可能會(huì)給客戶端返回502，這個(gè)accept-count值就是在除了最大連接數(shù)，還可以在額外多接受幾個(gè)連接。
參考：
https://www.cnblogs.com/leezhxing/p/5329786.html
https://blog.csdn.net/yjh314/article/details/51038774
