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

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

問題背景：118機器出現接口不通報警，一段時間后恢復

排查過程：

1、確認問題：nginx大量502異常，即nginx對應的后端服務可能處理很慢或者將請求丟棄了。

2、檢查118機器的cpu，內存，網絡等基礎指標，發現eth0這段時間入口流量驟減，幾乎為0，而且出問題的幾天，時間吻合，其它指標正常，說明流量減少一定是問題的一個主要突破口。

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

4、檢查網絡：發現本機的ping檢測無丟包現象，另外，同個機房的其它機器也都沒有丟包的情況，那么網絡問題就可以被排除了。

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

6、等待了一天。

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

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

8、找到對應的請求地址，以及客戶端，找到客戶端對應的負責人，和其溝通發現：會在每天凌晨大批量調用這個接口導致。

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