背景
我司使用的是亞馬遜廠商的云服務，廠商的消息隊列產品我們并沒有用，我們選擇自建，自建的好處是更靈活，定制性更廣。公司內部有多套Kafka集群，100+broker節點，針對kafka我司也有比較完善的自動化運維管理體系，最近出現過一次業務連接kafka集群頻繁超時的情況，在這里記錄下處理過程，加深對網絡知識的理解。
問題現象
業務收到服務可用性下降報警，分析日志發現是連接亞馬遜kafka集群有頻繁超時，超時日志如下：
基本分析
- 影響因素：多臺主機同時報警，排查單臺主機問題。
- 集群檢查：立即確認kafka集群以及涉及到topic健康狀態。集群狀態正常，收發消息正常，壓力負載正常；topic讀寫正常。
- 變更操作：近期未做關于kafka的任何變更操作，排查變更影響。
- 確定影響范圍：確認其他業務是否有超時情況。大部分業務反饋未出現超時情況，問題規模限定在當前業務。
定位
網絡問題從表面看不到細節，只能通過抓包分析，同時抓取了客戶端和服務端的數據包，抓包命令如下：
# 客戶端（抓所有和kafka節點通信的網絡數據包）
nohup tcpdump port 9092 -w kafka.pcap &
# 服務端（抓所有和客戶端主機通信的數據包）
nohup tcpdump host 10.66.67.166 -s0 -w 10.66.67.166.pcap &
說明： 開啟抓包后，在客戶端主機過濾超時日志，出現超時后即可停止抓包操作。
數據包分析
- 錯誤日志：
- 2023-05-24 20:46:29.947 kafka client/metadata got error from broker while fetching metadata: read tcp 10.66.67.166:37272->10.68.0.151:9092: i/o timeout
- 客戶端報文
- 服務端報文
- 報文分析
- 客戶端報文：
- 在序號為793以上的報文都收到了服務端的響應，而且可以看到使用的是kafka協議進行了消息的投遞（kafka produce respone）。
- 在序號為794的時候，客戶端發送了7個長度是8514的tcp報文，未看到服務端的回應。
- 在序號是803，804的時候，客戶端又發送了2個長度的tcp報文。
- 從序號是807開始，發現客戶端重傳了之前發送的所有長度是8514的tcp報文。（丟包了。客戶端未收到服務端的響應所以重傳了）。
- 服務端報文。
- 從服務端看，客戶端前面的幾個tcp報文都被服務端正常處理。（前面的報文長度都很小，小于1000）。
- 客戶端發送的9個長度為8514的包，服務端根本沒收到。
- 服務端等待了60s后，關閉了tcp連接。（服務端配置的空閑連接時間就是1min，符合預期）。
丟包問題分析
- 被丟棄的數據報長度都比較大，是否是報長度過大的問題？
- 查詢機器的網卡mtu配置，發現是9001（TCP/IP 巨型幀），隨機使用ping命令指定size進行測試。
- TCP 最大段大小（Max Segment Size，MSS）是會根據網卡設置的mtu值決定，即使設置的是9001，測試最大MSS最大支持到8468，超過后就直接丟了。
- 對比測試規律總結
- 騰訊、阿里主機（mtu=1500）：因為網卡配置的都是1500，所以不存在報過大丟棄的情況。
- 亞馬遜主機（mtu=9001）：包大于8468后，就會直接丟棄（問題產生在新老賬戶通信上）。
刨根問底
其他亞馬遜業務網卡mtu配置配置也是9001，為啥沒問題？
- 第一時間和出問題的業務方確認業務是否有調整或者變更，他們說明了服務沒有調整，他們在亞馬遜有開了一個新賬戶部署了服務，目前業務訪問是跨賬戶調用。
聯系廠商確認跨賬戶網絡鏈路。
- mtu 問題反饋給廠商技術支持人員，給到的結論是：新老賬戶網絡連通設備(TGC)，最大的mtu上限是8500，所以我們通過網關設備的包就丟棄了。
解放方案
- 調整主機mtu值，已匹配廠商的mtu限制。
# 臨時生效
ip link set dev eth0 mtu 1500
永久生效
vim /etc/sysconfig.NETwork-scripts/ifcfg-eth0 增加如下內容
MTU="9000"
# service network restart
