feat: parse NetSign protocol

[lzf575]

This PR is for:

[lzf575]

@claude review 下这个pr，使用中文

[claude]

Claude finished @lzf575's task in 29m 36s —— View job

---

已完成 review。结论：当前实现里有 3 个确定性比较高的问题，建议修完再合并。

• 阅读核心改动
• 核对协议号 / parser 注册 / server 映射 / eBPF inference
• 输出 review 结论

1. session_id=None 却开启 session aggregation，cBPF 下会把整条 flow 上的 NetSign 会话混成一个 key

@agent/src/flow_generator/protocol_logs/rpc/net_sign.rs:205-210 里 session_id() 返回 None，但 needs_session_aggregation() 返回 true。
而 @agent/src/flow_generator/protocol_logs/parser.rs:217-223、@agent/src/flow_generator/protocol_logs/parser.rs:268-277 表明：非 eBPF 路径的 session key 会退化成 flow_id | 0。
接着在 @agent/src/flow_generator/protocol_logs/parser.rs:463-528，同一个 key 上的新 request/response 会直接走 merge / send / replace 逻辑。

这意味着，只要同一条 TCP 连接上存在多个未完成的 NetSign 请求/响应对，就会共用一个聚合 key，可能出现错配、提前发送或覆盖。
对照已有企业协议，@agent/src/flow_generator/protocol_logs/rpc/iso8583.rs:118-125 和 @agent/src/flow_generator/protocol_logs/mq/web_sphere_mq.rs:72-79 在 session_id=None 时都关闭了 session aggregation。

建议二选一：

1. 如果 NetSign 没有稳定的 request/response 关联键，就把 needs_session_aggregation() 改成 false；
2. 如果协议里能提取出关联字段，就补一个真实 session_id()。

2. eBPF 用户态外围接入没有补齐，调试/展示链路对 NetSign 仍不完整

内核侧协议号和 inference 已经接进去了，但用户态还有几个漏点：

• @agent/src/ebpf/mod.rs:68-72 里没有 SOCK_DATA_NET_SIGN = 50
• @agent/src/ebpf/user/socket.h:296-299 里有 PROTO_SOME_IP / PROTO_ISO8583，但没有 PROTO_NET_SIGN 的名字映射
• @agent/src/ebpf/user/ctrl_tracer.c:148-166 的 datadump help 里也没有 50: PROTO_NET_SIGN

这会让新协议在用户态常量、名称展示和调试帮助上不一致，后续排障时比较难发现。建议把这几处一起补齐。

3. 默认配置没有纳入 NetSign，端口预过滤会退化成“全端口尝试”

@agent/src/config/config.rs:2037-2099 的默认 port_number_prefilters 和 tag_filters 都没有 NetSign。
而 @agent/src/flow_generator/perf/mod.rs:162-170、@agent/src/flow_generator/perf/mod.rs:203-206 表明：如果某个协议没有对应 bitmap，checker 会把它当成“无端口限制”，直接参与协议尝试。

也就是说，NetSign 一旦被启用，默认配置下会在 cBPF 路径上对所有 TCP 端口都尝试解析。这和其它企业协议的接入方式不一致，也会增加误判/额外开销。
建议至少补上默认 port_number_prefilters；tag_filters 也最好一起补齐，不然 blacklist / 文档暴露面也不完整。

补充说明：当前仓库里 @agent/crates/enterprise-utils/src/lib.rs 的 NetSign parser 仍是 OSS stub（check_payload() / parse_payload() 是 unimplemented!()），所以这次 review 主要覆盖的是接入层、聚合逻辑和外围注册完整性，真实报文字段解析正确性这里没法继续往下验证。

除上述问题外，协议号枚举、server 侧 flow.go 映射以及 kernel inference 主链路看起来是补齐的。

[lzf575]

@claude review这个pr，使用中文

[claude]

Claude finished @lzf575's task in 29m 3s —— View job

---

- 这是对 #11567 的中文 review。 - 我重新核对了 NetSign parser 接入、session 聚合、状态映射，以及前一轮提到的外围补点。 - 结果：前一轮提到的 eBPF 用户态补点和默认配置补点已经修复；当前还剩 1 个确定性问题，另有 1 个建议关注点。

