故障發(fā)生在2023春節(jié)前兩天，DeepFlow 團(tuán)隊(duì)內(nèi)部訪問(wèn)工單系統(tǒng)出現(xiàn)問(wèn)題，影響了所有北京區(qū)的同事，這篇文章將詳細(xì)記錄如何利用 DeepFlow 定位到對(duì)這次問(wèn)題根因（網(wǎng)關(guān) MSS 誤變更導(dǎo)致報(bào)文大于 MTU，大數(shù)據(jù)報(bào)文被丟棄）。
01｜背景介紹
工單系統(tǒng)是 DeepFlow 團(tuán)隊(duì)自主研發(fā)的一個(gè)跟蹤工單的內(nèi)部工具，部署在阿里公有云的容器服務(wù)（ACK）中，工單系統(tǒng)通過(guò) Ingress 的方式對(duì)外提供服務(wù)，辦公區(qū)與阿里云通過(guò) VPN 連接，因此辦公區(qū)可以直接使用域名訪問(wèn)工單系統(tǒng)。在《K8s 服務(wù)異常排障過(guò)程全解密》[1]文中對(duì) K8s 訪問(wèn)方式做過(guò)總結(jié)，工單系統(tǒng)是比較典型的??方式三??的訪問(wèn)形式
集群外客戶端通過(guò) Ingress 訪問(wèn)集群內(nèi)服務(wù)
下圖是通過(guò) DeepFlow 自動(dòng)繪制的訪問(wèn)拓?fù)鋱D，可以看出北京和廣州辦公區(qū)都是通過(guò) Ingress 的形式來(lái)訪問(wèn)工單的入口服務(wù) (ticket_web)。工單系統(tǒng)部署在基礎(chǔ)服務(wù)的容器集群上，此容器集群所有的 Node 上都已經(jīng)部署了 deepflow-agent，因此可以自動(dòng)采集所有 POD 及 Node 的網(wǎng)絡(luò)/系統(tǒng)/應(yīng)用相關(guān)的數(shù)據(jù)，其中就包括阿里云 Nginx-ingress-controller 服務(wù)對(duì)應(yīng)的 POD 以及應(yīng)用的 POD
工單系統(tǒng)訪問(wèn)拓?fù)?/p>
02｜排障過(guò)程
下午 3:00 左右，陸續(xù)收到同事反饋，工單系統(tǒng)加載不出來(lái)，首先和工單系統(tǒng)研發(fā)明確，并未做過(guò)任何變更
故障現(xiàn)場(chǎng)
依據(jù)《K8s 服務(wù)異常排障過(guò)程全解密》[2]總結(jié)的思路
K8s 服務(wù)異常排障思路
查看了對(duì)應(yīng)的 ??Node/POD?? 負(fù)載、狀態(tài)等都正常；登錄到 DeepFlow 平臺(tái)，調(diào)出了工單系統(tǒng)的訪問(wèn)拓?fù)洌ㄍ負(fù)渖蠘?biāo)紅部分表明有異常），從訪問(wèn)拓?fù)淇芍??后端服務(wù)??黃金指標(biāo)也都一切正常；又通過(guò)圖可看出來(lái)廣州辦公室對(duì)工單系統(tǒng)的訪問(wèn)也并沒(méi)有異常（也同步與廣州同事確認(rèn)，訪問(wèn)一切正常），可推測(cè) ??DNS/SVC?? 也應(yīng)該都正常；進(jìn)一步結(jié)合拓?fù)鋱D，可看出異常僅出現(xiàn)在北京辦公室與 nginx-ingress-controller 之間。
訪問(wèn)拓?fù)?/p>
繼續(xù)分析標(biāo)紅的路徑，查看對(duì)應(yīng)的流日志，因?yàn)樵葡挛床渴鸩杉?，因此僅支持查看的是 nginx-ingress-controller POD 以及 Node 的數(shù)據(jù)，發(fā)現(xiàn)了幾個(gè)問(wèn)題：
- 服務(wù)端異常都是因?yàn)?code>傳輸-連接超時(shí)導(dǎo)致的
- 服務(wù)端異常時(shí)，服務(wù)端 (nginx-ingress-controller) 回復(fù)的數(shù)據(jù)包，都是大包
- 服務(wù)端異常時(shí)，服務(wù)端 (nginx-ingress-controller) 都未收到任何客戶端發(fā)送的數(shù)據(jù)
流日志
結(jié)合以上幾點(diǎn)發(fā)現(xiàn)，懷疑方向轉(zhuǎn)移到 MSS/MTU 上，立馬咨詢了 IT 同事，是不是變動(dòng)過(guò)網(wǎng)關(guān)的 MSS/MTU 值，IT 同事否認(rèn)了
聊天記錄-01
既然云下部分未變動(dòng)過(guò)，轉(zhuǎn)而懷疑是不是 nginx-ingress-controller 動(dòng)過(guò) MSS/MTU，通過(guò)??時(shí)序圖??查看 MSS 是否有變化，通過(guò)故障前后對(duì)比可知：
- 客戶端在故障前后發(fā)送的 MSS 確實(shí)發(fā)生過(guò)變動(dòng)，從 1280 變?yōu)榱?1380
- 服務(wù)端 (nginx-ingress-controller) MSS 值一直未變動(dòng)過(guò)
時(shí)序圖
通過(guò)數(shù)據(jù)可明確，云下一定變動(dòng)過(guò) MSS 值，拿著數(shù)據(jù)截圖又去找 IT 同事，最后 IT 同事一頓找，明確改了 MSS 值，將 MSS 值恢復(fù)后，工單系統(tǒng)恢復(fù)正常
聊天記錄-02
03｜問(wèn)題總結(jié)
問(wèn)：MSS 值變動(dòng)了，為什么影響了工單系統(tǒng)
- 因?yàn)樵葡碌?MTU 值設(shè)置的是 1420，如果 MSS 值為 1380 + 報(bào)文頭則會(huì)大于 MTU 值，因此大數(shù)據(jù)報(bào)文無(wú)法通過(guò)云下的網(wǎng)關(guān)，這就導(dǎo)致了 nginx-ingress-controller 收不到任何客戶端的回應(yīng)（客戶端也未收到服務(wù)端的包）出現(xiàn)?
?傳輸-連接超時(shí)??的情況
問(wèn)：MSS 值變動(dòng)了，為什么其他內(nèi)部系統(tǒng)未受到影響
- 工單描述中包含了大量的圖片和文件，因此存在傳輸大數(shù)據(jù)的情況，而其他系統(tǒng)大部分都是文字傳輸，所以未受到明顯影響
- 其他如 gitlab 存在圖片和大文字傳輸?shù)姆?wù)，并未使用 Ingress 的方式對(duì)外提供訪問(wèn)形式，而是利用阿里云 Terway 提供的內(nèi)網(wǎng)直接訪問(wèn) Headless 服務(wù)后端 POD 的方式，在協(xié)商 MSS 值時(shí)，后端 POD 的值為 1360（nginx-ingress-controller 的值為 1460），因此最終協(xié)商的取 1360 + 報(bào)文頭則小于 MTU 值，所以也未受到明顯影響
04｜什么是 DeepFlow
DeepFlow[3] 是一款開(kāi)源的高度自動(dòng)化的可觀測(cè)性平臺(tái)，是為云原生應(yīng)用開(kāi)發(fā)者建設(shè)可觀測(cè)性能力而量身打造的全棧、全鏈路、高性能數(shù)據(jù)引擎。DeepFlow 使用 eBPF、WASM、OpenTelemetry 等新技術(shù)，創(chuàng)新的實(shí)現(xiàn)了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等核心機(jī)制，幫助開(kāi)發(fā)者提升埋點(diǎn)插碼的自動(dòng)化水平，降低可觀測(cè)性平臺(tái)的運(yùn)維復(fù)雜度。利用 DeepFlow 的可編程能力和開(kāi)放接口，開(kāi)發(fā)者可以快速將其融入到自己的可觀測(cè)性技術(shù)棧中。
GitHub 地址：https://github.com/deepflowys/deepflow
訪問(wèn) DeepFlow Demo[4]，體驗(yàn)高度自動(dòng)化的可觀測(cè)性新時(shí)代。
參考資料
[1] 《K8s 服務(wù)異常排障過(guò)程全解密》: ??https://deepflow.yunshan.net/blog/020-k8s-service-exception-troubleshooting/??
[2] 《K8s 服務(wù)異常排障過(guò)程全解密》: ??https://deepflow.yunshan.net/blog/020-k8s-service-exception-troubleshooting/??
[3] DeepFlow: ??https://github.com/deepflowys/deepflow??
[4] DeepFlow Demo: ??https://deepflow.yunshan.net/docs/zh/install/overview/?
