線上問題排查的四類方法
最正統的方法
日誌
這是排查問題的最常用的方法，需要預估自己每日日誌量和需要儲存的日誌時間。申請磁碟空間時一般會留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，請求打到斷點卡在那裡了。
總結
事實、資料、推論、猜測
推薦閱讀