[[415271]]

一、背景

隨著軟件應(yīng)用的集群化、容器化、微服務(wù)化，產(chǎn)品的穩(wěn)定性越來(lái)越依賴(lài)網(wǎng)絡(luò)?，F(xiàn)有的專(zhuān)有云和一體機(jī)產(chǎn)品，部署在裸機(jī)，從硬件服務(wù)器、交換機(jī)到os都是不可靠的，且監(jiān)控盲區(qū)較多，其中網(wǎng)絡(luò)是重災(zāi)區(qū)。對(duì)于網(wǎng)絡(luò)不穩(wěn)定導(dǎo)致的中間件鏈接超時(shí)、設(shè)備掉線、視頻推流卡頓等問(wèn)題，缺乏有效的網(wǎng)絡(luò)層監(jiān)控指標(biāo)定界問(wèn)題。一旦現(xiàn)場(chǎng)不存在，由網(wǎng)絡(luò)引發(fā)的問(wèn)題很難定位?，F(xiàn)有的網(wǎng)絡(luò)監(jiān)控方案，都集中在網(wǎng)卡維度做流量、錯(cuò)包等指標(biāo)統(tǒng)計(jì)，粒度過(guò)粗，只有從Socket和TCP連接維度，監(jiān)控socket緩存狀態(tài)，采集TCP建連、斷開(kāi)、實(shí)時(shí)流量、延遲、重傳等信息，才可以最直接的反映業(yè)務(wù)的網(wǎng)絡(luò)狀態(tài)。

二、目標(biāo)

現(xiàn)有的網(wǎng)絡(luò)監(jiān)控工具如 ss、netstat 等，可以顯示服務(wù)器當(dāng)前 Socket 狀態(tài)快照，在問(wèn)題現(xiàn)場(chǎng)可以有效的輔助我們排查問(wèn)題。當(dāng)現(xiàn)場(chǎng)不存在，我們希望能有工具能保存歷史網(wǎng)絡(luò)狀態(tài)。然而單純記錄歷史 Socket 五元組信息，在復(fù)雜拓?fù)鋱?chǎng)景是不夠的，因?yàn)镮P很可能是動(dòng)態(tài)的，還須將當(dāng)前時(shí)刻的 Socket 連接和業(yè)務(wù)屬性（Pod Name、設(shè)備身份...）關(guān)聯(lián)，才能達(dá)到還原問(wèn)題現(xiàn)場(chǎng)，快速界定故障域的目的。

1.典型場(chǎng)景

集群中間件訪問(wèn)超時(shí)問(wèn)題定界。
數(shù)據(jù)采集丟包問(wèn)題定界：例如設(shè)備側(cè)聲稱(chēng)發(fā)包，但網(wǎng)關(guān)沒(méi)有收到，現(xiàn)場(chǎng)不在了，互相扯皮。
設(shè)備連云鏈路檢測(cè)。
視頻直播卡頓問(wèn)題定界。
...
2.能力綜述

Socket維度信息采集

流量(tx/rx)、延遲(srtt)，待重傳包數(shù)量、總重傳次數(shù)、收發(fā)隊(duì)列長(zhǎng)度，Accept隊(duì)列長(zhǎng)度。
TCP 生命周期監(jiān)控：監(jiān)聽(tīng)TCP Close事件，統(tǒng)計(jì)連接時(shí)長(zhǎng)，收發(fā)包總字節(jié)數(shù)。
TCP Reset異常監(jiān)控：收到或者發(fā)送Reset的異常，及異常時(shí)刻的TCP State。
云原生監(jiān)控方案適配

現(xiàn)有的netstat、ss等網(wǎng)絡(luò)信息統(tǒng)計(jì)工具，無(wú)法做到跨network namespce的socket信息統(tǒng)計(jì)。在云原生環(huán)境使用不便。需要做到監(jiān)控k8s集群所有節(jié)點(diǎn)，及節(jié)點(diǎn)上所有Pod的Socket狀態(tài)。
采集數(shù)據(jù)指標(biāo)化，支持對(duì)接 Prometheus 的 Exporter 接口。
支持指標(biāo)推送到 VictoriaMetrics。

指標(biāo)選取原理

TCP的指標(biāo)有很多，為什么采集上述的指標(biāo)信息，出發(fā)點(diǎn)是希望找到可以反映應(yīng)用程序狀態(tài)和網(wǎng)絡(luò)連通狀態(tài)指標(biāo)，如果有其它指標(biāo)采集建議也歡迎留言。下面展開(kāi)分析下上述指標(biāo)的采集原因：