Review 结论

这轮复核后，前一轮提到的下面两项已经补齐：

• eBPF 用户态常量 / 名称映射 / datadump help：@agent/src/ebpf/mod.rs:74、@agent/src/ebpf/user/socket.h:300-301、@agent/src/ebpf/user/ctrl_tracer.c:151
• 默认 prefilter / tag filter 及文档同步：@agent/src/config/config.rs:2047、@agent/src/config/config.rs:2080、@server/agent_config/template.yaml:6121、@server/agent_config/template.yaml:6285

我这边还看到 1 个建议修复后再合并的问题：

1. session_id=None 但仍开启 session aggregation，cBPF 下会把同一条 flow 上的多组 NetSign 请求/响应共用一个聚合 key

• @agent/src/flow_generator/protocol_logs/rpc/net_sign.rs:223-228 里 session_id() 返回 None，但 needs_session_aggregation() 返回 true。
• @agent/src/flow_generator/protocol_logs/parser.rs:217-223、@agent/src/flow_generator/protocol_logs/parser.rs:268-278 表明：非 eBPF 路径下，没有 session_id 时 key 会退化成 flow_id | 0。
• 后面的聚合逻辑会直接按这个 key 走 merge / send / replace：@agent/src/flow_generator/protocol_logs/parser.rs:433-444、@agent/src/flow_generator/protocol_logs/parser.rs:463-533。

这意味着如果同一条 TCP 连接里出现多组尚未完成的 NetSign 请求/响应，它们会落到同一个聚合槽里，可能出现错配、提前发送或覆盖。对照已有企业协议，@agent/src/flow_generator/protocol_logs/rpc/iso8583.rs:117-125 在 session_id=None 时直接关闭了 session aggregation。

建议二选一：

1. 如果协议里没有稳定的 request/response 关联键，把 needs_session_aggregation() 改成 false；
2. 如果能从报文里提取稳定关联字段，就补一个真实的 session_id()。

Fix this →

额外建议关注

• @agent/src/flow_generator/protocol_logs/rpc/net_sign.rs:389-397 里，响应 result_code 只把 "1" / "11" 映射成 Ok，其它返回码全部落到 L7ResponseStatus::Unknown。
• 但通用 perf 统计只会把 ClientError / ServerError 记入错误计数：@agent/src/common/l7_protocol_log.rs:381-385。
• 这意味着如果 NetSign 的其它 result_code 确实代表失败，当前实现不会进入 error 指标，只会保留 biz_response_code / exception。

如果协议语义里这些 code 就是失败，建议把它们映射到明确的错误状态，而不是 Unknown。

Fix this →

补充说明

• 当前 OSS snapshot 里的 NetSignParser 仍是 stub：@agent/crates/enterprise-utils/src/lib.rs:394-401，所以这次 review 主要覆盖接入层和聚合/状态逻辑；没有继续验证 enterprise parser 的真实字段解析实现。
• server / querier 侧枚举映射看起来是补齐的：@server/libs/datatype/flow.go:163、@server/libs/datatype/flow.go:702-706、@server/querier/db_descriptions/clickhouse/tag/enum/l7_protocol:14

Checklist

• 更新 GitHub 评论中的进行中 checklist
• 审阅 PR diff 并阅读相关文件
• 用中文整理 review 结论并更新评论

[lzf575]

@claude review 下代码，使用中文说明

[claude]

Claude finished @lzf575's task in 16m 22s —— View job

---

- 这是一次 PR 评论触发的代码 review，请求是“review 下代码，使用中文说明”。 - 这是 review 任务，不是实现任务；只需要阅读 diff 和相关代码后给出中文反馈。 - 已知这是 `feat-net-sign` 分支相对 `origin/main` 的 PR，核心改动集中在 agent 侧 NetSign 协议接入、server 枚举映射和配置文档同步。 - 需要重点复核 parser 注册、session 聚合、协议状态映射、eBPF inference/常量、默认配置接入是否完整。 - 我会先更新 checklist，再阅读关键改动文件和关联逻辑，最后把 review 结论整理成中文并回写到这条评论；本次不做代码修改，也不需要 push。

