共计 1407 个字符，预计需要花费 4 分钟才能阅读完成。
Kindling 是一款基于 eBPF 技术的云原生可观测性开源我的项目。本文将次要介绍如何通过 Kindling 对 HTTP 协定进行解析。
在故障排查过程中，咱们通常对申请性能、申请内容和返回内容感兴趣。这使咱们能晓得申请和接管了什么内容，是否有异样等根本信息。如何获取申请的具体详细信息，传统形式是通过 tcpdump 获取申请包数据，而后通过 wireshark 查看其具体协定内容。
tcpdump 尽管在生产环境中常常应用，但因为获取的数据量和大小限度，不适宜始终开启，只有在排查问题时应用。而获取的数据也无奈间接查看，需下载到本地通过 wireshark 剖析查看。基于 tcp 的诸多问题，所以 Kindling 通过 eBPF 形式实现申请的具体分析。
那么 Kindling 是如何实现实时可用的协定解析性能呢？次要波及 3 块性能：
• 数据采集
• 申请 / 响应关联
• 申请 / 响应解析
协定解析流程图
1 数据采集
先来查看下一个简略的 HTTP 服务
HTTP 服务伪代码
当接管到申请时会有 accept/read/write/close 等函数执行，这些函数最终执行内核的零碎调用。
HTTP 服务接管申请流程图
应用 strace 命令查看一次申请的零碎调用状况
• read 接管 HTTP 申请 /test
• 第一个 write 日志输入
• 第二个 write 返回 HTTP 后果
从日志中可剖析出，申请通过 read 零碎调用，日志和响应都是通过 write 零碎调用。
Kindling 已实现对系统事件调用进行抓取，并将相干的 read 和 write 零碎调用转换为 Kindling 事件，最终生成 3 条事件。事件格局定义可参见 kindling_event.proto。
零碎调用与 Kindling 事件映射
参数阐明：
• fd 读写申请的文件描述符
• size 申请报文大小
• res 返回大小
• data 申请报文内容
• latency 读 / 写操作耗时
• category 事件类型，NET 是指网络事件，FILE 是文件读写事件
2 申请 / 响应关联
惯例的 TCP 申请都会用同一个 FD 进行通信，只需依据过程号和 FD 就能关联同一个申请和响应。
申请 - 响应关联
3 申请 / 响应解析
尽管有了报文，但不同的协定定义的标准也不同。那么如何晓得该报文是什么协定，并且用该协定进行解析呢？次要波及 2 块内容：
• 协定辨认
• 协定解析
申请 - 响应解析流程图
3.1 协定辨认
通过特色或关键字疾速匹配协定，缩小协定解析的次数，晋升整体解析的性能。
HTTP 报文标准
对于 HTTP 申请来说，通过 HTTP 版本号 (HTTP/1.0 或 HTTP/1.1) 能够疾速辨认协定。
但因为抓包大小限度，如果一个申请的 URL 长度超过包的大小，那么无奈获取后续的 HTTP 版本号，于是采纳端口协定配置形式也能辨认协定。
3.2 协定解析
协定解析是为了产生指标用于后续剖析，在解析过程中需依据协定本身的格局进行解析。
因为报文内容是 byte 数组格局，Kindling 提供了封装好的 API 用于解析。
以 HTTP 协定为例，可解析出如下信息：
• 申请行 – 办法、URL 信息
• HTTP 头信息 – traceId 信息
• 状态行 – 状态码信息
HTTP 解析样例
3.2.1 解析 HTTP 申请
解析申请过程就是对申请进行逐帧解析，读取到对应的属性后最终将值存储到 attribute 中
3.2.2 解析 HTTP 响应
解析响应跟解析申请相似，也是逐帧解析，将解析出的属性存储到 attribute 中。
此外，需思考报文非法场景（状态码非数值），确保解析失常完结。
退出咱们
关注咱们
