Open Fancyki1 opened 1 month ago
@Fancyki1 你提到的方法挺好的,相当于定义一个 http/grpc header injection 的规范,通过 value 的特殊性,在一个 value 中放进去所有需要 injection 的内容。
我们想想如何能在规范层面推进这种做法。
请问一下低于6.4的版本会有这个问题吗?
@gbling 文章来源都有:https://www.deepflow.io/blog/zh/053-high-performance-decoding-of-http2-compressed-headers-using-ebpf-kprobe/ 6.4之前都不支持这个功能
@Fancyki1 想再确认一下,HTTP1.1 协议的也会有同样的情况么?
@gbling http1.1 可以用wasm插件解析去实现,不需要用到这个特性
@Fancyki1 是这样的,我们在测试链路追踪的时候通过自定义的 http_log_x_request_id 做链路的关联,内部链路调用都是用 http1.1 ,会存在链路不全的情况;是想再明确一下这个特性是只对 HTTP2/gRPC 生效,还是 http1.1 也会生效的?
@gbling 你多看看文档,文档里面都写了
## Configuration to extract the customized header fields of HTTP, HTTP2, GRPC protocol etc
#extra-log-fields:
## for example:
## http:
## - field-name: "user-agent"
## - field-name: "cookie"
# http: []
# http2: []
你用>v6.4版本,配置了http就启用了http1.1,而且http1.1不存在http2索引表的采集乱序不全的问题,直接用就好了,而且你要弄明白你要实现什么效果,如果是链路追踪那和这个没什么关系,如果想用这个看链路追踪是否每个请求都有http_log_x_request_id那倒是可以辅助排障使用
Search before asking
Description
需求: deepflow v6.4版本实现了eBPF kprobe 高性能解码 HTTP2 压缩头,自动学习通信双方的压缩字典,但是在实际过程中采集自定义header存在丢失乱序覆盖的问题,希望使用只采集value去解决自定义头匹配的问题 文章来源:https://www.deepflow.io/blog/zh/053-high-performance-decoding-of-http2-compressed-headers-using-ebpf-kprobe/ 缺陷:
问题描述: 对于可能存在压缩字典乱序的问题,导致采集内容key和value对应不上,实测效果
发送一个http2/gRPC的请求
技术原理:https://kiosk007.top/post/http-2-0-header-compression/ http2索引表包括:静态表rfc7541和动态表
Server代码落库位置:
情况1:正常,少数
AttributeNames = ["rpc_services","x-custom-code","x-custom-msg","x-custom-data"] AttributeValues = ["xxx","200","success","{\"test\": \"data\"}"]
情况2:异常,大量
x-custome-msg 被 x-custome-code 覆盖,索引表解析乱序
AttributeNames = ["rpc_services","x-custom-code","x-custom-code","x-custom-data"] AttributeValues = ["xxx","200","success","{\"test\": \"data\"}"]
x-custome-code 被 x-custome-data 覆盖,索引表解析乱序
AttributeNames = ["rpc_services","x-custom-data","x-custom-msg","x-custom-data"] AttributeValues = ["xxx","200","success","{\"test\": \"data\"}"]
定义的header key :x-custom-content,没有实际意义,如果wireshark和deepflow学习不到这个值的时候是unknown
特定字符串分隔符:!#!
x-custom-content: "200!#!success!#!{\"test\": \"data\"}"
实际协议解析可能为:unknown:"200!#!success!#!{\"test\": \"data\"}"
static_config: l7-protocol-advanced-features: extra-log-fields: http2:
由于特殊分隔符的情况较少,解析header时候可以被特殊分隔符分割且分割后的长度大于等于2的value,按照匹配规则和预定义的key进行补全。
补全后的结果和正常自学习header结果一致,效果稳定
场景补充:正则匹配处理(字段冗余思路)
增加一个配置
举例伪代码处理:
匹配解析后的结果
备注: 采用HTTP2静态表中的字段
user-agent
和server
,deepflow采集的效果稳定很多,但是对应的server代码要做修改处理,静态表字段并不符合协议标准和存在不安全性,看能否兼容动态表处理,兼容自定义http2 header的场景 @sharangUse case
No response
Related issues
No response
Are you willing to submit a PR?
Code of Conduct