悲催的事情
今天下午2點多（時間發生故障的時間是14:14 ，反饋時間卻是：14:25 ）收到運營推廣部門同事告知，網站打不開了，這個煩呀，怎么會打不開了，由於以前的系統有問題，都重新寫了，切換到新的系統上面了，打不開就直接報錯了，報錯頁面如下
分析過程
找到錯誤日志
出現錯誤不可怕，這一點我們必須第一時間明確，千萬不要擔心，擔心解決不了任何問題。 對我們最有幫助的就是各種業務日志。通過查閱日志得出如下的錯誤，當時出現了大量的錯誤日志
curl: (56) Recv failure: Connection reset by peer
如下是我們的業務架構圖
可以我們S1 通過API 接口 訪問 S2 ， 我們的錯誤日志就是在S1上面發現的，因為我們所有的http請求都是通過一個類發出去的，會進行文件日志存儲，大致代碼如下。
言歸正傳，找到錯誤信息只是第一步，得基於日志進行分析具體問題，而接近問題
分析錯誤
第一種猜測：認為 S2 API出問題了，然后去S2服務器看請求日志和load 負載都不高，內存也沒有問題。那么可以排除。
第二種猜測：Yii2 S1 站點代碼出問題了，當第一個人反饋的我還有這種猜測，但是隨着其他人反饋我知道，肯定不是代碼問題。排除
這個時候我心里其實知道一定是流量"大"導致的，因為當天把老系統10來個域名切換到新的系統了，那么就會導致新的系統訪問量增加。這是今天系統唯一變化的地方，在排查錯誤過程中有個原則就是 本來是好的，現在不好了，那么從好到不好這期間應該有什么東西變化了，這個變化的就是我們要第一優先級考慮的線索。
臨時處理方法：問題解決不了，但是我們不能一直有時間去慢慢排查，因為每天的運營推廣費用總體都有幾十萬了，那么我們就做一個動作：將今天切換的域名切回老系統，先讓業務恢復。這么操作之后臨時恢復了可以訪問。
但是這只是為我們爭取到了時間，讓我們有更多的時間排查錯誤，那么繼續猜測下去。
第三個猜測：既然S2 API 服務沒問題,那么問題應該在S1上面，我就在S1服務使用命令 curl 訪問了下，報錯同樣的（如下圖），這時候見鬼了，我就跑到另外一台服務器暫時叫S3 使用同樣的curl 可以訪問。此時就可以完全確定 S1 服務的問題，無論什么問題肯定這台機器出問題了
定位問題
基於第三個猜測的方向，定位問題情況，那么我們就可以在S1上面更加仔細的排查了，我看了機器的各種硬件指標是正常的（CPU LOAD，內存，網卡的流量），如下圖一切正常，完全訪問沒壓力（下圖中的內存使用率不對，因為沒有加上 buffer 的，實際內存還剩余很多）。這個時候陷入了僵局，
的確是很久不做運維一線工作了，敏感度不夠，我就找了一個運維朋友問了下，真的是一語驚醒夢中人，我結合今天的動作增加流量 我覺得他的說法是對的，然后我就按照這個思路去驗證。
解決問題
基於我運維朋友的指點，我看了S1的文件句柄真的很小，就是1024，我看了當時的請求量比平時多了3倍，所以不夠很正常，我就把句柄數設置更大了，很多朋友說 這樣只是修改了優化參數，如何驗證咧？
驗證問題
問題是必然要被解決的，既然有了新系統那么必然是要切換的，不把問題解決就沒辦法完全切過去。我就讓把今天添加的域名一點點的加，看看請求戶會不會出現問題，有點壓力測試的感覺。直接我們說結果：把所有域名切換到新系統，並還多加了幾個域名 發現 S1服務器 屁事都沒有，壓力完全沒有，我就說嘛在我的印象中一台 4核8G 服務器 怎么承受這點壓力都受不住了。
總結
在這個過程大家可以看到一個大致的排查錯誤的一個方式方法 如下圖。這里面有一個過程有點反過來的感覺：解決問題->驗證問題，大部分思維應該是 驗證問題->解決問題 。這里面是因為我們前面臨時解決問題了，導致沒辦法直接驗證，而要先把問題解決了在驗證
不足之處
報警機制不夠完善，導致沒有第一時間報警
服務器初始化做的不夠完善，導致服務器優化配置出問題
后續基於以上的不足我們這邊會完善運維系統，為企業提供高可用服務保駕護航
原文地址： curl: (56) Recv failure: Connection reset by peer 分析解決過程
標簽： linux centos curl 推廣