[[349024]]

 最近幫新來的校招同學排查一個線上問題，問題本身不是很難，但是過程中踩到了一個arthas的坑，挺有意思的。

同時，也分享下在排查過程中使用的一些比較實用的工具，包括tcpdump、arthas、simpleHTTPServer等。

希望能對大家有所幫助。

1.問題描述
新開發的一個功能，簡單來說，就是讀取數據庫的數據展示在前臺。

本地啟動服務調試，用postman調用api，返回數據顯示正常，數據中的中文也正常。

但是部署到線上環境后，通過chrome瀏覽器調用和postman調用接口，返回的非中文數據正常，但是中文顯示亂碼。

2.排查思路
這個問題的第一反應是請求的content-type有問題。

不過在chrome瀏覽器中確認了請求的request和response的content-type都是application/json;charset=UTF-8，沒有問題。

然后又google了一番亂碼問題，基本上都是說的spring的HttpMessageConverter問題或者content-type，都無法解決。

只能深入排查一番了。

排查的主要思路就是先確定亂碼是哪一步產生的。

一個就是數據庫里查出來地方，需要用抓個包確認下，不過我們本地服務調用是正確的，那么這一步應該沒有問題。

一個是應用服務返回的地方，需要用抓個包確認下。在線上部署環境里，用tcpdump把對應的應用服務返回數據時抓個包。

一個就是代碼邏輯中存在數據轉換，這個需要通過arthas看看線上應用的運行時數據情況。

3.用tcpdump抓包看服務端響應
3.1 什么是tcpdump呢？
tcpdump是linux下的網絡數據包截獲分析工具。在linux的日常網絡管理中，tcpdump的使用頻率很高，熟練掌握對提高工作效率很有幫助。

3.2 報文抓取
為了獲取對應服務的請求報文，需要登錄對應的服務器（或者k8s的pod）使用tcpdump進行抓取。

作為一個暖男，我把從安裝到使用都一步步記下來給你 ：）

1）安裝工具

如果你的服務器上沒有安裝過tcpdump，可以先執行以下命令安裝

yum -y install net-tools 

2）查看網絡狀態

如果服務上有多個網卡，可以通過以下命令查看

Netstat -i 

3）部署抓包

tcpdump -i eth0 tcp -w xxx.cap 

• en0表示監聽的網卡
• tcp表示報文類型
• -w 指定輸出文件名

還有很多其他選項可以過濾使用，大家可以網上搜一下，這里就不展開了。

4）調用請求

部署了tcpdump后，對服務器發起api請求。這時候相關的tcp報文都會被輸出到 xxx.cap文件中了。

3.3 報文解析
1）把xxx.cap文件發送本地

一般可以使用scp命令，直接發送

scp xxxx.cap admin@10.xxx.xxx.xxx:/path 

在傳輸服務器的文件到本地時，如果scp不方便使用，比如一些防火墻限制。

也可以使用 python 在服務器上開啟一個 web 服務(端口可自定義)。

python -m SimpleHTTPServer 18888 & 

然后在本地使用 wget 下載文件即可。

2）解析cap文件

本地得到cap文件后，可以通過wireshark軟件對cap文件進行解析，得到如下結果。

對api的報文進行解析后，發現返回對中文已經是亂碼了，確認了在服務端發出的響應內容中，已經是亂碼了。

所以，只能繼續排查應用本身的問題。

4.用arthas排查線上運行代碼
Arthas 是Alibaba開源的Java診斷工具，當你遇到以下類似問題而束手無策時，都可以嘗試使用Arthas（更詳細的用法參考官方文檔：https://arthas.aliyun.com/doc/quick-start.html）：

• 這個類從哪個 jar 包加載的？為什么會報各種類相關的 Exception？
• 遇到問題無法在線上 debug，又不想頻繁加日志再重新發布
• 線上遇到某個用戶的數據處理有問題，但線上同樣無法 debug，線下無法重現！

4.1 快速安裝、啟動

curl -O https://arthas.aliyun.com/arthas-boot.jar 
 
java -jar arthas-boot.jar 

4.2 運行代碼返回排查
本次排查，就使用了arthas的watch功能（更詳細的用法參考官方文檔：https://arthas.aliyun.com/doc/watch.html），能方便的觀察到指定方法的調用情況。能觀察到的范圍為：返回值、拋出異常、入參。

我們先看看線上運行應用controller層對于請求的響應，無需添加日志重新部署，我們馬上就能看到線上代碼的返回結果。

watch xxx.xxx.controller method "{params,returnObj}" -x 2 

然后發起api調用，在arthas中顯示結果如下：

我們可以看到，這個controller方法返回的內容就是亂碼了。

因此，說明是代碼邏輯中存在轉換的問題了。

5.問題定位
根據業務邏輯，基本能猜測是從業務中的 byte[] 轉string的時候出現問題了。

找到對應代碼如下，new string()時沒有指定字符集：

因此會在轉換過程中，默認讀取系統變量的file.encoding作為字符集。

然后我們用arthas直接查看系統變量，果然不是utf8。

所以，解決方案有兩個。

第一種是在new string(bytes) 時指定字符集。

第二種就是設置系統變量file.encoding=utf-8。

 

5.進一步踩坑
我們一開始選擇了代碼修復，在代碼中轉換時指定字符集。

重新發布后，再用arthas觀察一下，發現竟然還是亂碼？！！

然后重新回頭在代碼中看了很久，一直找不到原因，陷入了僵局。。。

 

突然，隨手看了下線上，發現線上已經顯示正常了，納尼？是arthas有問題？

然后google了一下，發現很多人碰到arthas顯示中文亂碼的問題。。。

解決方式也比較簡單，啟動arthas的時候，也指定一下字符集。

java -jar -Dfile.encoding=UTF-8 arthas-boot.jar

然后問題解決了。。。呵呵。。。

這時候再觀察arthas的結果已經顯示正常。

這說明了什么？！！！！

Arthas輸出界面的時候，肯定在字符串轉換的時候，也沒有指定字符集。。。。

一腳踩了個連環坑。。。

6.總結
其實整個問題是比較粗淺的，就是最后這個arthas的中文亂碼讓人有點腦殼疼。

當然，最主要還是簡單分享下tcpdump、arthas、simpleHTTPServer這些小工具，希望能有所幫助吧。