# Technical Documentation: hengyoush/kyanos > ℹ️ **Provenance:** Hybrid Fusion: `hengyoush/kyanos` (README + 10 In-Tree Chapters) · [CodeWiki Reference](https://codewiki.google/github.com/hengyoush/kyanos) · Recency: Active (< 180 days) ## 1. Project Overview & Quickstart (hengyoush/kyanos) # kyanos [简体中文](./README_CN.md) | English - [English Document](https://kyanos.io/) ## Table of Contents - [kyanos](#kyanos) - [Table of Contents](#table-of-contents) - [What is kyanos](#what-is-kyanos) - [Examples](#examples) - [❗ Requirements](#-requirements) - [🎯 How to get kyanos](#-how-to-get-kyanos) - [📝 Documentation](#-documentation) - [⚙ Usage](#-usage) - [🏠 How to build](#-how-to-build) - [🤝 Feedback and Contributions](#-feedback-and-contributions) - [🙇‍ Special Thanks](#-special-thanks) - [🗨️ Contacts](#️-contacts) - [Star History](#star-history) ## What is kyanos Kyanos is an **eBPF-based** network issue analysis tool that enables you to capture network requests, such as HTTP, Redis, MySQL, Kafka, MongoDB, RocketMQ, and DNS requests. It also helps you analyze abnormal network issues and quickly troubleshooting without the complex steps of packet capturing, downloading, and analysis. 1. **Powerful Traffic Filtering**: Not only can filter based on traditional IP/port information, can also filter by process/container, L7 protocol information, request/response byte size, latency, and more. ```bash # Filter by pid ./kyanos watch --pids 1234 # Filter by container id ./kyanos watch --container-id abc # Filter by Redis key ./kyanos watch redis --keys my-key1,my-key2 # Filter by response byte size ./kyanos watch --resp-size 10000 ``` 2. **Advanced Analysis Capabilities** : Unlike tcpdump, which only provides fine-grained packet capture, Kyanos supports aggregating captured packet metrics across various dimensions, quickly providing the critical data most useful for troubleshooting. Imagine if the bandwidth of your HTTP service is suddenly maxed out—how would you quickly analyze `which IPs` and `which requests` are causing it? With Kyanos, you just need one command: `kyanos stat http --bigresp` to find the largest response byte sizes sent to remote IPs and view specific data on request and response metrics. 3. **In-Depth Kernel-Level Latency Details**: In real-world, slow queries to remote services like Redis can be challenging to diagnose precisely. Kyanos provides kernel trace points from the arrival of requests/responses at the network card to the kernel socket buffer, displaying these details in a visual format. This allows you to identify exactly which stage is causing delays. 4. **Lightweight and Dependency-Free**: Almost zero dependencies—just a single binary file and one command, with all results displayed in the command line. 5. **Automatic SSL Traffic Decryption** : All captured requests and responses are presented in plaintext. ## Examples **Capture HTTP Traffic with Latency Details** Run the command: ```bash ./kyanos watch http ``` The result is as follows: **Capture Redis Traffic with Latency Details** Run the command: ```bash ./kyanos watch redis ``` The result is as follows: **Identify the Slowest Requests in the Last 5 Seconds** Run the command: ```bash ./kyanos stat --slow --time 5 ``` The result is as follows: ## ❗ Requirements Kyanos currently supports kernel versions 3.10(from 3.10.0-957) and 4.14 or above (with plans to support versions between 4.7 and 4.14 in the future). > You can check your kernel version using `uname -r`. ## 🎯 How to get kyanos You can download a statically linked binary compatible with amd64 and arm64 architectures from the [release page](https://github.com/hengyoush/kyanos/releases): ```bash tar xvf kyanos_vx.x.x_linux_amd64.tar.gz ``` Then, run kyanos with **root privilege**: ```bash sudo ./kyanos watch ``` If the following table appears: 🎉 Congratulations! Kyanos has started successfully. ## 📝 Documentation [English Document](https://kyanos.io/) ## ⚙ Usage The simplest usage captures all protocols currently supported by Kyanos: ```bash sudo ./kyanos watch ``` Each request-response record is stored as a row in a table, with each column capturing basic information about that request. You can use the arrow keys or `j/k` to move up and down through the records: Press `Enter` to access the details view: In the details view, the first section shows **Latency Details**. Each block represents a "node" that the data packet passes through, such as the process, network card, and socket buffer. Each block includes a time value indicating the time elapsed from the previous node to this node, showing the process flow from the process sending the request to the network card, to the response being copied to the socket buffer, and finally read by the process, with each step’s duration displayed. The second section provides **Detailed Request and Response Content**, split into Request and Response parts, and truncates content over 1024 bytes. For targeted traffic capture, such as HTTP traffic: ```bash ./kyanos watch http ``` You can narrow it further to capture traffic for a specific HTTP path: ```bash ./kyanos watch http --path /abc ``` Learn more: [Kyanos Docs](https://kyanos.io/) ## 🏠 How to build 👉 [COMPILATION.md](./COMPILATION.md) ## 🤝 Feedback and Contributions > [!IMPORTANT] > > If you encounter any issues or bugs while using the tool, please feel free to > ask questions in the issue tracker. ## 🙇‍ Special Thanks During the development of kyanos, some code was borrowed from the following projects: - [eCapture](https://ecapture.cc/zh/) - [pixie](https://github.com/pixie-io/pixie) - [ptcpdump](https://github.com/mozillazg/ptcpdump) ## 🗨️ Contacts For more detailed inquiries, you can use the following contact methods: - **My Email:** [hengyoush1@163.com](mailto:hengyoush1@163.com) - **My Blog:** [http://blog.deadlock.cloud](http://blog.deadlock.cloud/) ## Star History [](https://star-history.com/#hengyoush/kyanos&Date) [Back to top](#top) ## 2. In-Tree Documentation Chapters (hengyoush/kyanos) ## File: README.md # kyanos [简体中文](./README_CN.md) | English - [English Document](https://kyanos.io/) ## Table of Contents - [kyanos](#kyanos) - [Table of Contents](#table-of-contents) - [What is kyanos](#what-is-kyanos) - [Examples](#examples) - [❗ Requirements](#-requirements) - [🎯 How to get kyanos](#-how-to-get-kyanos) - [📝 Documentation](#-documentation) - [⚙ Usage](#-usage) - [🏠 How to build](#-how-to-build) - [🤝 Feedback and Contributions](#-feedback-and-contributions) - [🙇‍ Special Thanks](#-special-thanks) - [🗨️ Contacts](#️-contacts) - [Star History](#star-history) ## What is kyanos Kyanos is an **eBPF-based** network issue analysis tool that enables you to capture network requests, such as HTTP, Redis, MySQL, Kafka, MongoDB, RocketMQ, and DNS requests. It also helps you analyze abnormal network issues and quickly troubleshooting without the complex steps of packet capturing, downloading, and analysis. 1. **Powerful Traffic Filtering**: Not only can filter based on traditional IP/port information, can also filter by process/container, L7 protocol information, request/response byte size, latency, and more. ```bash # Filter by pid ./kyanos watch --pids 1234 # Filter by container id ./kyanos watch --container-id abc # Filter by Redis key ./kyanos watch redis --keys my-key1,my-key2 # Filter by response byte size ./kyanos watch --resp-size 10000 ``` 2. **Advanced Analysis Capabilities** : Unlike tcpdump, which only provides fine-grained packet capture, Kyanos supports aggregating captured packet metrics across various dimensions, quickly providing the critical data most useful for troubleshooting. Imagine if the bandwidth of your HTTP service is suddenly maxed out—how would you quickly analyze `which IPs` and `which requests` are causing it? With Kyanos, you just need one command: `kyanos stat http --bigresp` to find the largest response byte sizes sent to remote IPs and view specific data on request and response metrics. 3. **In-Depth Kernel-Level Latency Details**: In real-world, slow queries to remote services like Redis can be challenging to diagnose precisely. Kyanos provides kernel trace points from the arrival of requests/responses at the network card to the kernel socket buffer, displaying these details in a visual format. This allows you to identify exactly which stage is causing delays. 4. **Lightweight and Dependency-Free**: Almost zero dependencies—just a single binary file and one command, with all results displayed in the command line. 5. **Automatic SSL Traffic Decryption** : All captured requests and responses are presented in plaintext. ## Examples **Capture HTTP Traffic with Latency Details** Run the command: ```bash ./kyanos watch http ``` The result is as follows: **Capture Redis Traffic with Latency Details** Run the command: ```bash ./kyanos watch redis ``` The result is as follows: **Identify the Slowest Requests in the Last 5 Seconds** Run the command: ```bash ./kyanos stat --slow --time 5 ``` The result is as follows: ## ❗ Requirements Kyanos currently supports kernel versions 3.10(from 3.10.0-957) and 4.14 or above (with plans to support versions between 4.7 and 4.14 in the future). > You can check your kernel version using `uname -r`. ## 🎯 How to get kyanos You can download a statically linked binary compatible with amd64 and arm64 architectures from the [release page](https://github.com/hengyoush/kyanos/releases): ```bash tar xvf kyanos_vx.x.x_linux_amd64.tar.gz ``` Then, run kyanos with **root privilege**: ```bash sudo ./kyanos watch ``` If the following table appears: 🎉 Congratulations! Kyanos has started successfully. ## 📝 Documentation [English Document](https://kyanos.io/) ## ⚙ Usage The simplest usage captures all protocols currently supported by Kyanos: ```bash sudo ./kyanos watch ``` Each request-response record is stored as a row in a table, with each column capturing basic information about that request. You can use the arrow keys or `j/k` to move up and down through the records: Press `Enter` to access the details view: In the details view, the first section shows **Latency Details**. Each block represents a "node" that the data packet passes through, such as the process, network card, and socket buffer. Each block includes a time value indicating the time elapsed from the previous node to this node, showing the process flow from the process sending the request to the network card, to the response being copied to the socket buffer, and finally read by the process, with each step’s duration displayed. The second section provides **Detailed Request and Response Content**, split into Request and Response parts, and truncates content over 1024 bytes. For targeted traffic capture, such as HTTP traffic: ```bash ./kyanos watch http ``` You can narrow it further to capture traffic for a specific HTTP path: ```bash ./kyanos watch http --path /abc ``` Learn more: [Kyanos Docs](https://kyanos.io/) ## 🏠 How to build 👉 [COMPILATION.md](./COMPILATION.md) ## 🤝 Feedback and Contributions > [!IMPORTANT] > > If you encounter any issues or bugs while using the tool, please feel free to > ask questions in the issue tracker. ## 🙇‍ Special Thanks During the development of kyanos, some code was borrowed from the following projects: - [eCapture](https://ecapture.cc/zh/) - [pixie](https://github.com/pixie-io/pixie) - [ptcpdump](https://github.com/mozillazg/ptcpdump) ## 🗨️ Contacts For more detailed inquiries, you can use the following contact methods: - **My Email:** [hengyoush1@163.com](mailto:hengyoush1@163.com) - **My Blog:** [http://blog.deadlock.cloud](http://blog.deadlock.cloud/) ## Star History [](https://star-history.com/#hengyoush/kyanos&Date) [Back to top](#top) --- ## File: docs/cn/debug-tips.md # Debug Tips ## 构建相关 注意每次修改 eBPF 相关代码后都需要使用 `make build-bpf` 重新生成一些 bpf 相关代码，然后再用 `make` 构建或者在 IDE 里调试。 使用 `kyanos-debug` 来构建带有调试信息的二进制文件, 以便更好地进行调试。 ```sh make kyanos-debug ``` ## 日志相关 启动 kyanos 开启日志，日志分为几个模块可分别开启，5 为 debug 级别，默认是 warn 级别。如下是每个模块的日志选项： | 参数 | 含义 | | --------------------- | ------------------------------------------------------------------------------------------- | | --agent-log-level | 指定 agent 模块日志级别，主要是和 Agent 启动等相关的日志 | | --bpf-event-log-level | 指定 bpf 事件日志级别，一些内核上报的和 syscall 层上报的事件会打印出来 | | --conntrack-log-level | 指定 conntrack 模块日志级别，一些连接相关的事件比如连接创建、协议推断、连接关闭等会打印出来 | | --protocol-log-level | 指定协议模块日志级别，主要是具体协议解析相关的日志 | | --uprobe-log-level | 指定 uprobe 模块日志级别，主要是和 ssl 探针相关的日志 | 比如如果你在调试协议解析相关部分的代码建议加上：`--bpf-event-log-level 5 --conntrack-log-level 5 --protocol-log-level 5`。 如果你碰到 eBPF 代码加载失败的情况，可以加上 `--agent-log-level 5` 日志打印一些 Agent 启动时的日志。 日志输出默认到/tmp 下，加上 `--debug-output` 选项可以让日志输出到标准输出，而且不再展示 tui 会展示的表格，抓取到的请求都会直接输出到控制台: ``` WARN[0023] [ Request ] GET /health HTTP/1.1 Host: :8080 User-Agent: Go-http-client/1.1 Accept-Encoding: gzip [ Response ] HTTP/1.1 200 OK Date: Wed, 01 Jan 2025 16:20:20 GMT Content-Length: 2 Content-Type: text/plain; charset=utf-8 OK [conn] [pid=2252][local addr]=127.0.0.1:8080 [remote addr]=127.0.0.1:38664 [side]=server [ssl]=false [total duration] = 0.423(ms)(start=2025-01-02 00:20:20.095, end=2025-01-02 00:20:20.095) [read from sockbuf]=0.296(ms) [process internal duration]=0.078(ms) [syscall] [read count]=1 [read bytes]=92 [write count]=1 [write bytes]=118 ``` > [!TIP] > > 调试协议解析相关代码时可以使用：`--bpf-event-log-level 5 --conntrack-log-level 5 --protocol-log-level 5 --debug-output` > 选项就基本上足够了。 ## eBPF 相关 协议推断代码可以通过 `bpf_printk` 打印日志调试，参考：https://nakryiko.com/posts/bpf-tips-printk/。 ## IDE 调试相关 VSCODE 直接打开项目即可，.vscode/launch.json 添加配置如下： ```json { "version": "0.2.0", "configurations": [ { "name": "Launch file", "type": "go", "request": "launch", "mode": "debug", "program": "${workspaceFolder}", "args": ["watch", "--debug-output"] } ] } ``` 注意添加 `--debug-output` 参数。 ## 源码结构 ``` > agent > analysis (聚合分析模块，stat命令用到) > conn （连接跟踪模块） > protocol（协议解析模块） > render（TUI渲染模块） > uprobe（uprobe相关主要是ssl探针） > bpf > loader (bpf 程序加载逻辑) pktlatency.bpf.go (内核态核心代码，包括系统调用和内核部分的事件上报等逻辑) gotls.bpf.go (gotls探针相关) protocol_inference.h (协议推断相关) openssl* (openssl相关) > cmd (命令行相关) > common (一些工具类) > docs (基于vitepress的文档) ``` --- ## File: docs/cn/faq.md --- next: false prev: false --- # FAQ ## 支持运行在 Windows / Mac 上吗 ？ 目前还未支持，但后续有计划支持。([ISSUE-151](https://github.com/hengyoush/kyanos/issues/151)) ## 支持运行在低版本内核上吗 ？ 目前支持最低内核版本: 3.10.0-957，而且低版本内核下 kyanos 的会缺少某些功能。 目前 3.\*版本内核不支持根据容器 id/容器名称等过滤流量，也无法自动关联 NAT 前后的流量。 ## 支持运行在 WSL 上的 Linux 吗 ? 理论上支持，但一般在 WSL 上的 Linux 发行版默认不带 linux headers，但 kyanos 会依赖，所以可能需要修改编译选项手动编译内核，具体方法可参考：[Enabling eBPF/XDP for Kernel Tinkering on WSL2](https://dev.to/wiresurfer/unleash-the-forbidden-enabling-ebpfxdp-for-kernel-tinkering-on-wsl2-43fj) ## 可以运行在容器/Pod 里吗 ? 必须运行在具有特权模式下的容器/Pod 里。 ## 当使用 `--pod-name` 选项时出现 "can not find any running pod by name xxx" 日志 Kyanos 必须与目标 Pod 运行在同一主机上。 ## 运行出现 `can't find btf file to load!` 日志 可能是因为你的系统缺少了 btf 文件导致的，可以在这里 https://mirrors.openanolis.cn/coolbpf/btf/ 以及 https://github.com/aquasecurity/btfhub-archive/ 这里手动下载和你的内核匹配的 BTF 文件，启动 kyanos 时通过 `--btf` 选项指定你下载的 btf 文件即可。 ## 怎么理解 watch 结果中内核耗时的可视化部分 ? 每一个方块代表数据包经过的节点，从上面依次看起，第一个是 Process，代表请求从进程发出，到右边第二个节点 eth0@if483，这是容器内部的网卡设备，后边有一个(used: 0.02ms)代表从上一个节点 process 到容器内部网卡花费了 0.02ms。 以此类推，再到右边的 eth0 即为宿主机网卡，并且可以知道从容器网卡到虚拟机网卡花费了 0.02ms。 然后请求从网卡发出，到网卡接收到响应（即为图中所示的向下箭头），花费了 13.37ms，之后就是响应接收的流程，从右往左。 接着容器接收响应花费 0.06ms，再到响应数据复制到 TCP 缓存区花费了 0.06ms，最后进程从缓冲区读取数据花费了 0.11ms。 可以清楚的看到请求从进程发送到网卡，响应再从网卡复制到 Socket 缓冲区并且被进程读取的流程和每一个步骤的耗时。 ## 运行 kyanos 后没有观察到 http 流量? 确认你想监控的协议不是 HTTP2，因为 kyanos 目前尚未支持。 ## 为什么抓取到的请求数量明显少于真实的请求数量？ 在大流量的情况下 kyanos 可能抓取不到完整的请求数据，检查 `/tmp` 目录下的 kyanos 日志，如果出现 `[dataReader] lost xx syscall data events` 的日志说明正是这种情况。 如果想尽可能的抓取请求可以加上 `--trace-dev-event=false --trace-socket-data` 这个选项，加上该选项后不会抓取数据经过网卡和`socket buffer`的事件，将所有处理能力用于解析 syscall 数据上（目前通过 syscall 数据解析请求和响应） ## 运行后终端表格颜色不正确（比如无法选择表格中的记录） 检查是否有 `Your terminal does not support 256 colors, ui may display incorrectly` 日志，如果有说明终端的颜色配置不正确，kyanos 需要 256 色的终端。 使用以下命令即可列出系统所支持的所有终端类型，以及他们支持的颜色位数： ```shell for T in `find /usr/share/terminfo -type f -printf '%f '`;do echo "$T `tput -T $T colors`";done|sort -nk2|tail -n20 ``` 示例输出如下： ```shell Eterm-88color 88 rxvt-88color 88 xterm-88color 88 xterm+88color 88 Eterm-256color 256 gnome-256color 256 iTerm.app 256 konsole-256color 256 ... ``` $TERM变量代表当前终端类型，可使用echo $ TERM 命令查看。 可通过修改~/.bashrc 文件将其改为 256 色，在.bashrc 文件中加入以下代码即可： ```shell case "$TERM" in xterm) export TERM=xterm-256color ;; screen) export TERM=screen-256color ;; esac ``` --- ## File: docs/cn/how-to.md --- next: text: "Watch 使用方法" link: "./watch" prev: false --- # 5 分钟学会使用 kyanos kyanos 共有三个子命令：watch、stat、overview。每个命令的作用如下： 1. watch：根据你指定的条件抓取网络流量并自动解析为请求响应记录。 2. stat：根据你指定的条件抓取请求响应记录并且聚合这些记录，得到更高维度的统计信息。 3. overview：一键展示当前机器依赖的外部资源。 ## `watch` 流量采集简单用法 最简单的用法如下，抓取所有 kyanos 当前能够识别的协议 ```bash ./kyanos watch ``` 每个请求响应记录会记录在表格中的一行，每列记录这个请求的基本信息。你可以通过方向键或者 j/k 上下移动来选择记录： 按下 `enter` 进入详情界面： 详情界面里第一部分是 **耗时详情**，每一个方块代表数据包经过的节点，比如这里有进程、网卡、Socket 缓冲区等。 每个方块下面有一个耗时，这里的耗时指从上个节点到这个节点经过的时间。可以清楚的看到请求从进程发送到网卡，响应再从网卡复制到被进程读取的流程和每一个步骤的耗时。 第二部分是 **请求响应的基本信息**，包含请求响应的开始和结束时间，请求响应的大小等。 第三部分是 **请求响应的具体内容**，分为 Request 和 Response 两部分，超过 1024 字节会截断展示。 抓取流量时一般会更有针对性，比如抓取 HTTP 流量： ```bash ./kyanos watch http ``` 更进一步，你可能只想抓取某个 HTTP Path 的流量： ```bash ./kyanos watch http --path /abc ``` 每种协议都具有不同的过滤条件，而且 watch 还可以根据很多其他条件过滤，详情参考：[如何抓取请求响应和耗时细节](./watch) ## `stat` 聚合分析简单用法 在真实场景中，watch 输出的结果过于细粒度，因此 kyanos 提供了 stat 命令用于 **统计分析**。 简单来说 stat 可以用来回答这些问题：哪些连接的请求数最多？哪些远程服务端上的平均耗时最高？哪些客户端发送的请求带宽占比最高？ 现在让我们来尝试找到哪些远程服务端上的平均耗时最高，我们只需指定 `--slow` 选项代表我们关心的指标是耗时，和 watch 一样，stat 也可以使用所有的过滤条件，这里我们只收集 PATH =/abc 的 HTTP 请求 ： ```bash ./kyanos stat http --slow --path /abc ``` kyanos 默认会收集 10s（可以通过 `--time` 参数指定收集时间，当然，你也可以按下 `ctrl+c` 提前结束收集）： 10s 结束后收集结果展示在表格里： ```js{6-8} Colleted events are here! ┌──────────────────────────────────────────────────────────────────────────────────────────────┐ │ id remote-ip max(ms) avg(ms) p50(ms) p90(ms) p99(ms) count │// [!code focus] │──────────────────────────────────────────────────────────────────────────────────────────────│ │ 0 169.254.0.4 108.59 60.36 64.00 128.00 128.00 3 │// [!code focus] │ 1 180.101.50.242 11.56 11.56 16.00 16.00 16.00 1 │ │ 2 180.101.50.188 11.98 11.51 13.33 16.00 16.00 3 │ │ │ │ │ │ │ └──────────────────────────────────────────────────────────────────────────────────────────────┘ ↑/k up • ↓/j down 1 sort by name • 2 sort by max • 3 sort by avg • 4 sort by p50 • 5 sort by p90 • 6 sort by p99 • 7 sort by count • 8 sort by total ``` watch 展示的每一行是一次请求响应，而 stat 会按照某个维度聚合请求响应。 在这个例子中没有指定，默认采用 **请求的服务端地址（remote-ip）** 作为聚合维度（第二列就是聚合维度列），相同远程服务 IP 的请求响应结果会聚合起来（当然不止这一种聚合方式，了解更多请参考：[流量分析](./stat)）。 后面的 `max` 列就是这些相同 remote-ip 的请求响应中的最大耗时，`avg` 就是平均耗时等等。所以如果某个远程服务端出现了异常，你可以很快的通过比对不同 remote-ip 的指标发现异常的服务端是 169.254.0.4。 如果想查看这个 remote-ip 上的请求响应的详细信息，可以移动到这行记录上按下 `enter`，进入这个 remote-ip 上的请求响应列表中： ```js Events Num: 3 ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ id Process Connection Proto TotalTime↓ ReqSize RespSize Net/Internal ReadSocketTime │// [! code focus] │───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────│ │ 1 1315398 10.0.4.9:38458 => 169.254.0.4:80 HTTP 108.59 564 216 107.18 1.36 │// [! code focus] │ 2 1315398 10.0.4.9:38482 => 169.254.0.4:80 HTTP 45.89 676 216 43.83 2.00 │// [! code focus] │ 3 1315398 10.0.4.9:38470 => 169.254.0.4:80 HTTP 26.60 588 216 25.21 1.30 │ │ │ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ ↑/k up • ↓/j down ``` 这里实际和 watch 命令展示的结果是相同的形式，每一行代表请求响应记录，之后你可以通过 `enter` 继续选择你感兴趣的一行记录，查看它的耗时细节和具体内容。 > [!TIP] > > stat 的功能十分强大，推荐你阅读：[如何聚合分析](./stat) > 查看 stat 命令的其它用法。 ## 下一步 了解每个命令的详细使用方法： - watch 命令请查看：[如何抓取请求响应和耗时细节](./watch) - stat 命令请查看：[如何聚合分析](./stat) --- ## File: docs/cn/how-to-add-a-new-protocol.md # 如何为 kyanos 贡献新的协议 ## 背景 kyanos 需要捕获协议消息组成请求响应对以供终端展示，因此 kyanos 需要每个协议的协议解析代码，目前支持 HTTP、Redis、MySQL、RocketMQ、Kafka、MongoDB 和 DNS，将来会支持更多。本文将阐述 kyanos 协议解析的整体架构，以协助开发新的协议。 ## 协议解析流程总览 从左边看起，kyanos 在 read、write 等系统调用上插桩，获取应用进程读写的数据，将其通过 perf event buffer 发送到用户空间。 用户空间则根据这个连接是客户端侧还是服务端侧，分别放到 reqStreamBuffer 或者 respStreamBuffer 里。这些数据是单纯的应用协议数据，没有协议头。 kyanos 会使用相应协议的解析器解析放到 streamBuffer 的数据，然后关联解析后的请求和响应，最后根据协议的需要再进行 Full Body 解析，生成一个“记录”（record）。 ## 一些术语 Message：协议的最基本数据单元，通常有一个 header 和 body。 Request / Response: 请求或响应由一起发送的一个或多个 Message 组成，这些 Message 在一起表示一个消息（_Note: 对于简单的协议比如 HTTP1.1 来说，一个 Request/Response 可能只对应一个 Message，但对于像 MySQL 这种复杂的协议，多个 Message 组合起来才对应一个 Request/Response_） Record：Record 代表一个匹配完成的请求响应对。 ## Step.0-准备工作 我们需要做以下几个事情： 1. 实现用户态协议解析 1. 定义协议消息类型（即请求和响应的结构） 2. 实现一个 `Parser`, 具体来说需要实现 `ProtocolStreamParser` 接口，该接口实现了协议解析和请求响应匹配等的具体逻辑。 2. 实现内核态的协议推断逻辑。 3. 增加命令行子命令，实现过滤逻辑。 4. 增加 e2e 测试。 ## Step.1-定义协议消息类型 在/agent/protocol 目录下新建一个目录，名称为协议名称，例如：kafka。 ### 定义 Message 一般来说，你要实现的协议会存在一个通用的 Header，这个 Header 会包含一些元数据，比如一个标志位记录其是请求还是响应，像这些信息你需要存储到你定义的 Message 的字段里，比如 MySQL 协议定义的： ```go type MysqlPacket struct { FrameBase seqId byte msg string cmd int isReq bool } ``` 一般来说，Message 或者下面的 Request/Response 都需要嵌入一个 FrameBase，FrameBase 定义如下，包含了一些基本信息： ```go type FrameBase struct { timestampNs uint64 byteSize int seq uint64 } ``` 而对于 HTTP 等简单的协议来说，由于其一个 Message 就对应一个请求或响应，没有必要进行 Full Body 解析，因此也就没必要定义一个 Message 了，直接定义 Request 和 Response 就可以。 ### 定义请求和响应 请求和响应在 Message 的上层，由一个或多个 Message 组成。`struct Request` 或 `struct Response` 应包含特定于请求/响应的数据, 并且应该实现 ParsedMessage 接口，接口定义如下： ```go type ParsedMessage interface { FormatToString() string FormatToSummaryString() string TimestampNs() uint64 ByteSize() int IsReq() bool Seq() uint64 StreamId() StreamId } ``` | 方法名 | 作用 | | ------------------ | -------------------------------------------------------------------------- | | `FormatToString()` | 将消息格式化为字符串表示形式。 | | `TimestampNs()` | 返回消息的时间戳（以纳秒为单位）。 | | `ByteSize()` | 返回消息的字节大小。 | | `IsReq()` | 判断消息是否为请求。 | | `Seq()` | 返回消息的字节流序列号, 可以从 `streamBuffer.Head().LeftBoundary()` 获取。 | | `StreamId()` | 返回消息的 StreamId, 一般的协议可以直接返回 0，用于 HTTP2 这种多路复用的协议。 | HTTP 的例子： ```go type ParsedHttpRequest struct { FrameBase Path string Host string Method string buf []byte } ``` > Note. 在 `protocol.BinaryDecoder` 中 `BinaryDecoder` > 类提供了一些方便的实用程序函数，用于从缓冲区中提取字符、字符串或整数。在下面的实现 ParseFrame、FindFrameBoundary 和 Full > Body 解析时，我们应该使用这些函数。 ## Step.2-实现协议解析 定义好请求响应类型之后，就可以开始实现解析流程了，具体来说需要实现接口：`ProtocolStreamParser` ```go type ProtocolStreamParser interface { ParseStream(streamBuffer *buffer.StreamBuffer, messageType MessageType) ParseResult FindBoundary(streamBuffer *buffer.StreamBuffer, messageType MessageType, startPos int) int Match(reqStream *ParsedMessageQueue, respStream *ParsedMessageQueue) []Record } ``` - ParseStream: 解析 Message - FindBoundary: 寻找 Message 边界 - Match: ReqResp 匹配 - Full Body Parse(可选): Full Body 解析 ### ParseStream (Buffer -> Message/ReqResp) ParseStream 从网络数据解析出来 Message 或者直接解析出来 ReqResp。 ```go ParseStream(streamBuffer *buffer.StreamBuffer, messageType MessageType) ParseResult ``` 注意 eBPF 数据事件可能会无序到达，或者丢失事件，因此数据缓冲区中的数据可能缺少数据块，参数 streamBuffer 中通过 `streamBuffer.Head` 函数获取到目前为止已接收到的缓冲区前面的所有连续数据。因此，此时 **无法保证数据有效或缓冲区与数据包的开头对齐**。 如果返回 `ParseResult` 中的 `state` 为 `success`，且那么 kyanos 会自动删除掉 `ParseResult.ReadBytes` 个字节的数据；如果返回 `invalid`，那么通过 `FindBoundary` 找到下一个可能的 `Message` 边界；如果返回 `needsMoreData`，则不会删除数据，而是稍后重试。 ### FindBoundary 寻找 Message 边界 FindBoundary 寻找 Message 边界，然后从解析失败状态中恢复。 ```go FindBoundary(streamBuffer *buffer.StreamBuffer, messageType MessageType, startPos int) int ``` conntrack.go 在一个循环中调用 ParseStream 和 FindBoundary，如果 ParseStream 返回 invalid，说明解析遇到了问题，接着会调用 FindBoundary 找到下一个位置，这个位置一般是 Message 的开头。如果请求带有一个 tag 比如 request id，那么响应带有相同 request id 的可能性非常高。 ### Match (Messages -> reqresp -> record) ParseStream 解析成功的 Message 会放到对应的 ReqQueue 和 RespQueue 中，然后再它们匹配在一起创建 Record，主要有两种匹配方法：基于顺序 和 基于标签。 HTTP 等协议使用顺序匹配，而 Kafka 等协议使用基于标签的匹配。 Note: 如果是使用顺序匹配，可以直接使用 `matchByTimestamp`。 ### Full Body Parsing 解析整个消息 目前，Full Body Parsing 是 Match 的一部分。对于大多数协议，我们如果需要解析整个消息体，只有在请求响应匹配之后才可以，比如 Kafka 需要知道请求的 opcode，然后才可以根据 opcode 解析响应。 ## Step.3-实现协议推断 在将内核数据抓取到用户态解析之前，我们需要识别出这个流量是什么协议的流量，当连接开启上面有数据传输时，kyanos 会基于一些规则判断该流量术语哪种协议，每个协议有自己的规则，HTTP 协议如下： ```c static __always_inline enum message_type_t is_http_protocol(const char *old_buf, size_t count) { if (count < 5) { return 0; } char buf[4] = {}; bpf_probe_read_user(buf, 4, old_buf); if (buf[0] == 'H' && buf[1] == 'T' && buf[2] == 'T' && buf[3] == 'P') { return kResponse; } if (buf[0] == 'G' && buf[1] == 'E' && buf[2] == 'T') { return kRequest; } if (buf[0] == 'H' && buf[1] == 'E' && buf[2] == 'A' && buf[3] == 'D') { return kRequest; } if (buf[0] == 'P' && buf[1] == 'O' && buf[2] == 'S' && buf[3] == 'T') { return kRequest; } return kUnknown; } ``` Warn: 1. 新协议的规则可能会导致误报或漏报，导致影响其他协议的准确性。 2. 规则的顺序很重要。 3. 不要在最终的 eBPF 代码中出现字符串字面量，例如使用 `bpf_printk` 打印日志（如果你在调试当然允许），低版本的内核不支持 出于这些原因，你需要注意以下几个事情： 1. 避免在协议中使用过于通用和常见的模式作为推理规则。例如，根据单独的 `0x00` 或 `0x01` 的字节判断就不够严格。 2. 将更严格、更健壮的规则（例如 HTTP）放在前面。 ## Step.4-添加命令行子命令并且实现过滤逻辑 需要添加到 watch 和 stat 命令下，增加需要的协议特定的过滤选项。 然后实现 `protocol.ProtocolFilter`： ```go type ProtocolFilter interface { Filter(req ParsedMessage, resp ParsedMessage) bool FilterByProtocol(bpf.AgentTrafficProtocolT) bool FilterByRequest() bool FilterByResponse() bool } ``` | 方法名 | 作用 | | ------------------ | -------------------------- | | `Filter` | 过滤请求和响应。 | | `FilterByProtocol` | 是否根据协议类型进行过滤。 | | `FilterByRequest` | 是否根据请求进行过滤。 | | `FilterByResponse` | 是否根据响应进行过滤。 | 另外需要在 `cmd/watch.go` 里的 `supportedProtocols` 需要添加对应的协议名称。 ## Step.5-注册协议解析器 在你写的模块下增加 init 函数，将其写入到 `ParsersMap` 里，例如： ```go func init() { ParsersMap[bpf.AgentTrafficProtocolTKProtocolHTTP] = func() ProtocolStreamParser { return &HTTPStreamParser{} } } ``` 最后在 `bpf/common.go` 里的 `ProtocolNamesMap` 增加对应的协议名称翻译。 ## Step.6-添加测试 ### 添加 e2e 测试 在 testdata 目录下添加对应协议的 e2e 测试，可以参考其他协议的写法（比如 `test_redis.sh` 等）。 然后在 ./github/workflows/test.yml 中添加你的测试步骤： ```yaml - name: Your Test name uses: cilium/little-vm-helper@97c89f004bd0ab4caeacfe92ebc956e13e362e6b # v0.0.19 with: provision: 'false' cmd: | set -ex uname -a cat /etc/issue if [ -f "/var/lib/kyanos/btf/current.btf" ]; then bash /host/testdata/YOUR_TEST_SCRIPT.sh 'sudo /host/kyanos/kyanos $kyanos_log_option --btf /var/lib/kyanos/btf/current.btf' else bash /host/testdata/YOUR_TEST_SCRIPT.sh 'sudo /host/kyanos/kyanos $kyanos_log_option' fi ``` 💡 Hint: 一开始可以将你的测试放在 workflow 的前面，这样能很快执行到你的测试，便于发现问题。 ### 添加协议解析单元测试 给你的 `ProtoclParser` 的三个 function 添加单元测试，模拟对应协议的输入 case 完成测试。 ## 其他 ### 调试建议 打印协议解析日志建议使用 `common.ProtocolParserLog`. 打开 protocol 解析日志：`--protocol-log-level 5` 设置协议解析相关 log 日志为 debug 级别。 协议解析框架代码在 conntrack.go 的 `addDataToBufferAndTryParse` 函数里。 更多调试建议参考：[Debug Tips](./debug-tips) ### 协议解析持久化信息 在某些协议中，如果需要在解析过程中保留一些数据（比如 kafka 中，它存储了请求缓冲区上看到的所有 correlation_id 的集合，而 FindBoundary 只返回 respStreamBuffer 上之前看到 correlation_id 的位置。）可以在协议的 Parser 里自定义一些变量保存（即 Parser 可以是有状态的），**kyanos 会为每个连接开启时创建独立的 Parser 并保持到连接关闭**。 ## 总结 恭喜你成功向 Kyanos 添加新协议！由于你的贡献，新的协议解析器将使许多其他人受益！ --- ## File: docs/cn/how-to-build.md --- next: false prev: false --- # 编译步骤 本文介绍 kyanos 的本地编译方法，我的环境是 ubuntu 22.04，其他环境可能会有所不同。 ## 工具版本要求 - golang 1.23 以上 - clang 10.0 以上 - llvm 10.0 以上 ## 编译环境依赖安装 ### Ubuntu 如果你使用的是 ubuntu 20.04 以及更新版本，可以使用一条命令即可完成编译环境的初始化。 ``` /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/hengyoush/kyanos/refs/heads/main/init_env.sh)" ``` ### 其他 Linux 发行版 用下面的命令 clone 项目: ```bash git clone https://github.com/hengyoush/kyanos cd kyanos git submodule update --init --recursive ``` 编译环境除了上面工具链版本列出的软件外，还需要以下软件，请自行安装。 - linux-tools-common - linux-tools-generic - pkgconf - libelf-dev ## 编译命令 如果只是本地开发测试，可以执行 ```bash make build-bpf && make ``` 之后在项目根目录下会生成 kyanos 可执行文件。 格式化代码 ```bash make format ``` 格式化文档 ```bash make format-md ``` > [!IMPORTANT] > > 但是需要注意的是该二进制文件中没有包含 > [btfhub-archive](https://github.com/aquasecurity/btfhub-archive/) > 中的 btf 文件，如果直接拿这个 kyanos 去没有开启 BTF 支持的低版本内核上执行可能会启动失败，通过下面的命令可以构建出一个内嵌 btf 文件的 kyanos 产物： > > ::: code-group > > ```bash [x86_64] > make build-bpf && make btfgen BUILD_ARCH=x86_64 ARCH_BPF_NAME=x86 && make > ``` > > ```bash [arm64] > make build-bpf && make btfgen BUILD_ARCH=arm64 ARCH_BPF_NAME=arm64 && make > ``` > > ::: > > 需要注意 `make btfgen` 耗时可能超过 15min。 > [!TIP] > > 如果你的内核没有开启 BTF，你可能无法成功启动 kyanos. > > 检查是否开启 BTF： > > ``` > grep CONFIG_DEBUG_INFO_BTF "/boot/config-$(uname -r)" > ``` > > 如果结果是 `CONFIG_DEBUG_INFO_BTF=y` 说明开启了，如果没开启请到 > [mirrors.openanolis.cn](https://mirrors.openanolis.cn/coolbpf/btf/) or > [btfhub-archive](https://github.com/aquasecurity/btfhub-archive/) > 上下载对应你的内核版本的 btf 文件，然后启动 kyanos 时使用 `--btf` > 选项指定下载的 btf 文件。 --- ## File: docs/cn/index.md --- # https://vitepress.dev/reference/default-theme-home-page layout: home hero: name: "Kyanos" text: "A Simple & Powerful Network Tracing Tool" tagline: 秒级分析定位网络问题 image: src: /kyanos.png alt: Kyanos actions: - theme: brand text: What is Kyanos? link: ./what-is-kyanos - theme: alt text: Quickstart link: ./quickstart - theme: alt text: Star me at Github! link: https://github.com/hengyoush/kyanos features: - icon: 🚀 title: 使用简单 details: 聚焦于7层协议，只需一条命令即可快速查看应用的网络性能，包括 HTTP、Redis、MySQL、Kafka、MongoDB、RocketMQ、DNS 等服务的网络延迟和数据传输大小 link: ./how-to linkText: Learn how to use kyanos - icon: 🎯️ title: 高级数据过滤 details: 支持根据协议字段（如HTTP的Path或Redis的Command）过滤数据，以及根据进程PID、容器ID、K8s Pod名称等多维度筛选数据，提供更精确的问题定位。 link: ./watch#how-to-filter linkText: Learn how to filter traffic - icon: 📈️ title: 强大的聚合分析 details: 支持根据远程IP、协议等维度自动聚合数据，快速获取特定信息，如特定IP的HTTP路径耗时情况。 link: ./stat linkText: Learn how to analysis traffic - icon: 💻️ title: 容器网络监控 details: 在容器化环境中，能够统计数据包从容器网卡到宿主机网卡的耗时。 link: ./watch#filter-by-container linkText: Capture container traffic - icon: 📊️ title: 直观的用户界面 details: 基于命令行就地分析，提供可视化的输出，无需复杂的文件下载和分析步骤。 link: ./how-to linkText: Learn how to use kyanos - icon: 🌐️ title: 轻量级与兼容性 details: Kyanos作为一个网络问题排查工具，不依赖于任何外部依赖，能够在从3.10版本到最新版本的内核上运行 link: ./quickstart#prerequire linkText: Install kyanos --- --- ## File: docs/cn/json-output.md # JSON 输出格式 本文档描述了使用 kyanos 的 `--json-output` 参数时的 JSON 输出格式。 ## 使用方法 使用 `--json-output` 参数输出 JSON 格式数据，可以指定以下值： ```bash # 输出到终端 kyanos watch --json-output=stdout # 输出到文件 kyanos watch --json-output=/path/to/custom.json ``` ## 输出格式 每个请求-响应对都表示为一个 JSON 对象，包含以下字段： ### 时间信息 | 字段 | 类型 | 描述 | | ----------------------------------- | ------ | ---------------------------------------------------------------------------------------------------------------- | | `start_time` | string | 请求开始时间，RFC3339Nano 格式 | | `end_time` | string | 请求结束时间，RFC3339Nano 格式 | | `total_duration_ms` | number | 请求-响应总耗时，单位毫秒 | | `black_box_duration_ms` | number | 对于客户端：请求离开和响应到达网络接口之间的持续时间 对于服务器端：请求到达进程和响应离开进程之间的持续时间 | | `read_socket_duration_ms` | number | 从 socket 缓冲区读取数据的耗时 | | `copy_to_socket_buffer_duration_ms` | number | 复制数据到 socket 缓冲区的耗时 | ### 连接信息 | 字段 | 类型 | 描述 | | ------------- | ------- | --------------------------------------- | | `protocol` | string | 协议名称（如 "HTTP"、"Redis"、"MySQL"、"RocketMQ"、"Kafka"、"MongoDB"、"DNS"） | | `side` | string | 连接的角色（客户端或服务端） | | `local_addr` | string | 本地 IP 地址 | | `local_port` | number | 本地端口号 | | `remote_addr` | string | 远程 IP 地址 | | `remote_port` | number | 远程端口号 | | `pid` | number | 进程 ID | | `is_ssl` | boolean | 是否是 SSL/TLS 加密连接 | ### 内容信息 | 字段 | 类型 | 描述 | | ---------------------------- | ------ | ---------------------- | | `req_size_bytes` | number | 请求总大小，单位字节 | | `resp_size_bytes` | number | 响应总大小，单位字节 | | `req_plain_text_size_bytes` | number | 请求明文大小，单位字节 | | `resp_plain_text_size_bytes` | number | 响应明文大小，单位字节 | | `request` | string | 格式化后的请求内容 | | `response` | string | 格式化后的响应内容 | ### 事件详情 | 字段 | 类型 | 描述 | | --------------------- | ----- | ---------------------- | | `req_syscall_events` | array | 请求相关的系统调用事件 | | `resp_syscall_events` | array | 响应相关的系统调用事件 | | `req_nic_events` | array | 请求相关的网卡事件 | | `resp_nic_events` | array | 响应相关的网卡事件 | ## 示例 ```json { "start_time": "2024-01-01T12:00:00.123456789Z", "end_time": "2024-01-01T12:00:00.234567890Z", "protocol": "HTTP", "side": "client", "local_addr": "127.0.0.1", "local_port": 54321, "remote_addr": "192.168.1.1", "remote_port": 80, "pid": 12345, "is_ssl": false, "total_duration_ms": 111.111111, "black_box_duration_ms": 50.505050, "read_socket_duration_ms": 30.303030, "copy_to_socket_buffer_duration_ms": 20.202020, "req_size_bytes": 256, "resp_size_bytes": 1024, "req_plain_text_size_bytes": 256, "resp_plain_text_size_bytes": 1024, "request": "GET /api/v1/users HTTP/1.1\r\nHost: example.com\r\n\r\n", "response": "HTTP/1.1 200 OK\r\nContent-Type: application/json\r\n\r\n{\"status\":\"success\"}", "req_syscall_events": [...], "resp_syscall_events": [...], "req_nic_events": [...], "resp_nic_events": [...] } ``` --- ## File: docs/cn/quickstart.md --- prev: text: "Kyanos 是什么" link: "./what-is-kyanos" next: false --- # 快速开始 ## 安装要求 **内核版本要求** For amd64: - 3.x: 3.10.0-957 版本及以上内核 - 4.x: 4.14 版本以上内核 - 5.x, 6.x: 全部支持 For arm64: - 5.5 以上 ## 安装并运行 {#prerequire} 你可以从 [release page](https://github.com/hengyoush/kyanos/releases) 中下载以静态链接方式编译的适用于 amd64 和 arm64 架构的二进制文件： ```bash tar xvf kyanos_vx.x.x_linux_amd64.tar.gz ``` 然后以 **root** 权限执行如下命令： ```bash sudo ./kyanos watch ``` 如果显示了下面的表格： 🎉 恭喜你，kyanos 启动成功了。 > [!TIP] > > 如果上面的命令执行失败了？没关系，在这个 [FAQ](./faq) > 里看看有没有符合你的情况，如果没有欢迎提出 > [github issue](https://github.com/hengyoush/kyanos/issues) ! ## 常见问题 请查看：[常见问题](./faq) ## 下一步 - 快速了解 kyanos 的使用方法，请查看：[5 分钟学会使用 kyanos](./how-to) --- ## File: docs/cn/stat.md --- next: false prev: text: "Watch 使用方法" link: "./watch" --- # 使用 stat 统计分析异常流量 watch 命令提供了细粒度的观察视角，在分析单个请求响应维度的问题上十分有用。然而考虑到一些问题场景： - 我的 HTTP 请求慢了，是所有服务端都慢了，还是某一个服务端慢了？ - 有人对我负责的 Redis 发送 get 请求，导致机器带宽被占满，是哪一个客户端 ip 造成的？ stat 命令用于解决这种需要分析大量请求响应才能得出结论的问题。 ## 如何使用 stat 命令 使用 stat 命令非常简单，你只需要确定 **你关心的指标是什么？** 以上述的这个问题为例："我的 HTTP 请求慢了，是所有服务端都慢了，还是某一个服务端慢了？"，在这里我们关心的是 **服务端的响应时间** 这个指标。 所以可以输入如下的命令： ```bash ./kyanos stat --metric total-time --group-by remote-ip ``` 指定 `metric` 选项为 `total-time` 代表我们需要统计的指标是请求响应的总耗时，指定 `group-by` 选项为 `remote-ip` ，代表我们需要观察的响应时间是每个 `remote-ip` 的响应时间，kyanos 会将所有相同 `remote-ip` 的请求响应聚合，最终得出每个 `remote-ip` 的总耗时的相关指标。 一个更简短的命令形式： ```bash ./kyanos stat -m t -g remote-ip ``` m 是 metric 的缩写，t 是 total-time 的缩写，g 是 group-by 的缩写。 > [!TIP] > > **如何过滤流量？** > stat 支持所有 watch 命令的过滤选项。 ## 如何分析 stat 命令的结果 如下是输入上述 stat 命令后你会看到的表格： 就像 watch 表格的操作方式一样：你可以通过按下数字键对对应的列排序，也可以按 `"↑"` `"↓"` 或者 `"k"` `"j"` 可以上下移动选择表格中的记录。 但和 watch 表格不同的是表格里的记录，stat 命令是将所有请求响应按照 `--group-by` 选项聚合的，所以第二列的名称是 `remote-ip`，其后各列：`max`、`avg`、`p50` 等列表示 `--metric` 选项所指定指标（在我们这个例子中指 `total-time` ）的最大值、平均值和 P50 等值。 按下 `enter` 即可进入这个 `remote-ip` 下具体的请求响应，这里其实就是 watch 命令的结果，操作方式和 watch 完全相同，你可以选择具体的请求响应，然后查看其耗时和请求响应内容，这里不再赘述。 ## 目前支持的指标 kyanos 目前支持通过 `--metric` 指定的指标如下： | 观测指标 | short flag | long flag | | :------------------------- | :--------- | :------------ | | 总耗时 | t | total-time | | 响应数据大小 | p | respsize | | 请求数据大小 | q | reqsize | | 在网络中的耗时 | n | network-time | | 在服务进程中的耗时 | i | internal-time | | 从 Socket 缓冲区读取的耗时 | s | socket-time | ## 目前支持的聚合方式 kyanos 目前支持通过 `--group-by` 指定的指标如下： | 聚合维度 | 值 | | :----------------- | :------------ | | 聚合到单个连接 | conn | | 远程 ip | remote-ip | | 远程端口 | remote-port | | 本地端口 | local-port | | L7 协议 | protocol | | HTTP PATH | http-path | | Redis 命令 | redis-command | | 聚合所有的请求响应 | none | ## 这些选项记不住怎么办？ 如果你记不得这些选项，stat 同样提供了三个选项用于快速分析： - slow：分析慢请求。 - bigreq：分析大请求。 - bigresp：分析大响应。 同时可以通过 `--time` 选项指定收集时间，如 `--time 10`，stat 命令会收集流量 10s： 等收集结束或者按下 ctrl+c 提前结束，会出现如下的表格： 之后的操作方式就相同了。 ### 分析慢请求 抓取 10s 内的流量，快速找到哪一个远程 ip 的 HTTP 请求最慢： ```bash ./kyanos stat http --slow --time 10 ``` ### 分析大请求和大响应 快速找到哪一个远程 ip 的请求最大： ```bash ./kyanos stat http --bigreq ``` 快速找到哪一个远程 ip 的响应最大： ```bash ./kyanos stat http --bigresp ``` --- METRICS --- - Files Extracted: 11 - Estimated Token Budget: ~9932 tokens - Recency Window: Active (< 180 days) - Canonical Reference: https://codewiki.google/github.com/hengyoush/kyanos