nftables reset counters 怎样做规则变更前后对比

nftables 官方语法把 reset 设计成“列出并重置”有状态对象。针对 named counter，可以按三个范围选择命令：

# 只重置一个 named counter，适合单条规则或单个业务入口
nft reset counter inet edge_filter web_ingress

# 重置一张表里的所有 named counters，适合一次观察一组规则
nft reset counters table inet edge_filter

# 重置当前规则集可见范围内的 counters，影响最大，谨慎使用
nft reset counters

第一个命令最适合规则变更前后的单点对比；第二个命令适合把一张表视为一个统计窗口；第三个命令会扩大影响面，必须在记录中写清原因。reset 返回的内容可以作为“重置前最后一份快照”，因此不要把它的输出丢掉。

这里的关键是范围，而不是命令长短：单个 counter 的 reset 不会清空规则，表级 reset 也不改变表内的 chain、set 或 rule。它们改变的是计数状态。

规则变更后用同一个窗口比较命中增量

完成 reset 后再做规则变更，并等待一个预先约定的观察窗口。变更后不要拿历史日志里的累计值直接与当前值比较，而是重新读取同一批 named counters：

# 读取变更后的同一张表，保持 family、table 与基线一致
nft list counters table inet edge_filter

# 也可以连同规则一起查看，确认 counter 仍挂在预期规则上
nft list table inet edge_filter

比较时使用简单的增量：

# 变更后值减去变更前值，得到本次观察窗口的命中增量
delta_packets = after_packets - before_packets
delta_bytes = after_bytes - before_bytes

上面的片段是伪代码，变量名只表达计算关系。实际记录可以按下面的逻辑解释：

• delta_packets = 0 且 delta_bytes = 0：观察窗口内没有命中，或流量没有经过这条规则。
• delta_packets > 0：规则至少匹配到了流量，接下来结合 chain 顺序和 verdict 判断最终动作。
• delta_bytes 增长明显但包数少：可能是少量大包或上传流量，不能只按请求数判断影响。

下面的第二张图把“基线、重置后的零点、同窗口结果”与规则对象分开表示，帮助区分统计口径和规则结构；它同样是静态说明图，不代表某台机器的实际输出。

匿名 counter 为什么不能按同样方式管理

匿名 counter 绑定在单条规则内部，没有可供命令直接定位的稳定名称。nftables 官方 Counters 说明中也指出，reset named counters 不会重置匿名 counters。不要因为看到规则里有 counter 就默认 nft reset counter ... 能找到它。

如果业务确实需要可重复的变更前后对比，应把关键观察点改为 named counter，并在规则评审中固定命名。为了清空匿名计数器而重载整套无状态规则可能产生更大副作用，例如其它有状态信息也会被丢弃；这不应当作为普通变更的默认动作。

一份可复用的变更记录模板

可以把下面的内容放进变更单，重点是让下一位值班同事知道 reset 的范围和比较窗口：

# 记录这次观察的对象、窗口和变更目标
对象：inet edge_filter / web_ingress
变更前基线：packets=12480，bytes=9823410
重置范围：仅 named counter web_ingress
观察窗口：规则变更完成后 10 分钟
变更后读取：记录 after_packets 与 after_bytes
比较方式：after - before（以 reset 后零点为本次窗口起点）
回退依据：若命中增量异常，恢复原规则并保留本次快照

如果已经执行了 reset，最直接的补救不是再次 reset，而是保留当前读数、写清新的窗口起点，并在后续比较中只使用这一次 reset 之后的数据。

常见问题

reset counters 会删除 nftables 规则吗？

不会。它重置的是 counter 的状态值，不会删除 table、chain 或 rule。

应该使用 table 级 reset 还是单个 counter？

只观察一条规则时用单个 counter；需要把一张表作为整体统计窗口时用 table 级 reset。范围越大，越要提前记录影响对象。

为什么 reset 后看不到匿名 counter 归零？

匿名 counter 没有稳定名称，named counter 的 reset 不负责清理它。要获得可管理的窗口，优先改用 named counter。

比较 packets 还是 bytes？

请求数量优先看 packets，流量规模优先看 bytes。排障时同时记录两者，避免少量大包造成误判。

小结：用 named counter 固定观察对象，先记录基线，再选择最小必要范围执行 reset，规则变更后用相同窗口读取 packets 和 bytes。这样得到的是可解释的命中增量，而不是被历史累计值污染的模糊判断。