線上問題排查的四類方法
- 2019 年 10 月 3 日
- 筆記
最正統的方法
日誌
這是排查問題的最常用的方法，需要預估自己每日日誌量和需要存儲的日誌時間。申請磁碟空間時一般會留35%的冗餘以備突發流量。
一般需要打日誌的有：每個對外提供方法的入口和出口，調用第三方的調用前和調用後。列印內容主要包括入參和出參。https://github.com/xiexiaojing/concise-logger 我在簡明日誌規範里定義：幾種常用的類里用切面的形式注入日誌。
監控
傳統的方法如果JVM出現gc等問題需要先打開gc日誌，這會犧牲一些效率。但是現在業界已經普遍將這些數據上報到系統中，比如歐美常用的prometheus，中國用小米的falcon比較多。
對於資料庫、調用量、響應時長等監控系統也都有統計。美團點評的CAT不僅集成了這些，還集成了依賴分析、依賴分析、心跳報表、業務大盤等。挺方便的。
報警
報警不僅可以發現問題，還可以將發生問題時已經執行到的階段作為報警資訊一起發出，便於快速定位。
linux命令
tcpdump
如果收到不明數據，又不知道數據從哪裡來的，最簡單的方法就是tcpdump進行抓包分析，確定數據來源。
netstat
通常用來監聽連接埠的狀態。常見的狀態主要有：
-
listen狀態：正在監聽來自遠方的TCP埠的鏈接請求。
-
syn-sent狀態：在發送鏈接請求後等待匹配的連接請求。
-
syn-received狀態：在收到和發送一個鏈接請求後等待對方對鏈接請求的確認。
-
established狀態：代表一個打開的鏈接。
-
fin-wait-1狀態：等待遠程tcp連接中斷請求，或先前的鏈接中斷請求的確認。
-
fin-wait-2狀態：從遠程tcp等待鏈接中斷請求。
-
close-wait狀態：等待從本地用戶發來的鏈接中斷請求。
-
closing狀態：等待遠程tcp對鏈接中斷的確認。
-
last-ack狀態：等待原來的發現遠程tcp的鏈接中斷請求的確認。
-
tie-wait狀態：等待足夠的時間以確保遠程tcp接收到連接中斷請求的確認。
-
closed狀態：沒有任何連接狀態。
再現
我無數次的假裝路過，只是為了與你一次偶然的邂逅……
這句話用到希望復現線上問題時，往往描述到位的想哭。
如果線上運行的程式遇到問題需要排查，建議優先使用最正統的方法，不行的話linux命令也可以接受。記憶體泄漏、並發問題等的再現成本很高。並且極其不利用快速恢復。
線上調試
如果再現之後還不不能確定問題的原因，還有最後一招不到萬不得已不要用：線上調試。
工具：線上機器是linux系統，本地intelij
複製下面的資訊
在線上啟動參數中加上上面資訊，重啟。
sudo svc -du /service/XXXX/
看看監聽埠有沒有起來
lsof -i :8083
起來後，本地inteij開啟遠程debug即可。記得之前有次線上事故就是有個小哥在線上開啟遠程debug，請求打到斷點卡在那裡了。
總結
事實、數據、推論、猜測
推薦閱讀
