在這篇文章中，我們將詳細探討導致故障的可能原因以及解決方案，以便更好地理解故障排查的復雜性和艱巨性，尤其是當出現與本次故障表現相似的問題時。
故障的表現
首先，讓我們回顧一下故障的表現。在客戶端調用接口時，發(fā)現一直在轉圈等待，而服務器端卻收到了請求并在返回結果給客戶端時報了一些錯誤，包括java.io.IOException: Broken pipe錯誤和Connection reset by peer錯誤。盡管整個查詢鏈路所需時間并不長，大約在2秒左右，但通過使用grafana監(jiān)控工具，我們發(fā)現Nginx的連接數超過了平時的6倍以上。盡管我們已經仔細檢查了各個方面的原因，但仍未找到根本問題所在。但是，我們最終注意到重啟服務可以解決問題，因此我們將目標問題的范圍鎖定在服務器端。
pinpoint錯誤請求數及其分布
Nginx當時的連接數：當時是個很正常日子，并沒什么活動
問題排查
然而，為什么會出現這樣的問題呢？主要原因在于監(jiān)控手段不足，甚至無法生成基本的Java dump文件。在排查過程中，我們只能看到現象而無法找到具體原因。通過pinpoint平臺（類似于skywalking），我們發(fā)現了三種基本錯誤。第一種是之前提到的java.io.IOException: Broken pipe，第二種是Connection reset by peer，第三種是服務器訪問第三方服務器時出現的connection timeout或refuse connection錯誤。雖然之前也發(fā)生過類似的問題，但都是偶爾出現，并沒有像這次一樣數量如此之多，占用了訪問量的1/10。因此，在出現問題時，我們沒有立即重啟，而是進行了仔細排查。然而，最終我們以失敗告終，只能依靠重啟來解決問題。如果你有任何想法，請在下方評論區(qū)留言。
首先，我們排除了一些問題，如數據庫查詢、中間鏈路的轉發(fā)、第三方服務器的調用等，均未發(fā)現問題。盡管我們確實可以確定問題出在服務器節(jié)點上，但具體原因仍然是個謎。
在繼續(xù)探索之前，讓我們先了解一下故障排查的一般步驟。首先，我們需要收集足夠的信息來了解故障的具體表現。這包括錯誤日志、監(jiān)控指標、性能數據等。在本次故障中，我們已經通過監(jiān)控工具獲取了一些有用的信息。接下來，我們需要分析這些信息，并進行合理的假設和推斷。我們還可以嘗試在類似的環(huán)境中重現故障，以進一步觀察和分析。當我們找到可能的原因時，可以進行一系列的測試和驗證，以確定是否解決了問題。最后，我們需要記錄和總結我們的調查過程，以便于日后的參考和經驗積累。
在本次故障排查中，我們遇到了一些挑戰(zhàn)。首先是監(jiān)控手段不足的問題，由于JDK版本的問題導致無法生成Java dump文件。這使得我們無法深入了解故障的具體原因。因此，我們建議在類似的情況下，提前準備好足夠的監(jiān)控工具和技術手段，以便更好地進行故障排查。
另一個挑戰(zhàn)是故障的復現。由于問題并非每次都發(fā)生，我們無法簡單地通過重現來解決。在這種情況下，我們嘗試了在生產環(huán)境協調客戶獲取賬號，并確實復現了問題所在，最終確定了是某一個節(jié)點連接數飆高導致無法處理請求導致的，但是為什么會某一個節(jié)點單獨飆高就不得而知。
最后，我們需要注意故障排查的方法和技巧。在排查過程中，我們應該保持冷靜和耐心，避免盲目猜測和隨意嘗試。我們應該以科學的態(tài)度，根據收集的信息進行分析和推理，不斷迭代和驗證。同時，我們還應該注重團隊合作和知識共享，通過不同的視角和經驗來解決問題。文章來源：http://www.zghlxwxcb.cn/news/detail-746298.html
總結
總之，本次故障排查雖然以失敗告終，但我們從中學到了很多經驗和教訓。故障排查是一項復雜而重要的任務，需要我們具備專業(yè)知識和技術手段。同時，我們還需要保持冷靜和耐心，以科學的態(tài)度進行分析和推理。只有這樣，我們才能更好地解決問題，并為日后的故障排查積累寶貴的經驗。文章來源地址http://www.zghlxwxcb.cn/news/detail-746298.html
到了這里，關于????網絡之謎：記一次失敗排查的故事的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！