Checklist

• 阅读 PR diff 和相关文件
• 核对 parser / 聚合 / 映射 / 配置接入
• 输出中文 review 结论

进展

• 已复核 @agent/src/flow_generator/protocol_logs/rpc/net_sign.rs、@agent/src/flow_generator/protocol_logs/parser.rs、@agent/src/common/l7_protocol_log.rs、@agent/src/config/config.rs 和 enterprise stub。
• 正在继续确认是否还有确定性问题。

[lzf575]

@claude review 下这个pr，使用中文描述

[claude]

Claude finished @lzf575's task in 11m 43s —— View job

---

- 这是一次 PR 评论触发的代码 review；触发指令是“review 下这个pr，使用中文描述”。 - 这是 review 任务，不是实现任务；需要阅读 diff 和相关代码后给出中文反馈，并把结果更新到当前 Claude 评论。 - 我复核了 NetSign 在 agent/server/querier/eBPF 侧的接入，以及 session aggregation、状态映射、默认配置和 enterprise stub。 - 结论：前两轮提到的 eBPF 用户态常量/名称映射、默认 prefilter/tag filter、文档同步，这次看都已经补齐；当前还剩 1 个确定性问题，另有 1 个建议关注点。 - 本次只做 review，没有修改代码，也没有 push。

Checklist

• 阅读 PR diff 和相关文件
• 理解这次 review 的范围与请求
• 核对 parser / 聚合 / 状态映射 / 配置 / eBPF 接入
• 输出中文 review 结论

Review 结论

这轮复核后，前面提到的这些接入项已经补齐了：

• eBPF 用户态常量 / 名称映射 / datadump help：@agent/src/ebpf/mod.rs:74、@agent/src/ebpf/user/socket.h:300、@agent/src/ebpf/user/ctrl_tracer.c:151
• 默认 port_number_prefilters / tag_filters：@agent/src/config/config.rs:2047、@agent/src/config/config.rs:2080
• 配置模板和文档同步：@server/agent_config/template.yaml:6125、@server/agent_config/template.yaml:6289、@server/agent_config/README.md:8583、@server/agent_config/README.md:8657、@server/agent_config/README-CH.md:8395、@server/agent_config/README-CH.md:8468
• server / querier 枚举映射：@server/libs/datatype/flow.go:163、@server/libs/datatype/flow.go:702、@server/querier/db_descriptions/clickhouse/tag/enum/l7_protocol:14
• kernel inference 主链路接入：@agent/src/ebpf/kernel/include/common.h:81、@agent/src/ebpf/kernel/include/protocol_inference.h:1280、@agent/src/ebpf/kernel/include/protocol_inference.h:4210、@agent/src/ebpf/kernel/include/protocol_inference.h:4561

我这边还看到 1 个建议修复后再合并的问题：

1. session_id=None 但仍开启 session aggregation，cBPF 下会把同一条 flow 上的多组 NetSign 请求/响应共用一个聚合 key

• @agent/src/flow_generator/protocol_logs/rpc/net_sign.rs:224 返回 session_id() = None，但 @agent/src/flow_generator/protocol_logs/rpc/net_sign.rs:228 的 needs_session_aggregation() 仍然返回 true。
• 非 eBPF 路径下，session key 在没有 session_id 时会直接退化成 flow_id | 0：@agent/src/flow_generator/protocol_logs/parser.rs:217、@agent/src/flow_generator/protocol_logs/parser.rs:277。
• 后续聚合逻辑会直接按这个 key 做 merge / send / replace：@agent/src/flow_generator/protocol_logs/parser.rs:433、@agent/src/flow_generator/protocol_logs/parser.rs:463、@agent/src/flow_generator/protocol_logs/parser.rs:477、@agent/src/flow_generator/protocol_logs/parser.rs:513。

