開篇綜述：Socket Tracer定位是傳輸層(Socket&TCP)的指標(biāo)采集工具，通過補(bǔ)齊網(wǎng)絡(luò)監(jiān)控的這部分盲區(qū)，來達(dá)到快速界定網(wǎng)絡(luò)問題的目標(biāo)。

一、背景

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

二、目標(biāo)

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

1.典型場景

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

2.能力綜述

Socket維度信息采集

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

云原生監(jiān)控方案適配

• 現(xiàn)有的netstat、ss等網(wǎng)絡(luò)信息統(tǒng)計工具，無法做到跨network namespce的socket信息統(tǒng)計。在云原生環(huán)境使用不便。需要做到監(jiān)控k8s集群所有節(jié)點(diǎn)，及節(jié)點(diǎn)上所有Pod的Socket狀態(tài)。
• 采集數(shù)據(jù)指標(biāo)化，支持對接 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)采集建議也歡迎留言。下面展開分析下上述指標(biāo)的采集原因：

1)TCP Retransmit

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

2)TCP SRTT

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

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

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

3)TCP Tx/Rx

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

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

4)TCP reset reasons

Reset 包是導(dǎo)致TCP異常斷開的常見原因之一，下面對可能觸發(fā) reset 事件的原因做一個匯總(如有錯漏歡迎補(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)用層沒有及時accept，導(dǎo)致服務(wù)端Accept隊列滿(全鏈接隊列滿)，分兩種情況：對于新來握手請求 SYN -> SYN包會被Server默默丟棄，不會觸發(fā)reset;碰巧在Client 回 ACK(握手第三個包)時，accept 隊列滿了，Server 會根據(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)的場景(NAT網(wǎng)關(guān))，防火墻Session TTL過期。(中間數(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：客戶端Abort，內(nèi)核發(fā)送reset給服務(wù)端。(Client Reset)

三、實現(xiàn)原理

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

1.eBPF

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

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

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

2.kprobe

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

當(dāng)CPU執(zhí)行到探測點(diǎn)時，將因運(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ī)制)中注冊的所有notifier函數(shù)，kprobe正是通過向trap對應(yīng)的notifier_call_chain注冊關(guān)聯(lián)到探測點(diǎn)的處理函數(shù)來實現(xiàn)探測處理的。

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

3.tracepoint

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

4.方案選型

eBPF 調(diào)用方案

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

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

Socket 信息采集方案

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

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

四、部署和配置方法

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

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

bash-5.0# ./socktracer --help 
Usage 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采集過濾配置文件格式

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

filter.yaml配置文件定義，用于配置過濾需跟蹤的 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.yaml 
filters: 
  - localIP: ""                //采集目標(biāo)1：不指定本地IP，可以不配置或者設(shè)置為空 
    localPort: 6379            //指定本地端口，通常選擇固定的server端口作為過濾條件 
    localPod: "default/redis-" //指定本地PodName前綴，格式為: namespace/podName前綴 
  - localPod: "default/iotx-event-center"  // 采集目標(biāo)2：指定本地PodName前綴。peerPod: "default/redis-"  //指定對端PodName前綴，格式為: namespace/podName前綴 
    peerPort: 6379             //指定對端端口 

五、前臺展示

1.Grafana Dashboard

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

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

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

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