現(xiàn)象

凌晨，當運維剛躺下，就被業(yè)務研發(fā)的電話叫醒，"哥們！kafka服務又異常了？影響到業(yè)務了，快看看"，業(yè)務研發(fā)給出的異常日志如下：

基本分析

• 集群檢查：立即確認kafka集群以及涉及到topic健康狀態(tài)。集群狀態(tài)正常，收發(fā)消息正常，壓力負載正常；topic讀寫正常。
• 變更操作：近期未做關于kafka的任何變更操作，排查變更影響。
• 確定影響范圍：個例問題。問題規(guī)模限定在當前業(yè)務主機。

抓包分析

基本確定異常和集群無關后，接下來就是要排查網(wǎng)絡相關的問題，網(wǎng)絡和系統(tǒng)（內(nèi)核參數(shù)設定）是息息相關的，網(wǎng)絡問題是復雜而神秘的，后期會根據(jù)場景給大家分享，今天，我們主要分析網(wǎng)絡鏈路問題

• 使用tcpdump抓包（客戶端抓包）。

# 抓所有和kafka節(jié)點通信的網(wǎng)絡數(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秒一個心跳包和一個響應包）。
• 第899個報文，也就是2022-09-30 00:07:56.467480時服務端響應后，在下一個心跳包之前，也就是00:08:01 的時候，并未向服務端發(fā)送心跳。
• 第940個報文，也就是2022-09-30 00:08:01.376174，這時服務端給客戶端發(fā)送了FIN包（請求斷開連接），而且客戶端也回復了ACK包，確認斷開連接了。
• 連接已經(jīng)被斷開后，客戶端再次在這個連接上發(fā)送心跳包，收到了服務端回復的rst包，程序報錯（write: broken pipe）–管道關閉了，寫失敗。

分析結(jié)果

• 業(yè)務主機網(wǎng)絡存在不穩(wěn)定性，TCP心跳包丟了，導致服務端沒收到，在00:08:06在次發(fā)送的時候，連接已經(jīng)斷了（最終問題反饋到廠商，廠商技術同學反饋宿主機在故障期間有異常，主機做過熱遷移。）
• 5s內(nèi)服務端收不到客戶端的心跳包，就會主動發(fā)起斷開連接（FIN），斷開鏈接后，客戶端在發(fā)送寫請求，肯定會報broken pipe，異常會被拋出到程序側(cè)。

知識擴展

1、TCP KeepAlive機制是什么？

在TCP長連接下，客戶端和服務器若長時間無數(shù)據(jù)交互情況下，若一方出現(xiàn)異常情況關閉連接，另一方無法感知到，引入KeepAlive，當長連接無數(shù)據(jù)交互一定時間間隔時，連接的一方會向?qū)Ψ桨l(fā)送保活探測包，如連接仍正常，對方將對此確認回應。

2、Linux系統(tǒng)下KeepAlive內(nèi)核參數(shù)配置

# 允許的持續(xù)空閑時長，或者說每次正常發(fā)送心跳的周期
net.ipv4.tcp_keepalive_time 

# 在tcp_keepalive_time之后，最大允許發(fā)送?；钐綔y包的次數(shù)，到達此次數(shù)后直接放棄嘗試，并關閉連接
net.ipv4.tcp_keepalive_probes

# 在tcp_keepalive_time之后，沒有接收到對方確認，繼續(xù)發(fā)送?；钐綔y包的發(fā)送頻率
net.ipv4.tcp_keepalive_intvl