这意味着，只要同一条 TCP 连接里存在多组未完成的 NetSign 请求/响应，它们就会共用一个聚合槽，可能出现错配、提前发送或覆盖。对照已有企业协议，@agent/src/flow_generator/protocol_logs/rpc/iso8583.rs:118 和 @agent/src/flow_generator/protocol_logs/mq/web_sphere_mq.rs:73 都是在 session_id=None 时直接关闭 session aggregation。

建议二选一：

1. 如果 NetSign 没有稳定的 request/response 关联键，把 needs_session_aggregation() 改成 false；
2. 如果协议里能提取稳定关联字段，就补一个真实的 session_id()。

Fix this →

额外建议关注

2. request 侧把 response_status 预设成 Ok，语义上有点奇怪，虽然当前未必会直接出错

• @agent/src/flow_generator/protocol_logs/rpc/net_sign.rs:418-422 里，请求分支会执行 info.response_status = L7ResponseStatus::Ok。
• @agent/src/flow_generator/protocol_logs/rpc/net_sign.rs:339-346 会把这个状态写进 LogCache；而真正的错误统计只会在 response 合并后依据最终 resp_status 计数：@agent/src/common/l7_protocol_log.rs:365-385。

所以它现在大概率不会直接把失败请求误记成成功，但“request 先带一个 Ok 响应状态”本身容易让后续维护者误解，也和多数协议实现不太一致。更自然的做法是：请求分支保持默认状态，把状态判定留给响应分支。

如果你确认框架里 request 预填 Ok 是这个协议族的一贯约定，那这条可以忽略；否则建议顺手收敛一下。

Fix this →

补充说明

• 当前 OSS snapshot 里的 NetSign enterprise parser 仍是 stub：@agent/crates/enterprise-utils/src/lib.rs:394-401。所以这次 review 主要覆盖接入层、聚合逻辑和外围注册完整性，没法继续验证真实 TLV 字段解析的正确性。
• eBPF 侧 infer_net_sign_message() 在 socket 已确认协议后会直接返回 MSG_REQUEST：@agent/src/ebpf/kernel/include/protocol_inference.h:1292-1298。这里注释解释得比较清楚：只是为了续包场景继续上送，真正的 request/response 方向还是交给 Rust parser 根据 TLV 内容判定；这块我这次没看到明显问题。

[lzf575]

@claude review 下这个pr，使用中文描述

[claude]

Claude finished @lzf575's task in 10m 36s —— View job

---

- 这是一次 PR 评论触发的代码 review；触发指令是“review 下这个pr，使用中文描述”。 - 这是 review 任务，不是实现任务；需要阅读 diff 和相关代码后给出中文反馈，并把结果更新到当前 Claude 评论。 - 我重新复核了 NetSign 在 agent/server/querier/eBPF 侧的接入，以及 session aggregation、状态映射、默认配置和 enterprise stub。 - 结论：前几轮提到的 eBPF 用户态常量/名称映射、默认 prefilter/tag filter、文档同步，这次看都已经补齐；当前还剩 1 个确定性问题，另有 1 个建议关注点。 - 本次只做 review，没有修改代码，也没有 push。

Checklist

• 阅读 PR diff 和相关文件
• 核对 parser、聚合、状态映射与外围接入
• 整理中文 review 结论并更新评论

Review 结论

这轮复核后，前面提到的这些接入项已经补齐了：

• eBPF 用户态常量 / 名称映射 / datadump help：@agent/src/ebpf/mod.rs:74、@agent/src/ebpf/user/socket.h:300、@agent/src/ebpf/user/ctrl_tracer.c:151
• 默认 port_number_prefilters / tag_filters：@agent/src/config/config.rs:2047、@agent/src/config/config.rs:2080
• 配置模板和文档同步：@server/agent_config/template.yaml:6125、@server/agent_config/template.yaml:6289、@server/agent_config/README.md:8583、@server/agent_config/README.md:8657、@server/agent_config/README-CH.md:8395、@server/agent_config/README-CH.md:8468
• server / querier 枚举映射：@server/libs/datatype/flow.go:702、@server/querier/db_descriptions/clickhouse/tag/enum/l7_protocol:14
• kernel inference 主链路接入：@agent/src/ebpf/kernel/include/common.h:81、@agent/src/ebpf/kernel/include/protocol_inference.h:1297

