一、 为什么“看见”网络如此之难？

在传统运维中，我们常犯两个错误：

1. 只看机器，不看连接：CPU、内存正常，但应用就是慢。因为网络拥塞了，或者TCP重传率高了。

2. 只有宏观，没有微观：只知道网卡流量跑满了，但不知道是哪个进程、哪个IP、甚至哪个URL把带宽吃光了。

企业级网络监控的目标，不仅仅是画几张漂亮的流量图，而是要能回答以下问题：

• 现在的带宽占用里，TCP和UDP各占多少？

• 是否存在大量的TCP重传？（这通常意味着网络质量差或网卡丢包）

• 是哪台服务器的哪个进程正在疯狂发包？

• 有没有异常端口在对外通信？（安全审计）

二、 基础监控：SNMP与网卡流量的“前世今生”

虽然SNMP（简单网络管理协议）有些古老，但在企业内网环境中，它依然是获取交换机和Linux网卡流量数据的标准方式。

1. 部署 Node Exporter（现代做法）

如果你是新建系统，强烈建议放弃 Cacti/Nagios 那一套复杂的SNMP配置，直接使用Prometheus + Node Exporter。

Node Exporter 会采集Linux内核暴露的所有指标，其中网络相关的指标极其丰富。

关键指标解读（面试和排错常考）：

• node_network_carrier: 网卡物理连接状态（1为连接，0为断开）。

• node_network_receive_bytes_total/node_network_transmit_bytes_total: 总收发字节数（用于计算速率）。

• node_network_receive_errs_total/node_network_transmit_errs_total:接收/发送错误包计数。如果这个数值持续增长，说明网卡、网线或交换机端口可能硬件故障。

• node_network_tcp_segments_retransmitted:TCP重传段数。这是衡量网络质量的核心指标，比Ping丢包更准确。

2. 避坑指南：监控网卡的“双工模式”

很多时候网络慢，不是带宽问题，而是网卡协商成了半双工（Half-Duplex）或者百兆模式。

在Linux中检查：

ethtool eth0 | grep -E "Speed|Duplex"

企业规范：在Zabbix或Prometheus中，不仅要监控流量百分比，还要监控Speed是否为1000Mb/s，Duplex是否为Full。一旦降级，立即告警。

三、 进阶监控：用 eBPF 透视“内核里的网络”

这是近几年Linux网络监控最重大的变革。传统工具（如netstat,top）很难告诉你“数据包在内核里排队了多久”或者“某个TCP连接的延迟是多少”。

1. 什么是 eBPF？（通俗版）

想象一下，Linux内核是一个黑盒。以前我们要么在盒子外面抓包（tcpdump），要么看盒子输出的结果（ss）。eBPF允许我们在内核的特定路径上挂一个“探针”，实时统计经过这个路径的数据包信息，而且性能损耗极低。

2. 实战利器：BCC 与 bpftrace

不需要自己写eBPF代码，我们可以直接用封装好的工具集 BCC（BPF Compiler Collection）。

场景一：排查网络延迟

使用tcplatency工具查看所有TCP连接的RTT（往返时延）：

/usr/share/bcc/tools/tcplatency -D 10 # 统计10秒内的TCP延迟分布

如果看到延迟分布普遍偏高，而应用服务器负载很低，问题大概率出在网络链路上（防火墙、交换机、跨地域专线）。

场景二：排查丢包

使用dropwatch或skb_drop查看内核在哪里丢包了。

/usr/share/bcc/tools/dropwatch -K

这对于解决“内核缓冲区满导致的丢包”问题有奇效。

注意：eBPF需要较新的内核（推荐 >= 4.14，最好是 5.x+）。如果是CentOS 7（内核3.10），可能需要升级内核或使用特定的补丁包。

四、 流量分析：谁是内网的“流量怪兽”？

当带宽报警响起，我们需要快速定位罪魁祸首。这时候，iftop和nethogs是你的左膀右臂。

1. 实时流量定位：nethogs

不同于iftop按IP统计，nethogs是按进程统计的。这在多应用混部的服务器上非常重要。

nethogs eth0

它会直接显示 PID、用户、进程名以及实时的上传下载速率。

