背景

我司使用的是亞馬遜廠商的云服務(wù)，廠商的消息隊(duì)列產(chǎn)品我們并沒有用，我們選擇自建，自建的好處是更靈活，定制性更廣。公司內(nèi)部有多套Kafka集群，100+broker節(jié)點(diǎn)，針對kafka我司也有比較完善的自動(dòng)化運(yùn)維管理體系，最近出現(xiàn)過一次業(yè)務(wù)連接kafka集群頻繁超時(shí)的情況，在這里記錄下處理過程，加深對網(wǎng)絡(luò)知識的理解。

問題現(xiàn)象

業(yè)務(wù)收到服務(wù)可用性下降報(bào)警，分析日志發(fā)現(xiàn)是連接亞馬遜kafka集群有頻繁超時(shí)，超時(shí)日志如下：

基本分析

• 影響因素：多臺主機(jī)同時(shí)報(bào)警，排查單臺主機(jī)問題。
• 集群檢查：立即確認(rèn)kafka集群以及涉及到topic健康狀態(tài)。集群狀態(tài)正常，收發(fā)消息正常，壓力負(fù)載正常；topic讀寫正常。
• 變更操作：近期未做關(guān)于kafka的任何變更操作，排查變更影響。
• 確定影響范圍：確認(rèn)其他業(yè)務(wù)是否有超時(shí)情況。大部分業(yè)務(wù)反饋未出現(xiàn)超時(shí)情況，問題規(guī)模限定在當(dāng)前業(yè)務(wù)。

定位

網(wǎng)絡(luò)問題從表面看不到細(xì)節(jié)，只能通過抓包分析，同時(shí)抓取了客戶端和服務(wù)端的數(shù)據(jù)包，抓包命令如下：

# 客戶端（抓所有和kafka節(jié)點(diǎn)通信的網(wǎng)絡(luò)數(shù)據(jù)包）
nohup tcpdump  port 9092 -w kafka.pcap & 
# 服務(wù)端（抓所有和客戶端主機(jī)通信的數(shù)據(jù)包）
nohup tcpdump host 10.66.67.166 -s0 -w 10.66.67.166.pcap &

說明： 開啟抓包后，在客戶端主機(jī)過濾超時(shí)日志，出現(xiàn)超時(shí)后即可停止抓包操作。

數(shù)據(jù)包分析

• 錯(cuò)誤日志：
• 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
• 客戶端報(bào)文

• 服務(wù)端報(bào)文

• 報(bào)文分析
• 客戶端報(bào)文：
• 在序號為793以上的報(bào)文都收到了服務(wù)端的響應(yīng)，而且可以看到使用的是kafka協(xié)議進(jìn)行了消息的投遞（kafka produce respone）。
• 在序號為794的時(shí)候，客戶端發(fā)送了7個(gè)長度是8514的tcp報(bào)文，未看到服務(wù)端的回應(yīng)。
• 在序號是803，804的時(shí)候，客戶端又發(fā)送了2個(gè)長度的tcp報(bào)文。
• 從序號是807開始，發(fā)現(xiàn)客戶端重傳了之前發(fā)送的所有長度是8514的tcp報(bào)文。（丟包了。客戶端未收到服務(wù)端的響應(yīng)所以重傳了）。
• 服務(wù)端報(bào)文。
• 從服務(wù)端看，客戶端前面的幾個(gè)tcp報(bào)文都被服務(wù)端正常處理。（前面的報(bào)文長度都很小，小于1000）。
• 客戶端發(fā)送的9個(gè)長度為8514的包，服務(wù)端根本沒收到。
• 服務(wù)端等待了60s后，關(guān)閉了tcp連接。（服務(wù)端配置的空閑連接時(shí)間就是1min，符合預(yù)期）。

丟包問題分析

• 被丟棄的數(shù)據(jù)報(bào)長度都比較大，是否是報(bào)長度過大的問題？
• 查詢機(jī)器的網(wǎng)卡mtu配置，發(fā)現(xiàn)是9001（TCP/IP 巨型幀），隨機(jī)使用ping命令指定size進(jìn)行測試。
• TCP 最大段大小（Max Segment Size，MSS）是會(huì)根據(jù)網(wǎng)卡設(shè)置的mtu值決定，即使設(shè)置的是9001，測試最大MSS最大支持到8468，超過后就直接丟了。

• 對比測試規(guī)律總結(jié)

• 騰訊、阿里主機(jī)（mtu=1500）：因?yàn)榫W(wǎng)卡配置的都是1500，所以不存在報(bào)過大丟棄的情況。
• 亞馬遜主機(jī)（mtu=9001）：包大于8468后，就會(huì)直接丟棄（問題產(chǎn)生在新老賬戶通信上）。

刨根問底

其他亞馬遜業(yè)務(wù)網(wǎng)卡mtu配置配置也是9001，為啥沒問題？

• 第一時(shí)間和出問題的業(yè)務(wù)方確認(rèn)業(yè)務(wù)是否有調(diào)整或者變更，他們說明了服務(wù)沒有調(diào)整，他們在亞馬遜有開了一個(gè)新賬戶部署了服務(wù)，目前業(yè)務(wù)訪問是跨賬戶調(diào)用。

聯(lián)系廠商確認(rèn)跨賬戶網(wǎng)絡(luò)鏈路。

• mtu 問題反饋給廠商技術(shù)支持人員，給到的結(jié)論是：新老賬戶網(wǎng)絡(luò)連通設(shè)備(TGC)，最大的mtu上限是8500，所以我們通過網(wǎng)關(guān)設(shè)備的包就丟棄了。

解放方案

• 調(diào)整主機(jī)mtu值，已匹配廠商的mtu限制。

# 臨時(shí)生效
ip link set dev eth0 mtu 1500
永久生效
vim  /etc/sysconfig/network-scripts/ifcfg-eth0   增加如下內(nèi)容
MTU="9000"
# service network restart