我这边还看到 1 个建议修复后再合并的问题：

1. session_id=None 但仍开启 session aggregation，cBPF 下会把同一条 flow 上的多组 NetSign 请求/响应共用一个聚合 key

• @agent/src/flow_generator/protocol_logs/rpc/net_sign.rs:224 返回 session_id() = None，但 @agent/src/flow_generator/protocol_logs/rpc/net_sign.rs:228 的 needs_session_aggregation() 仍然返回 true。
• 非 eBPF 路径下，session key 在没有 session_id 时会直接退化成 flow_id | 0：@agent/src/flow_generator/protocol_logs/parser.rs:217、@agent/src/flow_generator/protocol_logs/parser.rs:277。
• 后续聚合逻辑会直接按这个 key 做 merge / send / replace：@agent/src/flow_generator/protocol_logs/parser.rs:433、@agent/src/flow_generator/protocol_logs/parser.rs:463、@agent/src/flow_generator/protocol_logs/parser.rs:477、@agent/src/flow_generator/protocol_logs/parser.rs:513。

这意味着，只要同一条 TCP 连接里存在多组未完成的 NetSign 请求/响应，它们就会共用一个聚合槽，可能出现错配、提前发送或覆盖。对照已有企业协议，@agent/src/flow_generator/protocol_logs/rpc/iso8583.rs:118 和 @agent/src/flow_generator/protocol_logs/mq/web_sphere_mq.rs:73 都是在 session_id=None 时直接关闭 session aggregation。

建议二选一：

1. 如果 NetSign 没有稳定的 request/response 关联键，把 needs_session_aggregation() 改成 false；
2. 如果协议里能提取稳定关联字段，就补一个真实的 session_id()。

Fix this →

额外建议关注

2. request 侧把 response_status 预设成 Ok，语义上比较别扭，虽然当前大概率不会直接统计错

• @agent/src/flow_generator/protocol_logs/rpc/net_sign.rs:418-422 里，请求分支会执行 info.response_status = L7ResponseStatus::Ok。
• @agent/src/flow_generator/protocol_logs/rpc/net_sign.rs:339-345 会把这个状态写进 LogCache；而聚合超时发送时会由 session aggregator 用 Timeout 覆盖：@agent/src/flow_generator/protocol_logs/parser.rs:578-588。
• 当前 perf 里请求首次入缓存时只会按 msg_type=Request 计 request_count，错误计数仍看最终 response/override status：@agent/src/common/l7_protocol_info.rs:286-293、@agent/src/common/l7_protocol_log.rs:381-385。

所以它现在看起来不会明显把失败流量记成成功，但“request 先带一个 Ok 响应状态”本身容易让后续维护者误解，也和多数协议实现不太一致。更自然的做法是：请求分支保持默认状态，把 response_status 的判定留给响应分支或超时覆盖逻辑。

如果你确认框架里 request 预填 Ok 是这类协议的一贯约定，这条可以忽略；否则建议顺手收敛一下。

Fix this →

补充说明

• 当前 OSS snapshot 里的 NetSign enterprise parser 仍是 stub：@agent/crates/enterprise-utils/src/lib.rs:396-401。所以这次 review 主要覆盖接入层、聚合逻辑和外围注册完整性，没法继续验证真实 TLV 字段解析的正确性。
• eBPF 侧 infer_net_sign_message() 在 socket 已确认协议后会直接返回 MSG_REQUEST：@agent/src/ebpf/kernel/include/protocol_inference.h:1306-1315。这里注释说明得比较清楚：只是为了续包场景继续上送，真正的 request/response 方向仍交给 Rust parser 根据 TLV 内容判定；这块我这次没看到明显问题。

[lzf575]

@claude review 下这个pr，使用中文描述

[claude]

Claude finished @lzf575's task in 7m 3s —— View job

---

