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