验证接入

分别验证进程、采集覆盖、业务解析和事件确认。每一步成功都有自己的范围，不能用 /healthz 代替整条链路验收。

1. 配置与覆盖就绪

sudo netflowscout onboard --config /etc/netflowscout/netflowscout.json \
  --endpoint-dir /etc/netflowscout/endpoints --timeout 30s

检查主服务、分析器和所选端点的配置、心跳、接线、程序身份、挂载数量及重叠目标。默认 scope 是 readiness_only，没有发送合成流。零匹配表示等待目标，不表示观察到业务。

可重复轮询 status --component all --require-ready，或打开TUI。仅选择与本管线对应的端点文件；检查范围不包括未声明应用或其他节点。

2. 模拟管线

先启用主配置 verification.enabled=true，重启主服务及分析器，然后执行：

sudo netflowscout verify --config /etc/netflowscout/netflowscout.json \
  --canary --timeout 30s

合成流经过私有 socket、实际 Wasm、规则、脱敏、WAL 和所有启用输出端。capture 始终是 not_verified，因为没有经过网卡或 TLS 探针。该结果适合定位解析后半段故障。

3. 真实业务与输出确认

sudo netflowscout verify --config /etc/netflowscout/netflowscout.json \
  --service billing --expect-type http.transaction \
  --expect-event http.slow \
  --endpoint-config /etc/netflowscout/endpoints/billing.json --timeout 60s

命令启动后，从另一终端产生一条确实会命中 http.slow 的新请求。事件名须与实际已加载规则一致。工具不会主动访问业务。

完整、非截断、非迟到、经过同类型规则评估的新记录才通过；指定 --expect-event 还要求对应事件和每个输出端独立确认。省略事件要求时，delivery 为 not_verified。

解释结果

结果	如何处理
attached 但无业务	确认命令后有新请求、协议/角色和来源配置正确
业务通过，delivery 未验证	添加实际可触发的 --expect-event
队列为空但 unconfirmed	确认凭据、接收端和确认留存；不根据空队列猜测送达
Dataway ACK 成功	仍需在目标平台查询同一 event_id 证明可检索

本地 WAL 保存最近 8192 条 sink 确认；过期会显示 unconfirmed。模拟验证、loopback 测试和真实网卡验收不能互相替代。