- 这是一次 PR 评论触发的代码 review；触发指令是“review 下这个pr，使用中文描述”。 - 这是 review 任务，不是实现任务；我重新复核了 `origin/main...HEAD` 的关键改动，重点确认前几轮提到的问题是否已修复。 - 本次重点检查了 NetSign 的 parser 注册、session aggregation、响应状态映射、eBPF inference、默认 prefilter/tag filter、server/querier 枚举映射。 - 结论：前几轮提到的大部分外围接入和状态映射问题都已经补齐；当前还剩 1 个确定性问题，建议修完再合并。 - 本次只做 review，没有修改代码，也没有 push。

Checklist

• 阅读 PR diff 和相关文件
• 核对 parser、聚合、状态映射与外围接入
• 整理中文 review 结论并更新评论

Review 结论

这轮复核下来，前面提到的这些点已经补齐了：

• parser 注册与协议枚举接入：@agent/src/common/l7_protocol_log.rs:103-107、@agent/src/common/l7_protocol_log.rs:189-208、@agent/src/common/l7_protocol_info.rs:133-134、@agent/crates/public/src/l7_protocol.rs:63-67
• eBPF 常量 / 名称映射 / datadump help：@agent/src/ebpf/mod.rs:72-74、@agent/src/ebpf/user/socket.h:298-301、@agent/src/ebpf/user/ctrl_tracer.c:149-151
• kernel inference 主链路：@agent/src/ebpf/kernel/include/common.h:79-81、@agent/src/ebpf/kernel/include/protocol_inference.h:1297-1382
• 默认 port_number_prefilters / tag_filters 和配置模板：@agent/src/config/config.rs:2046-2048、@agent/src/config/config.rs:2079-2081、@server/agent_config/template.yaml:6124-6125、@server/agent_config/template.yaml:6288-6289
• server / querier 映射：@server/libs/datatype/flow.go:702-706、@server/querier/db_descriptions/clickhouse/tag/enum/l7_protocol:14
• 前一轮提到的响应状态语义问题这次也顺手收敛了：现在只有 response 分支设置 response_status，且非空非 "1" 的 result_code 会落到 ServerError，见 @agent/src/flow_generator/protocol_logs/rpc/net_sign.rs:402-413、@agent/src/flow_generator/protocol_logs/rpc/net_sign.rs:418-421

我这边还看到 1 个建议修复后再合并的问题：

1. session_id=None 但仍开启 session aggregation，cBPF 下同一条 flow 上的多组 NetSign 请求/响应仍会共用一个聚合 key

• @agent/src/flow_generator/protocol_logs/rpc/net_sign.rs:224-229 里，session_id() 返回 None，但 needs_session_aggregation() 仍返回 true。
• 非 eBPF 路径下，session key 在没有 session_id 时会直接退化成 flow_id | 0：@agent/src/flow_generator/protocol_logs/parser.rs:217-223、@agent/src/flow_generator/protocol_logs/parser.rs:268-278。
• 后续聚合逻辑会直接按这个 key 做 merge / send / replace：@agent/src/flow_generator/protocol_logs/parser.rs:433-444、@agent/src/flow_generator/protocol_logs/parser.rs:463-529。

这意味着，只要同一条 TCP 连接上同时存在多组尚未完成的 NetSign 请求/响应，它们就会落到同一个聚合槽里，可能出现错配、提前发送或覆盖。

对照已有企业协议，@agent/src/flow_generator/protocol_logs/rpc/iso8583.rs:117-125 和 @agent/src/flow_generator/protocol_logs/mq/web_sphere_mq.rs:72-79 都是在 session_id=None 时直接关闭 session aggregation。

建议二选一：

1. 如果 NetSign 没有稳定的 request/response 关联键，把 needs_session_aggregation() 改成 false；
2. 如果协议里其实能提取稳定关联字段，就补一个真实的 session_id()。

Fix this →

补充说明

• 当前 OSS snapshot 里的 NetSign enterprise parser 仍是 stub：@agent/crates/enterprise-utils/src/lib.rs:393-401。所以这次 review 主要覆盖接入层、聚合逻辑和外围注册完整性，没法继续验证 enterprise 实际字段解析实现。
• 除了上面这点外，我这次没再看到新的确定性问题。