1）TCP Retransmit

包重傳的超時(shí)時(shí)間是RTO，通常是200ms左右，當(dāng)我們觀察到一段時(shí)間出現(xiàn)了TCP包重傳，后續(xù)又恢復(fù)正常了，可以判斷這個(gè)時(shí)間段出現(xiàn)了網(wǎng)絡(luò)抖動(dòng), 就可以找網(wǎng)絡(luò)的同學(xué)來(lái)幫忙排查問(wèn)題了。

2）TCP SRTTRTT

(round-trip time)為數(shù)據(jù)完全發(fā)送完（完成最后一個(gè)比特推送到數(shù)據(jù)鏈路上）到收到確認(rèn)信號(hào)的時(shí)間。

SRTT(smoothed round trip time)是平滑過(guò)的RTT。

通過(guò)srtt歷史曲線圖或柱狀圖，觀察出來(lái)延遲的區(qū)間變化，就可以知道網(wǎng)絡(luò)連接的srtt是否抖動(dòng)。如果業(yè)務(wù)延遲發(fā)生了抖動(dòng)，srtt很穩(wěn)定，就可以說(shuō)明大概率不是網(wǎng)絡(luò)的問(wèn)題，可能是業(yè)務(wù)的問(wèn)題，或者調(diào)度的問(wèn)題等等; 反之，如果srtt也發(fā)生了抖動(dòng)，那么可以先檢查一下網(wǎng)絡(luò)連接。

3）TCP Tx/Rx

監(jiān)控鏈接的流量，結(jié)合對(duì)現(xiàn)場(chǎng)業(yè)務(wù)的理解，在業(yè)務(wù)出現(xiàn)丟失數(shù)據(jù)場(chǎng)景，可以輔助定位時(shí)網(wǎng)絡(luò)問(wèn)題還是應(yīng)用問(wèn)題：

傳輸層收到數(shù)據(jù)，但堆積在rcv_queue中，可能是應(yīng)用層處理代碼阻塞。
傳輸層Rx沒(méi)有增加，則很可能是對(duì)端沒(méi)有發(fā)送數(shù)據(jù)。

4）TCP reset reasons

Reset 包是導(dǎo)致TCP異常斷開(kāi)的常見(jiàn)原因之一，下面對(duì)可能觸發(fā) reset 事件的原因做一個(gè)匯總（如有錯(cuò)漏歡迎補(bǔ)充）：

Non-Existence TCP endpoint: Port or IP（Restrict Local IP address）：服務(wù)端不存在。(SYN -> Server reset)
TCP SYN matches existing sessions：服務(wù)端、或者防火墻已存在相同5元組連接。(SYN -> Server reset)
Listening endPoint Queue Full ：應(yīng)用層沒(méi)有及時(shí)accept，導(dǎo)致服務(wù)端Accept隊(duì)列滿(mǎn)（全鏈接隊(duì)列滿(mǎn)），分兩種情況：對(duì)于新來(lái)握手請(qǐng)求 SYN -> SYN包會(huì)被Server默默丟棄，不會(huì)觸發(fā)reset；碰巧在Client 回 ACK(握手第三個(gè)包)時(shí)，accept 隊(duì)列滿(mǎn)了，Server 會(huì)根據(jù) tcp_abort_on_overflow sysctl 配置，決定是否發(fā)送 reset。
Half-Open Connections：服務(wù)端程序重啟，導(dǎo)致鏈接信息丟失。(中間數(shù)據(jù)-> Server reset)
RESET by Firewalls in transit：在防火墻維護(hù)session狀態(tài)的場(chǎng)景（NAT網(wǎng)關(guān)），防火墻Session TTL過(guò)期。(中間數(shù)據(jù)-> FW reset)
Time-Wait Assassination：Client Time-Wait 期間，收到 Server 端遲到的數(shù)據(jù)包，回送Ack給Server，導(dǎo)致Server發(fā)送Rst包。(Server 遲到數(shù)據(jù) -> Client Ack-> Server Reset)
Aborting Connection：客戶(hù)端Abort，內(nèi)核發(fā)送reset給服務(wù)端。(Client Reset)

三、實(shí)現(xiàn)原理

Socket Tracer 使用 eBPF+Tracepoint 捕捉 TCP 的 reset&new&close 等事件，使用 netlink + tcp_diag 周期抓取內(nèi)核 Socket 信息快照。

1.eBPF

背后的思想是：“與其把數(shù)據(jù)包復(fù)制到用戶(hù)空間執(zhí)行用戶(hù)態(tài)程序過(guò)濾，不如把過(guò)濾程序灌進(jìn)內(nèi)核去”。

