解析私有协议有response-status label 无 request-content label

[LambertZhaglog]

我在给kindling添加一个私有协议的解析器，设定解析成功时， kindling_entity_request_total 指标会同时带有request-content 和 response-status 两个label。 从prometheus 上查看，该指标的绝大多数timeSeries 是带有两个label的。但也有少部分timeSeries 只带有response-status标签，而不带request-content 标签。这让我很困惑，希望能得到些排查提示。

或许有帮助的信息如下

1. 该私有协议解析器，在parseRequest 时，只有在把request-content标签写入protocol.PayloadMessage中后， 才返回{true, true}， 其他情况都返回{false, false}
2. 未在prometheus 配置任何 针对request-context标签的label drop 或label rename 等

[dxsup]

request_content和response_content这两个字段在不同协议下代表的含义不同，有的协议确实会缺少某一个字段，具体详情见文档Prometheus Metrics.

在开发新协议时，要输出request_content和response_content这两个字段，需要在exporter/tools/adapter/net_dict.go中编写字段转换字典，将自己的字段转换到这两个字段上；另外要输出指标，还需要在aggregateprocessor/processor中增加要聚合的字段名。

目前增加新的协议要改动的组件偏多，后续有计划对这部分需求进行改进。

[dxsup]

analyzer 确实没写入该字段，我解析request 报文只做了两件事。

1. 在analyzer 中将request content 保存到ContentKey 字段
2. 在net_dict 中将ContentKey 字段 转为request-content 字段

按照你的写法，结果与aggregateProcessor关系不大了，因为我们默认会把content_key字段作为聚合字段。

但也有少部分timeSeries 只带有response-status标签，而不带request-content 标签。

这部分数据的protocol字段是你解析的协议吧？你说：

只有在把request-content标签写入protocol.PayloadMessage中后， 才返回{true, true}

根据上下文，我理解是只有把content_key标签写入protocol.PayloadMessage中才算解析成功？这样的话，如果最终的指标中protocol是你要的协议，但却缺少request_content字段，的确是不符合预期。有一种可能是DataGroup复用导致的字段丢失，建议使用日志的debug selector功能分别将networkanalyzer、aggregateprocessor和otelexporter的输出结果打印出来，看字段究竟是在哪里发生缺失的。

[LambertZhaglog]

建议使用日志的debug selector功能分别将networkanalyzer、aggregateprocessor和otelexporter的输出结果打印出来，看字段究竟是在哪里发生缺失的。

观察到从NetworkAnalyzer 开始，ContentKey 字段就缺失了。 所以判定 NetworkAnalyzer 的实现有bug。

另外我通过debug selector 观察到很多异常现象

1. NetworkAnalyzer的debug 日志，发现，http 协议的报文，带有dns，以及我自定义协议特有的label。dst_port=2333
2. NetworkAnalyzer的debug 日志，发现，Unsupport 协议的报文, 带有dns，http，以及我自定义协议特有的label
3. NetworkAnalyzer的debug 日志，发现，自定义协议的报文，带有http 协议的标签。我已经在配置文件为自定义协议设定了well-known 端口号，这里的报文也确实是well-known 的端口号。按照NetworkAnalyzer.parseProtocols 的实现，在step 1 中就完成了well-known port的解析，不应该带有http 的标签
4. NetworkAnalyzer 和 otelexport的debug 日志，发现，自定义协议的报文，content_key 标签值为空，没有该协议自定义字段的特有label。 该报文的dst_port 是协议well-known 的
5. NetworkAnalyzer的debug 日志，发现，自定义协议的报文，dst_port 是协议well-known 的，同时没有content_key 标签和自定义协议特有的标签。

[dxsup]

观察到这些现象可能的原因是，NetworkAnalyzer在使用DataGroup数据结构时，使用了sync.Pool来复用对象。在把对象放回资源池时，我们只会重置Labels中的value，而不会删除key，这就可能导致在其他协议的数据中看到不属于该协议的labels key。但这不影响后续的数据，因为数据会在aggregateprocessor被聚合重新构造数据结构。

[dxsup]

1, 2, 3应该是上面的原因；而4, 5还是要再看一下协议解析部分是否确实拿到了协议相关内容。

[LambertZhaglog]

1, 2, 3应该是上面的原因；而4, 5还是要再看一下协议解析部分是否确实拿到了协议相关内容。

4, 5 出现的原因是，

kindling/collector/pkg/component/analyzer/network/network_analyzer.go

Line 369 in 45bef0a

return na.getRecords(mps, staticProtocol, nil)

数据包从协议特定端口拿到，用自定义协议解析器解析该数据包失败，即使失败也带有端口对应的协议名。 其他label值为空，或为默认值，如您所说，

NetworkAnalyzer在使用DataGroup数据结构时，使用了sync.Pool来复用对象。在把对象放回资源池时，我们只会重置Labels中的value，而不会删除key，这就可能导致在其他协议的数据中看到不属于该协议的labels key