实战技巧：如果发现是java进程占用过高，结合jstack或 Arthas 进一步定位具体线程；如果是nginx，查看访问日志。

2. 连接数监控：被忽视的“隐形炸弹”

很多时候，网卡流量没满，但服务器却无法响应新请求。这通常是TCP连接数​ 被打满了。

监控关键文件：/proc/net/sockstat

cat /proc/net/sockstat

关注几个指标：

• TCP: inuse: 正在使用的TCP套接字数。

• TCP: orphan: 无主（不属于任何文件描述符）的TCP连接数（通常是TIME-WAIT堆积）。

• TCP: timewait: TIME-WAIT 状态的连接数。

企业级告警阈值：

• 当orphan接近net.ipv4.tcp_max_orphans时，必须告警。

• 当单台机器的 TCP 连接数超过 65535 的 70% 时，需要关注。

五、 可视化：打造你的网络监控仪表盘

数据是零散的，图表才是用来决策的。我们使用Grafana​ 来展示 Prometheus 采集的数据。

1. 必建的四个面板（Panel）

在你的 Grafana Dashboard 中，至少应该包含以下四个视图：

1. 流量吞吐量 (Throughput)：

   • 指标：rate(node_network_receive_bytes_total[5m])

   • 展示：按服务器分组的流量曲线。

   • 作用：发现流量突增或突降。

2. TCP 重传率 (Retransmission Rate)：

   • 指标：rate(node_network_tcp_segments_retransmitted[5m]) / rate(node_network_tcp_segments_total[5m])

   • 展示：百分比曲线。

   • 作用：判断网络质量的黄金指标。正常情况下应低于 0.1%。如果飙升，说明网络拥堵或硬件故障。

3. Socket 状态分布 (Socket States)：

   • 指标：node_netstat_Tcp_CurrEstab(当前建立连接),node_sockstat_TCP_tw(TIME_WAIT)

   • 展示：Stacked Bar（堆叠柱状图）。

   • 作用：观察连接池是否健康，是否有大量等待释放的连接。

4. DNS 查询耗时 (DNS Latency)：

   • 指标：如果使用dnsmasq或 CoreDNS，采集其 Query Time。

   • 作用：很多应用慢是因为DNS解析慢，而不是网络传输慢。

2. 告警策略

不要等网卡打满了才告警。建议设置多级告警：

• Warning: 流量达到带宽上限的 70%，或 TCP 重传率 > 0.5%。

• Critical: 流量达到带宽上限的 90%，或 TCP 重传率 > 1%，或出现Send-Q持续堆积。

六、 安全视角：网络监控也是安全哨兵

网络监控数据往往是入侵检测的第一信号。

1. 异常端口监控

编写一个简单的脚本，配合ss -tulnp，定期检查是否有非白名单的端口处于 LISTEN 状态。

# 白名单端口 ALLOWED_PORTS=(22 80 443 3306) # 当前监听端口 CURRENT_PORTS=$(ss -tuln | awk 'NR>1 {print $5}' | cut -d: -f2 | sort -u) # 对比逻辑...

一旦发现6666、4444或其他可疑端口，立即触发高危告警。

2. 异常外联监控

监控服务器的出口流量。如果一台Web服务器突然开始向公网的25端口（邮件）或大量的随机高位端口发包，极有可能它被植入了木马，正在扫描外网或发送垃圾邮件。

七、 总结：从“看热闹”到“看门道”

网络监控不是为了画几张花哨的图，而是为了量化系统的不确定性。

回顾一下今天的要点：

1. 基础要稳：用好 Prometheus + Node Exporter，重点关注TCP重传率​ 和错误包。

2. 内核要透：学会使用 eBPF/BCC 工具（如tcplatency），透视内核网络栈的性能瓶颈。

3. 定位要快：掌握nethogs和ss，在故障发生时秒级定位进程和连接。

4. 视图要全：Grafana 仪表盘要包含流量、重传、连接数和安全审计四个维度。

当你能从一堆监控数据中，一眼看出是交换机的光模块衰减导致TCP重传，还是Java程序的HTTP连接池泄漏导致Socket耗尽时，你就真正拥有了企业级Linux网络管理的“上帝视角”。