eBPF 是一個(gè)在內(nèi)核中運(yùn)行的虛擬機(jī)，它可以去運(yùn)行用戶(hù)。在用戶(hù)態(tài)實(shí)現(xiàn)的這種 eBPF 的代碼，在內(nèi)核以本地代碼的形式和速度去執(zhí)行，它可以跟內(nèi)核的 Trace 系統(tǒng)相結(jié)合，給我們提供了幾乎無(wú)限的可觀測(cè)性。

eBPF 的基本原理：它所有的接口都是通過(guò) BPF 系統(tǒng)調(diào)用來(lái)跟內(nèi)核進(jìn)行交互，eBPF 程序通過(guò) LVM 和 Cline 進(jìn)行編譯，產(chǎn)生 eBPF 的字節(jié)碼，通過(guò) BPF 系統(tǒng)調(diào)用，加載到內(nèi)核，驗(yàn)證代碼的安全性，從而通過(guò) JIT 實(shí)時(shí)的轉(zhuǎn)化成 Native 的 X86 的指令。eBPF整體架構(gòu)如下：

2.kprobe

當(dāng)安裝一個(gè)kprobes探測(cè)點(diǎn)時(shí)，kprobe首先備份被探測(cè)的指令，然后使用斷點(diǎn)指令(即在i386和x86_64的int3指令)來(lái)取代被探測(cè)指令的頭一個(gè)或幾個(gè)字節(jié)。

當(dāng)CPU執(zhí)行到探測(cè)點(diǎn)時(shí)，將因運(yùn)行斷點(diǎn)指令而執(zhí)行trap操作，那將導(dǎo)致保存CPU的寄存器，調(diào)用相應(yīng)的trap處理函數(shù)，而trap處理函數(shù)將調(diào)用相應(yīng)的notifier_call_chain（內(nèi)核中一種異步工作機(jī)制）中注冊(cè)的所有notifier函數(shù)，kprobe正是通過(guò)向trap對(duì)應(yīng)的notifier_call_chain注冊(cè)關(guān)聯(lián)到探測(cè)點(diǎn)的處理函數(shù)來(lái)實(shí)現(xiàn)探測(cè)處理的。

當(dāng)kprobe注冊(cè)的notifier被執(zhí)行時(shí)，它首先執(zhí)行關(guān)聯(lián)到探測(cè)點(diǎn)的pre_handler函數(shù)，并把相應(yīng)的kprobe struct和保存的寄存器作為該函數(shù)的參數(shù)，接著，kprobe單步執(zhí)行被探測(cè)指令的備份，最后，kprobe執(zhí)行post_handler。等所有這些運(yùn)行完畢后，緊跟在被探測(cè)指令后的指令流將被正常執(zhí)行。

3.tracepoint

tracepoint和kprobe相比，tracepoint是一個(gè)靜態(tài)的hook函數(shù)，是預(yù)先在內(nèi)核里面編寫(xiě)好才使用。tracepoint實(shí)現(xiàn)是基于hooks的思想，在函數(shù)的入口就被放置一個(gè)probe點(diǎn)，這個(gè)probe點(diǎn)就會(huì)跟蹤調(diào)用這個(gè)函數(shù)的各種信息，并將追蹤的信息保存到一個(gè)環(huán)形隊(duì)列中去，如果用戶(hù)希望讀取這些內(nèi)核，就會(huì)通過(guò)debugfs形式來(lái)訪問(wèn)。

4.方案選型

eBPF 調(diào)用方案

對(duì)比調(diào)用eBPF能力的三種方案，bpftrace / bcc / libbpf，最終選擇bcc：

bpftrace提供了腳本語(yǔ)言，方便輸出內(nèi)核信息到控制臺(tái)，做CLI工具很方便。但沒(méi)有提供API接口，不方便后臺(tái)代碼調(diào)用和信息讀取。
libbpf會(huì)直接把內(nèi)核bpf代碼編譯成bin文件，再放到目標(biāo)機(jī)運(yùn)行。目標(biāo)是一次編譯，四處運(yùn)行，為了解決跨內(nèi)核版本(配置)的可移植問(wèn)題，需依賴(lài)BTF kernel選項(xiàng)，目前絕大部分內(nèi)核默認(rèn)沒(méi)有打開(kāi)該功能，需要修改配置重新編譯kernel才行。
bcc在目標(biāo)機(jī)環(huán)境運(yùn)行階段，動(dòng)態(tài)編譯bpf內(nèi)核代碼，來(lái)解決可移植性問(wèn)題。是現(xiàn)階段使用最廣的方案，絕大部分bpf監(jiān)控工具都基于bcc-tools；并且提供API接口，便于代碼集成，其中內(nèi)核代碼基于C語(yǔ)言，應(yīng)用層代碼提供python和go兩種語(yǔ)言API。

