nginx大量502異常錯誤的排查過程

這篇文章主要講解了“nginx大量502異常錯誤的排查過程”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“nginx大量502異常錯誤的排查過程”吧！

問題背景：118機器出現(xiàn)接口不通報警，一段時間后恢復(fù)

排查過程：

1、確認(rèn)問題：nginx大量502異常，即nginx對應(yīng)的后端服務(wù)可能處理很慢或者將請求丟棄了。

2、檢查118機器的cpu，內(nèi)存，網(wǎng)絡(luò)等基礎(chǔ)指標(biāo)，發(fā)現(xiàn)eth0這段時間入口流量驟減，幾乎為0，而且出問題的幾天，時間吻合，其它指標(biāo)正常，說明流量減少一定是問題的一個主要突破口。

3、eth0網(wǎng)絡(luò)入口流量為0，有兩種可能：1、網(wǎng)絡(luò)問題導(dǎo)致機器不通；2、tomcat服務(wù)負(fù)載太高，導(dǎo)致新的socket請求連接被拒絕；

4、檢查網(wǎng)絡(luò)：發(fā)現(xiàn)本機的ping檢測無丟包現(xiàn)象，另外，同個機房的其它機器也都沒有丟包的情況，那么網(wǎng)絡(luò)問題就可以被排除了。

5、tomcat問題：由于之前調(diào)整過acceptcount到10000（當(dāng)連接數(shù)20000左右的時候，會導(dǎo)致隊列中的請求等待的時間很長），第一反應(yīng)是：這個時間段，肯定有一些請求導(dǎo)致tomcat的請求隊列滿了，導(dǎo)致請求在排隊，從而時間比較長。其它請求由于隊列已經(jīng)滿了于是被丟棄，tomcat則不會接受TCP連接，從而導(dǎo)致入口流量降低。于是，在tomcat的log中增加了請求時間%T，希望在出問題的時間段找出有請求時間很長的請求。

6、等待了一天。

7、觀察昨天的數(shù)據(jù)：發(fā)現(xiàn)在相同的時間段，出現(xiàn)了很多簡單的請求卻需要花大概將近2分鐘，而且很多花了將近1分鐘，

分析的命令：sort -k11rg file.txt：簡單解釋：按照空格分割，分割后按照第11列的數(shù)據(jù)排序，-r是倒敘排序，-g是將字符串轉(zhuǎn)成數(shù)值再排序

8、找到對應(yīng)的請求地址，以及客戶端，找到客戶端對應(yīng)的負(fù)責(zé)人，和其溝通發(fā)現(xiàn)：會在每天凌晨大批量調(diào)用這個接口導(dǎo)致。

感謝各位的閱讀，以上就是“nginx大量502異常錯誤的排查過程”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對nginx大量502異常錯誤的排查過程這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！