建站
咨詢
售后
建站咨詢
新聞中心
開篇綜述：Socket Tracer定位是傳輸層(Socket&TCP)的指標采集工具，通過補齊網(wǎng)絡(luò)監(jiān)控的這部分盲區(qū)，來達到快速界定網(wǎng)絡(luò)問題的目標。
一、背景
隨著軟件應(yīng)用的集群化、容器化、微服務(wù)化，產(chǎn)品的穩(wěn)定性越來越依賴網(wǎng)絡(luò)?，F(xiàn)有的專有云和一體機產(chǎn)品，部署在裸機，從硬件服務(wù)器、交換機到os都是不可靠的，且監(jiān)控盲區(qū)較多，其中網(wǎng)絡(luò)是重災(zāi)區(qū)。對于網(wǎng)絡(luò)不穩(wěn)定導(dǎo)致的中間件鏈接超時、設(shè)備掉線、視頻推流卡頓等問題，缺乏有效的網(wǎng)絡(luò)層監(jiān)控指標定界問題。一旦現(xiàn)場不存在，由網(wǎng)絡(luò)引發(fā)的問題很難定位?，F(xiàn)有的網(wǎng)絡(luò)監(jiān)控方案，都集中在網(wǎng)卡維度做流量、錯包等指標統(tǒng)計，粒度過粗，只有從Socket和TCP連接維度，監(jiān)控socket緩存狀態(tài)，采集TCP建連、斷開、實時流量、延遲、重傳等信息，才可以最直接的反映業(yè)務(wù)的網(wǎng)絡(luò)狀態(tài)。
二、目標
現(xiàn)有的網(wǎng)絡(luò)監(jiān)控工具如 ss、netstat 等，可以顯示服務(wù)器當前 Socket 狀態(tài)快照，在問題現(xiàn)場可以有效的輔助我們排查問題。當現(xiàn)場不存在，我們希望能有工具能保存歷史網(wǎng)絡(luò)狀態(tài)。然而單純記錄歷史 Socket 五元組信息，在復(fù)雜拓撲場景是不夠的，因為IP很可能是動態(tài)的，還須將當前時刻的 Socket 連接和業(yè)務(wù)屬性(Pod Name、設(shè)備身份...)關(guān)聯(lián)，才能達到還原問題現(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é)點，及節(jié)點上所有Pod的Socket狀態(tài)。
- 采集數(shù)據(jù)指標化，支持對接 Prometheus 的 Exporter 接口。
- 支持指標推送到 VictoriaMetrics。
指標選取原理
TCP的指標有很多，為什么采集上述的指標信息，出發(fā)點是希望找到可以反映應(yīng)用程序狀態(tài)和網(wǎng)絡(luò)連通狀態(tài)指標，如果有其它指標采集建議也歡迎留言。下面展開分析下上述指標的采集原因：
1)TCP Retransmit
包重傳的超時時間是RTO，通常是200ms左右，當我們觀察到一段時間出現(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ù)鏈路上)到收到確認信號的時間。
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 事件的原因做一個匯總(如有錯漏歡迎補充)：
- 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：在防火墻維護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)程序過濾，不如把過濾程序灌進內(nèi)核去”。
eBPF 是一個在內(nèi)核中運行的虛擬機，它可以去運行用戶。在用戶態(tài)實現(xiàn)的這種 eBPF 的代碼，在內(nèi)核以本地代碼的形式和速度去執(zhí)行，它可以跟內(nèi)核的 Trace 系統(tǒng)相結(jié)合，給我們提供了幾乎無限的可觀測性。
eBPF 的基本原理：它所有的接口都是通過 BPF 系統(tǒng)調(diào)用來跟內(nèi)核進行交互，eBPF 程序通過 LVM 和 Cline 進行編譯，產(chǎn)生 eBPF 的字節(jié)碼，通過 BPF 系統(tǒng)調(diào)用，加載到內(nèi)核，驗證代碼的安全性，從而通過 JIT 實時的轉(zhuǎn)化成 Native 的 X86 的指令。eBPF整體架構(gòu)如下：
2.kprobe
當安裝一個kprobes探測點時，kprobe首先備份被探測的指令，然后使用斷點指令(即在i386和x86_64的int3指令)來取代被探測指令的頭一個或幾個字節(jié)。
當CPU執(zhí)行到探測點時，將因運行斷點指令而執(zhí)行trap操作，那將導(dǎo)致保存CPU的寄存器，調(diào)用相應(yīng)的trap處理函數(shù)，而trap處理函數(shù)將調(diào)用相應(yīng)的notifier_call_chain(內(nèi)核中一種異步工作機制)中注冊的所有notifier函數(shù)，kprobe正是通過向trap對應(yīng)的notifier_call_chain注冊關(guān)聯(lián)到探測點的處理函數(shù)來實現(xiàn)探測處理的。
當kprobe注冊的notifier被執(zhí)行時，它首先執(zhí)行關(guān)聯(lián)到探測點的pre_handler函數(shù)，并把相應(yīng)的kprobe struct和保存的寄存器作為該函數(shù)的參數(shù)，接著，kprobe單步執(zhí)行被探測指令的備份，最后，kprobe執(zhí)行post_handler。等所有這些運行完畢后，緊跟在被探測指令后的指令流將被正常執(zhí)行。
3.tracepoint
tracepoint和kprobe相比，tracepoint是一個靜態(tài)的hook函數(shù)，是預(yù)先在內(nèi)核里面編寫好才使用。tracepoint實現(xiàn)是基于hooks的思想，在函數(shù)的入口就被放置一個probe點，這個probe點就會跟蹤調(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文件，再放到目標機運行。目標是一次編譯，四處運行，為了解決跨內(nèi)核版本(配置)的可移植問題，需依賴BTF kernel選項，目前絕大部分內(nèi)核默認沒有打開該功能，需要修改配置重新編譯kernel才行。
- bcc在目標機環(huá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在目標函數(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)用主動抓取某個時間點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: "" //采集目標1：不指定本地IP，可以不配置或者設(shè)置為空
- localPort: 6379 //指定本地端口，通常選擇固定的server端口作為過濾條件
- localPod: "default/redis-" //指定本地PodName前綴，格式為: namespace/podName前綴
- - localPod: "default/iotx-event-center" // 采集目標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)核中的功能也日趨增強，一般推薦基于Linux 4.4+ (4.9 以上會更好) 內(nèi)核的來使用 eBPF。部分 Linux Event 和 BPF 版本支持見下圖：
當前文章：快速界定故障：SocketTracer網(wǎng)絡(luò)監(jiān)控實踐
文章位置：http://www.5511xx.com/article/cdjgooc.html
