Linux sar -n DEV / -n TCP / -n ETCP 的网络指标采集频率与阈值告警

sar -n DEV 的 rxkB/s、txkB/s 是采样周期内的平均速率，非瞬时值；例如 sar -n DEV 1 3 中每行表示前1秒内收发字节数除以1秒的结果，单位为kB（千字节），换算Mbps需×8÷1000。 sar -n DEV 输出的 rxkB/s、txkB/s 是瞬时速率还是平均值？ 是采样周期内的平均值，不是瞬时快照。比如 每秒采一次、共3次，每行的 表示前1秒内网卡实际收到的字节数除以1秒的结果。 单位是 kB（千字节），不是 KiB；换算成带宽常用 Mbps 时，要 ×8÷1000（非÷1024） 如果用 连续跑，第一行其实是从命令启动时刻到第5秒的平均，后续每行才是严格5秒窗口平均 注意：Linux 内核在采样时刻读取的是 /proc/net/dev 的累计计数器，差值再除以时间，所以短周期（如1秒）下受突发流量影响大，容易误判为“持续打满” 为什么 sar -n TCP 的 active/s 和 passive/s 长期为 0？ 这两个指标统计的是「新建立连接」的动作次数，不是连接数本身。如果业务用长连接（如 HTTP/2、gRPC、数据库连接池）， （主动发起连接）和 （被动接受连接）可能极低甚至为0，不代表网络空闲。 对应内核中 tcp_active_opens 计数器，只增在 connect() 成功返回时 对应 tcp_passive_opens，只增在 accept() 返回新 socket 时 常见误判场景：Nginx 反向代理后端用 keepalive，或 Java 应用配了 HikariCP 连接池，此时连接复用率高，新建连接极少 要看当前连接状态，得结合 或 sar -n ETCP 的 RetransSeg 和 AtmptFails 什么情况下真该报警？ 这两个字段反映 TCP 重传行为，但直接设固定阈值（比如 >10 就告警）极易误报。关键看趋势和上下文。 是重传的数据段数量，单次采样值意义不大；应关注 5 分钟滑动窗口内是否持续 >0.5% 的重传率（重传段数 ÷ 总发出段数） 是 connect() 失败次数，常见于对端拒绝（RST）、SYN 超时、防火墙拦截；突然跳升往往比绝对值更有意义 注意干扰项：本地丢包（如网卡 ring buffer 溢出）会抬高 ，但 中对应网卡的 或 也会同步上升 别忘了检查 里的 Tcp: RetransSegs 和 TcpExt: TCPTimeouts，sar 读的就是这里，但原始精度更高 采集频率设多少才不丢关键抖动、又不压垮系统？ 默认 10 秒太粗，1 秒太密——折中推荐 3 秒，但必须配合归档策略，否则 日志体积爆炸。 高频（≤2 秒）采集时， 自身 CPU 占用可能达 1–3%，尤其多网卡+多 CPU 机器上；用 可验证 低于 5 秒的采样，在 sysstat 12.0+ 版本里建议显式加 参数启用毫秒级时间戳，避免多行挤在同一秒内导致聚合失真 真正要捕获微秒级抖动（如 RDMA、DPDK 场景）， 不适用，得切到 或 eBPF 工具 生产环境建议：用 （即每3秒一次、持续6分钟）做巡检快照，而非 24×7 全量记录 实际部署时最容易被忽略的，是 数据的时间基准依赖系统时钟稳定性——NTP 调整或 chrony 跳变会导致采样间隔错乱， 等指标出现负值或尖峰。别只盯着阈值，先确认 里 且 。