記一次Nginx服務器報502 Connection timed out的排查歷程
一個風和日麗的下午，測試小妹妹心急火燎地突然跑過來說，同樣的腳本，同樣的壓測參數，但在持續壓測2min左右後開始報502錯誤，重要功能平均響應時間嚴重超標。
重現
從測試小妹妹那要來Jmeter腳本，300併發持續5分鐘進行壓測。不出意外，果然2分鐘左右Jmeter就出現502 Bad Gateway錯誤。
伴隨着502報錯的，還有急劇升高的響應時長。
監測Docker容器負載
容器的CPU負載在剛開始併發請求時很高，屬於正常狀態，不過持續觀察發現，當Jmeter收到報錯提示時，此時的CPU負載突然降到很低，持續一段時間才緩慢回升。
監測帶寬
我這裏使用的是nload，它是一個命令行工具，讓用戶可以分開來監控入站流量和出站流量。
# fedora或centos
yum install nload -y
# ubuntu/debian
sudo apt-get install nload
如果只需要快速查看總帶寬使用情況，無需每個進程的詳細情況，那麼nload用起來很方便。
nload
經過觀察發現，跟CPU負載一樣，同一時間段，帶寬使用也突然降低，持續一段時間才緩慢回升。
查看Tomcat日誌
catalina.out中沒看到有報錯日誌
localhost_access_log.txt中看到有異常現象
這個時間段2019-07-09 17:59:05——2019-07-09 17:59:14，也就是Jmeter第一次出現502異常的時間段，並沒有請求進到Tomcat中
查看Nginx日誌
同一時間段error.log中出現超時日誌
初步推斷
一般出現超時問題，第一反應就是應用服務存在性能問題，沒法及時處理併發請求，導致響應時長超過等待時間。這時候就考慮找出慢SQL，優化SQL，優化索引，引入緩存，優化業務，調優Nginx、Tomcat配置等。
通過日誌分析，暫時可以判定無法響應請求應該來自應用服務鏈路的前一節點，也就是Nginx。
但假設Nginx出了問題，導致超時，那Tomcat那頭肯定是有訪問日誌的，現在是壓根就沒請求進入Tomcat。
這種情況，很像很久之前系統第一次壓測時遇到的TCP連接問題，服務器資源設置過小，導致過多的連接無法進入隊列，直接被服務器端拒絕，但很早就已經進行過內核參數調優了，姑且再覈查一遍內核參數吧
內核參數排查
cat /etc/sysctl.conf
恩…內核參數看起來沒什麼問題，但有時候最好不要太相信自己的眼睛
執行命令：
sysctl -p
如果系統沒有錯誤提示，就表明系統對內核參數應用成功。
額，出現了錯誤提示，根據錯誤提示重新設定了key值，重新執行命令，沒有報錯
重新300併發，持續壓測了1個小時，未看到異常，並且響應時長已恢復到正常水平
總結
- 根據日誌分析錯誤出現在哪一環
- 眼見不一定爲實