現(xiàn)象
凌晨，當(dāng)運維剛躺下，就被業(yè)務(wù)研發(fā)的電話叫醒，"哥們！kafka服務(wù)又異常了？影響到業(yè)務(wù)了，快看看"，業(yè)務(wù)研發(fā)給出的異常日志如下：
基本分析
- 集群檢查：立即確認(rèn)kafka集群以及涉及到topic健康狀態(tài)。集群狀態(tài)正常，收發(fā)消息正常，壓力負(fù)載正常；topic讀寫正常。
- 變更操作：近期未做關(guān)于kafka的任何變更操作，排查變更影響。
- 確定影響范圍：個例問題。問題規(guī)模限定在當(dāng)前業(yè)務(wù)主機。
抓包分析
基本確定異常和集群無關(guān)后，接下來就是要排查網(wǎng)絡(luò)相關(guān)的問題，網(wǎng)絡(luò)和系統(tǒng)（內(nèi)核參數(shù)設(shè)定）是息息相關(guān)的，網(wǎng)絡(luò)問題是復(fù)雜而神秘的，后期會根據(jù)場景給大家分享，今天，我們主要分析網(wǎng)絡(luò)鏈路問題
- 使用tcpdump抓包（客戶端抓包）。
# 抓所有和kafka節(jié)點通信的網(wǎng)絡(luò)數(shù)據(jù)包（因為數(shù)據(jù)量很大，在異常時抓取了幾分鐘的包）
nohup tcpdump port 9092 -w kafka.pcap &
- 報文分析。
- 錯誤日志。
2022-09-30 00:08:53.470 kafka/consumer.go:128 kafka_util,error,consume,group:cop.inke_owt.inno_pdl.user_pushmsg.server,from:user.msg.push.consume,topic:inno_phxyuyin_user_pushmsg_push_msg,err:kafka: error while consuming inno_phxyuyin_user_pushmsg_push_msg/1: write tcp 10.226.11.15:38742->10.226.5.4:9092: write: broken pipe
- 過濾報文（10.226.11.15:38742->10.226.5.4:9092）。
- 報文分析。
- 第477個報文，也就是從2022-09-30 00:07:06.387480時開始，沒有數(shù)據(jù)傳輸了，客戶端每5秒發(fā)一個心跳包（TCP Keep-Alive），從交互報文可以看出很規(guī)律（每5秒一個心跳包和一個響應(yīng)包）。
- 第899個報文，也就是2022-09-30 00:07:56.467480時服務(wù)端響應(yīng)后，在下一個心跳包之前，也就是00:08:01 的時候，并未向服務(wù)端發(fā)送心跳。
- 第940個報文，也就是2022-09-30 00:08:01.376174，這時服務(wù)端給客戶端發(fā)送了FIN包（請求斷開連接），而且客戶端也回復(fù)了ACK包，確認(rèn)斷開連接了。
- 連接已經(jīng)被斷開后，客戶端再次在這個連接上發(fā)送心跳包，收到了服務(wù)端回復(fù)的rst包，程序報錯（write: broken pipe）–管道關(guān)閉了，寫失敗。
分析結(jié)果
- 業(yè)務(wù)主機網(wǎng)絡(luò)存在不穩(wěn)定性，TCP心跳包丟了，導(dǎo)致服務(wù)端沒收到，在00:08:06在次發(fā)送的時候，連接已經(jīng)斷了（最終問題反饋到廠商，廠商技術(shù)同學(xué)反饋宿主機在故障期間有異常，主機做過熱遷移。）
- 5s內(nèi)服務(wù)端收不到客戶端的心跳包，就會主動發(fā)起斷開連接（FIN），斷開鏈接后，客戶端在發(fā)送寫請求，肯定會報broken pipe，異常會被拋出到程序側(cè)。
知識擴展
1、TCP KeepAlive機制是什么？
在TCP長連接下，客戶端和服務(wù)器若長時間無數(shù)據(jù)交互情況下，若一方出現(xiàn)異常情況關(guān)閉連接，另一方無法感知到，引入KeepAlive，當(dāng)長連接無數(shù)據(jù)交互一定時間間隔時，連接的一方會向?qū)Ψ桨l(fā)送保活探測包，如連接仍正常，對方將對此確認(rèn)回應(yīng)。
2、linux系統(tǒng)下KeepAlive內(nèi)核參數(shù)配置
# 允許的持續(xù)空閑時長，或者說每次正常發(fā)送心跳的周期
net.ipv4.tcp_keepalive_time
# 在tcp_keepalive_time之后，最大允許發(fā)送保活探測包的次數(shù)，到達此次數(shù)后直接放棄嘗試，并關(guān)閉連接
net.ipv4.tcp_keepalive_probes
# 在tcp_keepalive_time之后，沒有接收到對方確認(rèn)，繼續(xù)發(fā)送保活探測包的發(fā)送頻率
net.ipv4.tcp_keepalive_intvl
