連接跟蹤流量統(tǒng)計(jì)這是Linux網(wǎng)絡(luò)運(yùn)維里一個(gè)特別容易被忽視但關(guān)鍵時(shí)刻能救命的角落。很多人搞iptables、搞防火墻規(guī)則精通得很一說到“你線上每秒多少新建連接連接表占用多少到底哪個(gè)IP在持續(xù)往外發(fā)包”就啞火了。原因很簡單連接跟蹤conntrack和流量統(tǒng)計(jì)這兩件事平時(shí)不會(huì)主動(dòng)出現(xiàn)在監(jiān)控面板上等出了事故你才想起去查往往已經(jīng)晚了。這篇東西我把它定位成一篇實(shí)操經(jīng)驗(yàn)匯總。我不打算從頭講netfilter的論文級(jí)原理更多是站在一個(gè)長期跟連接表、計(jì)數(shù)器、NAT規(guī)則打交道的老運(yùn)維視角把連接跟蹤是怎么回事、流量統(tǒng)計(jì)到底有哪幾條路可以走、每一步怎么落地、踩過哪些坑一次說清楚。適合剛接手公司網(wǎng)關(guān)、負(fù)載均衡或者K8s節(jié)點(diǎn)的同行也適合那些被“conntrack表滿了”折磨過的新手。看完你至少能自己搭一套簡單但可靠的流量統(tǒng)計(jì)腳本也能在連接表異常時(shí)快速定位方向。1. 連接跟蹤到底在干什么為什么流量統(tǒng)計(jì)繞不開它1.1 連接跟蹤的本質(zhì)內(nèi)核里的“狀態(tài)記賬本”連接跟蹤全稱connection tracking是Linux內(nèi)核netfilter框架提供的一項(xiàng)基礎(chǔ)能力。它的核心工作是把經(jīng)過主機(jī)的數(shù)據(jù)流抽象成一條“連接”記錄這條連接的五元組信息協(xié)議、源IP、源端口、目的IP、目的端口連同當(dāng)前所處的狀態(tài)NEW新建、ESTABLISHED已建立、RELATED關(guān)聯(lián)連接比如FTP的數(shù)據(jù)通道、INVALID無效。打個(gè)比方你就懂了。連接跟蹤表就像餐廳前臺(tái)的服務(wù)員每一桌客人進(jìn)來他會(huì)記一下桌號(hào)、人數(shù)、點(diǎn)沒點(diǎn)菜、吃到哪個(gè)階段。后面上菜、加單、結(jié)賬全靠這本賬。沒有這個(gè)賬本防火墻的state規(guī)則沒法做——你憑什么判斷這個(gè)包是回應(yīng)之前的請(qǐng)求還是外部主動(dòng)打進(jìn)來的新攻擊NAT也一樣源地址轉(zhuǎn)換后回程的包要能逆轉(zhuǎn)翻譯回去必須查連接跟蹤表里存的映射關(guān)系。所以只要你的機(jī)器做了NAT、開了防火墻并且用了state/ct狀態(tài)匹配、或者跑了Docker、Kubernetes這種重度依賴網(wǎng)絡(luò)策略的容器平臺(tái)連接跟蹤就一定是開啟的。1.2 連接跟蹤表和流量統(tǒng)計(jì)的關(guān)系連接跟蹤表本身不統(tǒng)計(jì)字節(jié)數(shù)。它只管“誰跟誰在通信現(xiàn)在什么狀態(tài)”。但正因?yàn)樗拇嬖趦?nèi)核可以在連接創(chuàng)建、更新、銷毀的各個(gè)生命周期節(jié)點(diǎn)上天然掛鉤各種計(jì)數(shù)邏輯。這就是為什么我們?cè)趇ptables規(guī)則里能看到-c計(jì)數(shù)器在nftables里能定義counter在conntrack工具里能查到bytes和packets字段。換句話說連接跟蹤給了你兩個(gè)維度的數(shù)據(jù)一個(gè)是連接數(shù)橫向規(guī)模一個(gè)是流量字節(jié)縱向體量。這兩個(gè)維度合在一起才能回答運(yùn)維里最常問的“誰在消耗帶寬”“誰在瘋狂發(fā)起連接”“NAT網(wǎng)關(guān)的負(fù)載是否到了瓶頸”。1.3 什么時(shí)候你會(huì)真正需要做流量統(tǒng)計(jì)我遇到過好幾種典型場景逼著你必須認(rèn)真做連接跟蹤流量統(tǒng)計(jì)第一種公司出口NAT設(shè)備領(lǐng)導(dǎo)想搞清楚每個(gè)部門、每個(gè)應(yīng)用占了多大帶寬。這時(shí)候你得按源IP聚合流量光看交換機(jī)的端口流量沒有任何意義。第二種后端服務(wù)突然被大量異常請(qǐng)求打滿但前端所有QPS指標(biāo)都是正常的。查了半天發(fā)現(xiàn)是某個(gè)內(nèi)網(wǎng)服務(wù)在跟外網(wǎng)建立大量短連接連接表被打爆了。這時(shí)候你得看清楚到底哪個(gè)進(jìn)程、哪個(gè)目的IP在制造連接風(fēng)暴。第三種做安全審計(jì)。要回溯某段時(shí)間某個(gè)IP的往來流量連接跟蹤日志是最好的“黑匣子”。這些場景沒有一套順手可用的連接跟蹤流量統(tǒng)計(jì)手段基本就是抓瞎。2. 流量統(tǒng)計(jì)的常見實(shí)現(xiàn)路徑——三選一看你有什么牌2.1 路徑一內(nèi)核計(jì)數(shù)器的被動(dòng)統(tǒng)計(jì)iptables/nftables自帶這是最樸素也最可靠的辦法。iptables的每條規(guī)則自帶兩個(gè)計(jì)數(shù)器packets和bytes。你只需要把統(tǒng)計(jì)用的規(guī)則放在合適位置內(nèi)核會(huì)默默幫你累加數(shù)據(jù)。它的優(yōu)勢在于不需要額外開服務(wù)不占額外CPU數(shù)據(jù)是內(nèi)核精確計(jì)數(shù)的不丟包不采樣。非常適合做“總量統(tǒng)計(jì)”和“按固定維度聚合統(tǒng)計(jì)”比如按源IP段、目的端口、協(xié)議來查流量。但它的短板也很明顯聚合維度不夠靈活。你寫了十條規(guī)則按十個(gè)IP統(tǒng)計(jì)那以后想按“IP和端口組合”查就得加規(guī)則計(jì)數(shù)器是累計(jì)值想要速率必須拉差值后自己算另外iptables計(jì)數(shù)器在規(guī)則被刷新或者機(jī)器重啟后會(huì)清零需要配套的持久化采集方案。2.2 路徑二連接跟蹤日志的被動(dòng)采集基于日志的大數(shù)據(jù)統(tǒng)計(jì)內(nèi)核提供了一個(gè)開關(guān)net.netfilter.nf_conntrack_acct開啟后連接跟蹤會(huì)對(duì)每條連接記錄packets和bytes數(shù)據(jù)。你可以通過conntrack -L命令隨時(shí)查看某條連接已經(jīng)傳了多少字節(jié)、多少個(gè)包。更進(jìn)一步可以用ctnetlink機(jī)制把連接事件新建、更新、銷毀推送到用戶態(tài)通過ulogd2這類工具落日志或者自己寫一段C/Python用netlink庫接收消息。每條連接的字節(jié)數(shù)、包數(shù)都能被記錄到。好處是統(tǒng)計(jì)維度非常自由——你可以存下來做離線分析、按任意字段group by也可以回溯歷史某條連接的流量。代價(jià)是量大的機(jī)器上日志會(huì)產(chǎn)生海量事件磁盤和CPU都有壓力實(shí)時(shí)性弱于計(jì)數(shù)器方案而且如果連接長時(shí)間不斷開字節(jié)數(shù)只累計(jì)不輸出需要按超時(shí)兜底。2.3 路徑三流量采樣與鏡像分析NetFlow/sFlow/pcap旁路這條路嚴(yán)格來說已經(jīng)不算連接跟蹤流量統(tǒng)計(jì)了但實(shí)際運(yùn)維里經(jīng)常拿來補(bǔ)充。思路是把流量旁路出來用采樣協(xié)議sFlow/NetFlow或者全量抓包pcap的方式交給外部分析器比如ELK、SQL數(shù)據(jù)庫做聚合。優(yōu)勢是靈活、不碰生產(chǎn)路徑、能拿到L7應(yīng)用層信息劣勢是需要額外部署硬件交換機(jī)支持sFlow還好純服務(wù)器環(huán)境下還得做分光器或者端口鏡像成本高采樣有概率丟數(shù)據(jù)不適合對(duì)準(zhǔn)確性極其敏感的對(duì)賬場景。2.4 三條路徑的選型對(duì)照維度內(nèi)核計(jì)數(shù)器連接跟蹤日志采樣/鏡像精確度精確精確抽樣有誤差實(shí)時(shí)性秒級(jí)主動(dòng)拉取事件級(jí)推送秒級(jí)系統(tǒng)開銷極低連接量大的主機(jī)有壓力網(wǎng)絡(luò)和存儲(chǔ)壓力高持久化需自己采集天然寫入日志分析端存儲(chǔ)聚合靈活度受限于規(guī)則配置任意維度SQL查詢最靈活含L7適合場景網(wǎng)關(guān)/NAT計(jì)數(shù)器安全審計(jì)、連接級(jí)明細(xì)全鏈路監(jiān)控、協(xié)議分析我個(gè)人的建議是日常監(jiān)控、容量預(yù)警這種以路徑一為主簡單直接需要做安全審計(jì)或查歷史連接時(shí)路徑二配合conntrack工具臨時(shí)看甚至靠journalctl慢慢撈規(guī)模大且有專業(yè)流量分析平臺(tái)的再加路徑三作為補(bǔ)充。3. 實(shí)操環(huán)節(jié)五種最常用的連接跟蹤流量統(tǒng)計(jì)手段3.1 看一臺(tái)機(jī)器當(dāng)前活躍連接數(shù)摸清壓力先別急著寫統(tǒng)計(jì)腳本第一步應(yīng)該是能快速回答“這臺(tái)機(jī)器當(dāng)前同時(shí)在跑多少條連接”。用一行命令# 查看當(dāng)前連接跟蹤總數(shù) cat /proc/sys/net/netfilter/nf_conntrack_count # 查看系統(tǒng)允許的最大連接跟蹤數(shù) cat /proc/sys/net/netfilter/nf_conntrack_max當(dāng)nf_conntrack_count接近nf_conntrack_max的時(shí)候事情就危險(xiǎn)了——新連接會(huì)被內(nèi)核直接丟棄表現(xiàn)為服務(wù)端口telnet不上但ping通業(yè)務(wù)日志里出現(xiàn)“connection reset”且有周期性。這個(gè)數(shù)字應(yīng)該進(jìn)你的監(jiān)控系統(tǒng)告警閾值我一般設(shè)在最大值的80%左右。3.2 iptables計(jì)數(shù)器直接查流量最簡單粗暴假設(shè)你想統(tǒng)計(jì)“訪問本機(jī)8080端口的流量總量”直接加一條規(guī)則iptables -I INPUT 1 -p tcp --dport 8080注意我沒給-j ACCEPT只是把規(guī)則掛在那里純計(jì)數(shù)。因?yàn)镮NPUT鏈默認(rèn)處理完所有規(guī)則會(huì)回到鏈策略只要不顯式跳轉(zhuǎn)計(jì)數(shù)規(guī)則不影響包的去向。這樣加規(guī)則多少有點(diǎn)“臟”更干凈的做法是建一條獨(dú)立的統(tǒng)計(jì)鏈iptables -N TRAFFIC_STAT iptables -A INPUT -j TRAFFIC_STAT iptables -A TRAFFIC_STAT -p tcp --dport 8080隨后想讀取某條規(guī)則累計(jì)的包數(shù)和字節(jié)數(shù)iptables -L TRAFFIC_STAT -v -x-x參數(shù)很關(guān)鍵作用是讓計(jì)數(shù)器輸出精確數(shù)字而不是縮寫成12K、34M這種帶單位的格式方便腳本解析。這個(gè)參數(shù)至少在需要把數(shù)據(jù)丟給監(jiān)控系統(tǒng)的場景里是必須的。3.3 按IP聚合統(tǒng)計(jì)流量拿腳本說話計(jì)數(shù)器方案最實(shí)用的形態(tài)是寫一個(gè)腳本定時(shí)拉取計(jì)數(shù)器計(jì)算差值得到速率。我常用的邏輯如下# 清空指定鏈的計(jì)數(shù)器或重建規(guī)則全部歸零 iptables -Z TRAFFIC_STAT # 確認(rèn)規(guī)則存在后每分鐘執(zhí)行一次 # 先保存上一次的計(jì)數(shù)器讀取當(dāng)前值相減再除以間隔時(shí)間即得字節(jié)速率 prev_bytes$(cat /tmp/traffic_last.txt) curr_bytes$(iptables -L TRAFFIC_STAT -v -x -n | awk -v port8080 $3tcp $4dport {print $2}) echo $curr_bytes /tmp/traffic_last.txt rate_bytes$(( (curr_bytes - prev_bytes) / 60 ))實(shí)際生產(chǎn)環(huán)境里我會(huì)把這個(gè)邏輯編程成一段守護(hù)腳本輸出成timestamp ip bytes bytes_per_sec的格式丟給Prometheus文本文件采集器或者寫進(jìn)InfluxDB。核心思路就是不要指望iptables給你速率它只給累計(jì)增量速率永遠(yuǎn)是自己的時(shí)序系統(tǒng)算出來的。3.4 用conntrack命令查看連接級(jí)明細(xì)深挖單條連接如果你的問題不是“總量多大”而是“哪條連接在跑大流量”那就要進(jìn)連接跟蹤表細(xì)看。工具是conntrack安裝包一般叫conntrack-tools。# 查看當(dāng)前所有連接過濾出字節(jié)數(shù)排序前10 conntrack -L -o extended | awk {print $NF} | sort -rn | head -10conntrack -L輸出長格式時(shí)每條連接末尾會(huì)有bytes... packets...字段。-o extended這個(gè)參數(shù)很關(guān)鍵它額外輸出標(biāo)記、secmark等擴(kuò)展信息也確保字節(jié)數(shù)字段出現(xiàn)在解析里。如果要做每IP聚合conntrack -L -o extended | awk /udp|tcp/ { for(i1;iNF;i) { if($i ~ /^src/) {split($i,a,); srca[2]} if($i ~ /^bytes/) {split($i,b,); bytesb[2]} } total[src]bytes } END {for(ip in total) print total[ip], ip} | sort -rn | head -20這里的坑在于conntrack -L在高連接數(shù)的機(jī)器上本身就是重操作它會(huì)讀全部連接表可能占用CPU幾十毫秒甚至更多。生產(chǎn)環(huán)境大表比如超過十萬條連接我是絕對(duì)不用它做高頻輪詢的——只用于事故現(xiàn)場手動(dòng)排查。3.5 nftables下的統(tǒng)計(jì)實(shí)現(xiàn)——現(xiàn)代服務(wù)器更推薦如果你用的發(fā)行版已經(jīng)全面轉(zhuǎn)向nftables比如新裝的Debian 12、Ubuntu 22.04而且沒有老iptables套件那么統(tǒng)計(jì)寫作nftables規(guī)則要干凈得多。nftables原生支持counter關(guān)鍵字能直接嵌在規(guī)則里nft add table inet traffic_stat nft add chain inet traffic_stat count_in { type filter hook input priority 0; } nft add rule inet traffic_stat count_in tcp dport 8080 counter讀取時(shí)也更方便nft list table inet traffic_stat輸出里直接能看到packets 12345 bytes 6789012。nftables的counter天生支持動(dòng)態(tài)map你可以定義一張“IP地址-計(jì)數(shù)器”的映射表然后一行規(guī)則對(duì)每個(gè)新源IP自動(dòng)建計(jì)數(shù)器nft add table inet traffic_stat nft add set inet traffic_stat per_ip { type ipv4_addr; flags dynamic; } nft add rule inet traffic_stat count_in ip saddr per_ip counter之后每來一個(gè)不同的源IP集合里會(huì)自動(dòng)增加一條記錄并配一個(gè)獨(dú)立的計(jì)數(shù)器。這功能比iptables的“限制規(guī)則條數(shù)”思路靈活太多也是我近兩年主推的方案。4. 深度解析連接跟蹤表為什么會(huì)滿以及它怎么拖垮流量統(tǒng)計(jì)4.1 表滿的連鎖反應(yīng)比想象中嚴(yán)重連接跟蹤表設(shè)計(jì)成固定容量的哈希表默認(rèn)值因發(fā)行版而異常見是65536、131072或者262144。當(dāng)表滿時(shí)內(nèi)核無法為新建連接分配跟蹤條目于是靜默丟包丟棄的位置在netfilter框架的nf_conntrack_in階段后面你再有防火墻、NAT都沒機(jī)會(huì)執(zhí)行。結(jié)果是外部新請(qǐng)求進(jìn)不來但Server端已經(jīng)在跑的ESTABLISHED連接不受影響。這種故障最有迷惑性的特征是“半通”——用戶訪問部分失敗部分成功老連接正常重啟服務(wù)后短暫恢復(fù)又惡化。如果你對(duì)這種場景沒經(jīng)驗(yàn)很容易誤判成應(yīng)用層問題反復(fù)重啟服務(wù)浪費(fèi)時(shí)間。4.2 哪些流量會(huì)大量消耗連接表?xiàng)l目UDP和TCP短連接是大頭。TCP短連接三次握手建一條四次揮手后條目不會(huì)立刻消失默認(rèn)TCP連接的超時(shí)時(shí)間是432000秒5天——你沒看錯(cuò)一條已經(jīng)關(guān)閉的TCP連接conntrack條目最長可以賴在表里5天才被回收。UDP默認(rèn)超時(shí)30秒反而短得多。所以一條TCP連接只要存活超過超時(shí)時(shí)間或者關(guān)閉后沒被立即回收就會(huì)長期占據(jù)一個(gè)表項(xiàng)。高并發(fā)短連接的服務(wù)比如Web API、RPC調(diào)用非常容易把表堆滿。業(yè)界普遍的調(diào)優(yōu)手法是修正超時(shí)參數(shù)# 縮短TCP連接超時(shí)從5天改為1小時(shí) sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established3600 # 短連接場景可以進(jìn)一步改小但要評(píng)估業(yè)務(wù)是否有長連接另外還有兩個(gè)隱藏消耗一是NAT情況下同一個(gè)內(nèi)網(wǎng)IP的大量連接源端口很快耗盡但如果五元組不同conntrack照樣需要獨(dú)立條目二是有很多“半開連接”的場景SYN Flood攻擊會(huì)讓表里充滿SYN_SENT狀態(tài)的殘留條目。4.3 表滿之后的流量統(tǒng)計(jì)直接就廢了這里有個(gè)惡性循環(huán)值得單獨(dú)拉出來說。連接跟蹤表滿后新連接無法被跟蹤意味著你通過conntrack日志做流量統(tǒng)計(jì)的那些路徑天然漏掉了被丟棄的連接流量。表現(xiàn)在你的統(tǒng)計(jì)系統(tǒng)上就是流量數(shù)字突然掉下去了但實(shí)際帶寬占用可能還很高。只看統(tǒng)計(jì)結(jié)果的話你會(huì)誤以為攻擊停了其實(shí)只是連接跟蹤已經(jīng)被打癱了。所以做流量統(tǒng)計(jì)必須聯(lián)動(dòng)監(jiān)控連接跟蹤表的使用率。表的使用率本身才是這臺(tái)機(jī)器網(wǎng)絡(luò)健康度的“體溫計(jì)”。一旦超過80%統(tǒng)計(jì)數(shù)字的可信度就要打折扣得先處理表滿問題再來談流量分析。5. 實(shí)戰(zhàn)案例復(fù)盤一次連接表告警背后的流量統(tǒng)計(jì)排查5.1 現(xiàn)象與初步定位去年我接手一個(gè)內(nèi)網(wǎng)網(wǎng)關(guān)的維護(hù)某天凌晨告警網(wǎng)關(guān)的nf_conntrack_count超過閾值且連續(xù)三次采樣都在攀升。開始時(shí)我沒有著急調(diào)大nf_conntrack_max因?yàn)闄C(jī)器的內(nèi)存并不緊張盲調(diào)大只會(huì)掩蓋問題——如果真是攻擊流量你調(diào)再大也會(huì)被打滿。我的排查順序先看系統(tǒng)連接跟蹤狀態(tài)里的TCP狀態(tài)分布cat /proc/net/nf_conntrack | awk -F {print $4} | sort | uniq -c | sort -rn輸出的狀態(tài)里大量集中在SYN_SENT和TIME_WAIT。SYN_SENT偏多說明可能有對(duì)外異常連接在積壓TIME_WAIT大是正常的但配合連接數(shù)持續(xù)上漲就不是正常的了。5.2 順著連接表挖出元兇接著我用conntrack -L過濾出SYN_SENT狀態(tài)的連接按目的IP聚一下conntrack -L -o extended | grep SYN_SENT | awk -F dst {print $2} | awk {print $1} | sort | uniq -c | sort -rn | head結(jié)果一目了然有一個(gè)外網(wǎng)IP被大量去連而且都是SYN_SENT——對(duì)方根本不回包。netstat -antp確認(rèn)是某個(gè)Java服務(wù)在瘋狂重試外部接口調(diào)用對(duì)方接口有問題重試機(jī)制沒做熔斷很快把連接表堆滿。這個(gè)案例最有價(jià)值的經(jīng)驗(yàn)是先看連接跟蹤的狀態(tài)分布再看異常的遠(yuǎn)端IP最后回到應(yīng)用層的重試邏輯。流量統(tǒng)計(jì)的表象是“連接數(shù)暴漲”但真實(shí)兇手是應(yīng)用層沒有保護(hù)。我當(dāng)時(shí)把服務(wù)的超時(shí)時(shí)間從3秒改成1秒并且加了熔斷連接跟蹤表立刻回到正常水位。5.3 事后補(bǔ)上的流量統(tǒng)計(jì)方案處理完事故后我給網(wǎng)關(guān)加了完整的流量統(tǒng)計(jì)與告警體系/proc/sys/net/netfilter/nf_conntrack_count每30秒采集一次超過nf_conntrack_max的75%發(fā)P2告警90%發(fā)P1。按源IP聚類統(tǒng)計(jì)TCP SYN連接速率每5分鐘計(jì)算一次超過基線十倍以上觸發(fā)告警。iptables統(tǒng)計(jì)鏈按月保留每天早上把前一天的累計(jì)字節(jié)和包數(shù)推到表格存儲(chǔ)供業(yè)務(wù)方按IP查月度用量。這套體系上線之后同樣的問題再次出現(xiàn)時(shí)監(jiān)控能在我還沒被用戶投訴之前就發(fā)出告警。6. 常見問題速查與避坑經(jīng)驗(yàn)6.1 為什么計(jì)數(shù)器統(tǒng)計(jì)的流量和實(shí)際帶寬對(duì)不上這件事最容易引起業(yè)務(wù)方質(zhì)疑。首先要搞清楚iptables計(jì)數(shù)器統(tǒng)計(jì)的是“經(jīng)過這臺(tái)主機(jī)網(wǎng)絡(luò)棧處理的IP層流量”不含以太網(wǎng)幀頭、不含交換機(jī)層面的廣播流量也不含被DPDK這種用戶態(tài)驅(qū)動(dòng)繞過的數(shù)據(jù)包。如果你的機(jī)器上有部分流量走XDP/DPDK旁路了那計(jì)數(shù)器天生就統(tǒng)計(jì)不到。另外本機(jī)回環(huán)流量lo口算不算你的業(yè)務(wù)流量取決于你規(guī)則鏈掛的位置。我做統(tǒng)計(jì)時(shí)通常會(huì)把lo接口排除在外避免重復(fù)計(jì)數(shù)。6.2 conntrack日志丟失統(tǒng)計(jì)出現(xiàn)空洞用conntrack日志方案時(shí)事件通過netlink socket傳遞給用戶態(tài)如果用戶態(tài)程序處理不過來內(nèi)核socket緩沖區(qū)滿了就會(huì)丟棄消息。這種丟棄是靜默的日志里看不出異常只會(huì)表現(xiàn)為某段時(shí)間的連接事件缺失。解決思路一是加大接收緩沖區(qū)net.core.rmem_default二是做降級(jí)——如果事件吞吐量過大就不追求逐條記錄改為周期性全量快照的增量式統(tǒng)計(jì)犧牲實(shí)時(shí)性換完整性三是把連接表Dump快照定期落盤比如每5分鐘把/proc/net/nf_conntrack導(dǎo)出壓縮存一份事故后直接翻歷史快照就行。6.3 計(jì)數(shù)器反向增長數(shù)據(jù)出現(xiàn)氣泡我踩過一次很典型的坑。寫統(tǒng)計(jì)腳本時(shí)拿iptables計(jì)數(shù)器差值計(jì)算速率結(jié)果符號(hào)寫反了還是其次問題是計(jì)數(shù)器在某個(gè)時(shí)間點(diǎn)突然跳變到超大值。查原因發(fā)現(xiàn)是有人手動(dòng)清空了規(guī)則重新加載后計(jì)數(shù)器歸零然后腳本認(rèn)為是“反向回繞”算出來的速率變成了天量數(shù)字。這個(gè)問題的魯棒解法是腳本里判定如果當(dāng)前計(jì)數(shù)比上次小就丟棄這一輪差值一律輸出0而不是輸出負(fù)數(shù)。同時(shí)規(guī)則文件的變更操作要規(guī)范走自動(dòng)化發(fā)布避免人工干預(yù)計(jì)數(shù)器。6.4 如何應(yīng)對(duì)Kubernetes節(jié)點(diǎn)上的連接跟蹤統(tǒng)計(jì)盲區(qū)Kubernetes節(jié)點(diǎn)上Kube-proxy的iptables或IPVS模式大量依賴連接跟蹤。特別是IPVS模式它本身有更多連接條目因?yàn)槊總€(gè)Service的每個(gè)后端組合都會(huì)占據(jù)獨(dú)立的連接跟蹤項(xiàng)。流量統(tǒng)計(jì)的難點(diǎn)在于Service的ClusterIP只是虛擬IP你按源IP分類能聚合按目標(biāo)Service歸類就有難度了。我的建議是K8s場景下連接跟蹤統(tǒng)計(jì)盡量按Pod所在節(jié)點(diǎn)和網(wǎng)段聚合配合Service Mesh的sidecar流量指標(biāo)綜合判斷。純靠conntrack做細(xì)粒度業(yè)務(wù)流量拆解不僅效率低而且容易誤判。7. 終點(diǎn)之前留幾句實(shí)用閑話最后說點(diǎn)不寫在教科書里的感受。連接跟蹤流量統(tǒng)計(jì)這個(gè)技術(shù)點(diǎn)不像高并發(fā)框架那樣能帶來炫酷的架構(gòu)升級(jí)也出不了什么精彩的PPT但在真實(shí)的生產(chǎn)環(huán)境里它就是我這種人賴以為生的“底層能力”。說實(shí)話我自己最初踩的坑很多都不是技術(shù)難題而是沒把“連接跟蹤表也是要監(jiān)控的”這件事當(dāng)回事。給主機(jī)加內(nèi)存、加CPU、加帶寬都不如提前把nf_conntrack_count盯牢來得實(shí)在。還有一個(gè)心得是統(tǒng)計(jì)不是為了做日?qǐng)?bào)而是為了發(fā)現(xiàn)“異常”。一個(gè)穩(wěn)定運(yùn)行的系統(tǒng)連接數(shù)、字節(jié)數(shù)、包數(shù)在時(shí)間軸上應(yīng)該是平滑的。任何突兀的抖動(dòng)都值得你去連接跟蹤表里翻一翻。與其研究更花哨的流量分析平臺(tái)不如先把自己的計(jì)數(shù)器腳本和告警閾值搞好。如果你現(xiàn)在手頭正好管著幾臺(tái)NAT網(wǎng)關(guān)或K8s節(jié)點(diǎn)建議今天就跑一遍cat /proc/net/nf_conntrack | wc -l cat /proc/sys/net/netfilter/nf_conntrack_max先把這兩個(gè)數(shù)記下來再順手看一眼你的監(jiān)控系統(tǒng)里有沒有這兩個(gè)指標(biāo)。沒有的話補(bǔ)上它們比任何花架子優(yōu)化都實(shí)在。