Socket 信息采集方案

eBPF+kprobe在目標(biāo)函數(shù)上動(dòng)態(tài)掛載hook函數(shù)，在高頻調(diào)用（收發(fā)包函數(shù)）的場(chǎng)景額外開(kāi)銷(xiāo)較大，因此在周期統(tǒng)計(jì)socket鏈接收發(fā)數(shù)據(jù)量、重傳次數(shù)等場(chǎng)景，我們參考 ss 的實(shí)現(xiàn)，基于 linux netlink + tcp_diag 內(nèi)核模塊，該方案適合應(yīng)用主動(dòng)抓取某個(gè)時(shí)間點(diǎn)socket 統(tǒng)計(jì)信息快照，可以減少額外性能開(kāi)銷(xiāo)。

5.整體架構(gòu)圖

四、部署和配置方法

1.命令行參數(shù)定義

包含Socket采集過(guò)濾配置文件路徑，socket信息采集周期，vm-insert的URL地址。

bash-5.0# ./socktracer --helpUsage of ./socktracer:  -configfile string      Socket tracer target config file (default "/etc/filter.yaml")  -metricsCacheNum int      Metrics local cached number (default 10000)  -namespace string      Namespace for metrics  -sockScanInterval int      Socket statistical information scan interval (default 30)  -version      Show version information and exit  -vmaddr string      URL of Victoria Metrics write address  -web.listen-address string      Address to listen on for web interface and telemetry. (default ":8080")  -web.metrics-path string      Path under which to expose metrics. (default "/metrics") 

2.Socket采集過(guò)濾配置文件格式

一臺(tái)服務(wù)器上的Socket連接數(shù)量非常多，數(shù)據(jù)量和比較大，我們往往只關(guān)心部分服務(wù)的相關(guān)連接，就像tcpdump我們也往往會(huì)對(duì)IP和端口做過(guò)濾一樣。過(guò)濾配置文件使用yaml格式，定義如下：

filter.yaml配置文件定義，用于配置過(guò)濾需跟蹤的 Socket 鏈接：type SocketID struct {    Protocol  string `yaml:"protocol"`  // Only support TCPv4 currently, will support UDP and IPv6 when needed.    LocalIP   string `yaml:"localIP"`   // Specify local IP, will overwrite LocalPod when both set    LocalPod  string `yaml:"localPod"`  // Specify prefix of local podName, will be overwritten by LocalIP when both set    LocalPort int    `yaml:"localPort"` // Specify local Port, set to 0 means do not filter local port    PeerIP    string `yaml:"peerIP"`    // Specify peer IP, will overwrite PeerPod when both set    PeerPort  int    `yaml:"peerPort"`  // Specify peer Port, set to 0 means do not filter peer port    PeerPod   string `yaml:"peerPod"`   // Specify prefix of peer podName, will be overwritten by PeerIP when both set}樣例：bash-5.0# cat /etc/filter.yamlfilters:  - localIP: ""                //采集目標(biāo)1：不指定本地IP，可以不配置或者設(shè)置為空    localPort: 6379            //指定本地端口，通常選擇固定的server端口作為過(guò)濾條件    localPod: "default/redis-" //指定本地PodName前綴，格式為: namespace/podName前綴  - localPod: "default/iotx-event-center"  // 采集目標(biāo)2：指定本地PodName前綴。peerPod: "default/redis-"  //指定對(duì)端PodName前綴，格式為: namespace/podName前綴    peerPort: 6379             //指定對(duì)端端口 

五、前臺(tái)展示

1.Grafana Dashboard

下圖中，連接到 redis server 的所有TCP連接（來(lái)自不同的Client+Port）都會(huì)被監(jiān)控，展示總并發(fā)連接數(shù)和連接的 rtt(延遲) 等信息：

2.內(nèi)核版本依賴(lài)（>=4.9）

Socket 信息采集依賴(lài) tcp_diag 內(nèi)核模塊。

eBPF 還在快速發(fā)展期，內(nèi)核中的功能也日趨增強(qiáng)，一般推薦基于Linux 4.4+ (4.9 以上會(huì)更好) 內(nèi)核的來(lái)使用 eBPF。部分 Linux Event 和 BPF 版本支持見(jiàn)下圖：