云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载Kata Containers 的 agent 运行在虚拟机VM内部无法直接向宿主机的追踪收集器上报 OpenTelemetry 链路数据。本文聚焦 src/tools/trace-forwarder 目录下的kata-trace-forwarder组件讲解它如何作为宿主机侧的转发器通过 VSOCK 通道接收 VM 内 agent 产生的 trace span并以 OTLP 协议导出到 OpenTelemetry 兼容收集器。读完本文你将掌握该组件的运行原理、QEMU / Cloud Hypervisor / Firecracker 三种 hypervisor 下的启动方式、OTLP 端点与 Kata 配置文件的联动配置以及完整的 CLI 参数与排障要点。组件定位宿主机上的 Agent 追踪摆渡人Kata Containers 运行时runtime和 agent 都能生成 OpenTelemetry trace span用于观察各组件的行为与耗时。运行时运行在宿主机环境可以直连宿主机上的 trace collector但 agent 运行在 VM 内部与 collector 不在同一上下文中无法直接上报。kata-trace-forwarder正是为解决这一隔离问题而设计的组件它运行在宿主机上与 collector 处于同一上下文必须在容器sandbox启动之前启动通过VSOCK通道监听 VM 内 agent 发出的 trace 数据再使用 OpenTelemetry ProtocolOTLP把 span 导出到默认运行在宿主机上的 OpenTelemetry 兼容收集器。整体架构如下参考 docs/tracing.md 的架构说明-------------------------------------------- | Host | | | | --------------- | | | OpenTelemetry | | | | Trace | | | | Collector | | | --------------- | | ^ --------------- | | | spans | Kata VM | | | ---------- | | | | | Kata | spans o ------- | | | | Trace |-----------------| Kata | | | | | Forwarder | VSOCK o | Agent | | | | ----------- Channel | ------- | | | --------------- | --------------------------------------------说明这种设计无需修改 guest 镜像即可支持 agent 追踪自定义镜像osbuilder 构建的镜像同样能受益。工作原理VSOCK 通道与头-负载帧协议追踪链路分为两端VM 内agent 侧agent 通过vsock-exporter源码见 src/agent/vsock-exporter/src/lib.rs把 trace span 发送给 forwarder。它默认连接 CID 为VMADDR_CID_HOST宿主机、端口为10240源码中的DEFAULT_PORT并采用最简单的帧协议先是 8 字节HEADER_SIZE_BYTES size_of::u64()的头部用大端序NetworkEndian::write_u64编码后续 payload 的字节数然后才是序列化后的 span 数据见write_span实现。宿主机forwarder 侧forwarder 在 VSOCK 端口上监听handler.rs 中同样以 8 字节头部解析出 payload 长度再完整读取 payload从而逐条消费来自 agent 的 span。注释明确要求头部大小常量必须与 agent 侧vsock-exporter中同名变量的值保持一致。两种 VSOCK 模式的差异决定了运行方式该对照表也内置于--help的长帮助文本中见 main.rsHypervisorVSOCK 类型forwarder 运行身份Cloud Hypervisor (CLH)Firecracker Hybrid宿主机内核之外的本地 UNIX socket需要 rootQEMUStandard宿主机内核原生 vsock普通用户即可Firecracker (FC)Firecracker Hybrid需要 root其中Hybrid VSOCK的实现细节值得注意forwarder 传入的master socket路径本身并不会被直接使用而是以该路径为前缀、追加_{端口号}后缀生成真正与 agent 通信的 socket 路径。这一逻辑实现在 utils.rs 的make_hybrid_socket_path中例如/run/vc/vm/foo/clh.sock加端口后变为/run/vc/vm/foo/clh.sock_10240并有对应的单元测试验证。部署前置条件内核与模块要求宿主机内核需支持 VSOCKCONFIG_VHOST_VSOCK并加载内核模块sudo modprobe vhost_vsockguest 内核需支持 VSOCKCONFIG_VIRTIO_VSOCKETSKata Containers 默认 guest 内核已内置该特性。追踪收集器必须先启动必须有一个OTLP 兼容的 trace collector在运行。forwarder 启动前若 collector 未运行forwarder 会报错退出。常用收集器包括Jaegerv1.35、OpenTelemetry Collector、Grafana Tempo。测试时最快捷的方式是运行 Jaeger 的 all-in-one 镜像并确保其在 4317gRPC或 4318HTTP端口接收 OTLP 数据。在 Kata 配置文件中启用 agent 追踪以 QEMU 配置模板 configuration-qemu.toml.in 为例[agent.PROJECT_TYPE]段下的enable_tracing默认关闭[agent.kata] # Enable agent tracing. # (default: disabled) enable_tracing true同样地若要追踪运行时本身可在[runtime]段开启configuration-qemu.toml.in[runtime] enable_tracing true注意开启该选项只对之后启动的容器生效若同时开启 runtime 与 agent 追踪生成的 span 会被拼接collated在 collector Web UI 中展开某个 runtime span 即可看到对应的 agent span。快速开始按以下四步即可完成一次 agent 追踪的部署启动一个 OTLP 兼容收集器如 Jaeger v1.35、OpenTelemetry Collector 或 Grafana Tempo以合适的 OTLP 端点启动 trace forwarder在 Kata 配置文件中启用 agent 追踪[agent.kata]段的enable_tracing true照常创建 Kata 容器。说明若已启用 agent 追踪但 forwarder 未运行agent 会记录一条错误日志提示无法生成 trace span但容器本身仍能正常工作。OTLP 端点配置forwarder 把 span 发送到 OTLP 端点默认值为http://localhost:4317gRPC该默认值定义在 main.rs 的DEFAULT_OTLP_ENDPOINT常量中。如需指定其他端点使用--otlp-endpoint参数kata-trace-forwarder --otlp-endpoint http://my-collector:4317常见 OTLP 端点收集器端点Jaegerv1.35http://localhost:4317gRPC或http://localhost:4318HTTPOpenTelemetry Collectorhttp://localhost:4317gRPC或http://localhost:4318HTTPGrafana Tempo取决于其配置在 tracer.rs 的create_otlp_trace_exporter中可以看到导出器的构建方式使用opentelemetry-otlp的 tonic 实现gRPC创建SpanExporter并通过SdkTracerProvider::with_batch_exporter以批量方式导出资源属性包含service.name默认kata-agent与exporterotlp。根据 hypervisor 选择运行方式先确认 Kata 配置的 hypervisor查看配置文件或直接运行kata-runtime env --json | jq .Hypervisor.PathQEMU标准 VSOCK默认参数直接运行QEMU 以标准方式支持 VSOCK socket因此使用默认选项即可。在 src/tools/trace-forwarder 目录下运行cargo run随后照常创建 Kata 容器即可无需额外参数或特权。Cloud Hypervisor / FirecrackerHybrid VSOCK需指定 UNIX socket 路径CLH 与 Firecracker 都使用 hybrid VSOCK——通过本地 UNIX socket而非宿主机内核与 guest 通信因此必须指定 UNIX socket 路径。由于 forwarder 必须在 VMsandbox启动前运行而 socket 路径与具体 sandbox 绑定需要先用env命令确定模板路径该路径包含代表真实 sandbox ID/名称的{ID}占位符。配置的 hypervisor 为 Cloud Hypervisor 时$ socket_path_template$(sudo kata-runtime env --json | jq .Hypervisor.SocketPath) $ echo $socket_path_template /run/vc/vm/{ID}/clh.sock配置的 hypervisor 为 Firecracker 时$ socket_path_template$(sudo kata-runtime env --json | jq .Hypervisor.SocketPath) $ echo $socket_path_template /run/vc/firecracker/{ID}/root/kata.hvsock注意不要依赖上面展示的路径——请务必自行运行命令获取因为这些路径可能发生变化。得到模板路径后按以下顺序操作。构建与安装QEMU 场景无需此步骤CLH / Firecracker 场景下先安装好工具会更方便。构建make安装cargo install --path . sudo install -o root -g root -m 0755 ~/.cargo/bin/kata-trace-forwarder /usr/local/binmake对应 Makefile 中的构建目标实际执行的是cargo build -p kata-trace-forwarder。创建 sandbox 目录将下面的sandbox_id变量改成你计划在启动 forwarder 之后创建的容器sandbox名称sandbox_idfoo socket_path$(echo $socket_path_template | sed s/{ID}/${sandbox_id}/g | tr -d ) sudo mkdir -p $(dirname $socket_path)sed用于把模板中的{ID}替换成真实 sandbox IDtr -d 用于去除env --json输出中 JSON 字符串的引号。以 socket 路径启动 forwardersudo kata-trace-forwarder --socket-path $socket_path启动完成后即可照常创建名为 foo 的 Kata 容器。注意因为 forwarder 需要在 sandbox 目录中创建 socket而该目录归root用户所有所以 hybrid VSOCK 场景下 forwarder 也必须以root身份运行。这是 hybrid VSOCK 独有的要求——QEMU 场景下运行 forwarder 不需要任何特殊权限。为了降低影响forwarder 启动绑定 socket后会立即降权以nobody用户继续运行。特权模型root 启动与 nobody 降权该行为在 server.rs 中有完整实现NON_PRIV_USER常量定义为nobody见 server.rsstart_hybrid_vsock首先检查当前进程是否为 rootUid::effective().is_root()否则报 You need to be root删除可能残留的 socket 文件后通过UnixListener::bind(socket_path)绑定绑定成功后立即调用drop_privsdrop_privs先把工作目录切换到/再通过privdropcrate 的PrivDrop::default().user(nobody).apply()降权见 server.rs标准 VSOCK 路径则直接以VsockListener::bind(SockAddr::new_vsock(cid, port))监听无需特权。完整 CLI 参数参考除--otlp-endpoint外main.rs 还定义了以下参数运行cargo run -- --help可查看完整帮助参数默认值说明--otlp-endpointhttp://localhost:4317OTLP 端点 URLgRPC--trace-namekata-agent为 trace 指定的名称不可为空--socket-path无hypervisor socket 的完整路径仅 CLH / Firecracker需要 root--vsock-cidanyVSOCK CID 数字或any仅 QEMUany对应内核常量VMADDR_CID_ANY--vsock-port10240VSOCK 端口号仅 QEMUhybrid 模式下作为 socket 路径后缀不可为 0--log-level/-linfo日志级别支持运行时修改--dump-only关闭不转发 span而是写入 stdout用于测试其中 VSOCK 端口默认值10240必须与 agent 侧vsock-exporter的DEFAULT_PORTsrc/agent/vsock-exporter/src/lib.rs保持一致否则两侧无法建立连接。--vsock-cid、--vsock-port的解析与校验空值、非数字、端口为 0 等错误场景在 utils.rs 中有完整实现与单元测试覆盖。--help中还内置了三种 hypervisor 的示例after_help文本# QEMU $ kata-trace-forwarder --trace-name kata-agent # Cloud Hypervisorsandbox 名称 foo $ sandbox_idfoo $ sudo kata-trace-forwarder --trace-name kata-agent --socket-path /run/vc/vm/foo/clh.sock # Firecrackersandbox 名称 foo $ sandbox_idfoo $ sudo kata-trace-forwarder --trace-name kata-agent --socket-path /run/vc/firecracker/foo/root/kata.hvsock测试与调试运行单元测试make test对应 Makefile 中的cargo test -p kata-trace-forwarder -- --nocapture测试覆盖了 hybrid / standard VSOCK 参数解析、端口与 CID 校验、socket 路径拼接等逻辑。使用--dump-only模式forwarder 不再把 span 导出到 collector而是把收到的原始字节打印到 stdout便于在无收集器环境下验证 VM 内 agent 是否能成功发送数据。从当前仓库源码看handler.rshandler 在读取 payload 后存在一处已知的状态限制由于 OpenTelemetry 0.27 的SpanData不再实现Deserialize非 dump 模式下 forwarder 会输出一条警告提示 agent 与 forwarder 的 OpenTelemetry 版本可能不兼容dump 模式则仅记录接收字节数。使用该组件时建议留意此警告与两侧依赖版本的一致性。注意事项与常见问题collector 必须先于 forwarder 启动若收集器未运行forwarder 会直接报错退出。forwarder 未运行时 agent 不受影响agent 追踪开启但 forwarder 未运行时agent 仅记录错误日志正常工作不受阻。不要硬编码 socket 路径CLH / Firecracker 的 socket 模板路径以kata-runtime env --json的实际输出为准示例路径可能随版本变化。混合 VSOCK 必须用 root 启动但绑定 socket 后 forwarder 会自动降权为nobody无需常驻特权进程。追踪完成时机agent 的 trace 事务只有在 workload 与 agent 进程都退出后才算完成可参考 docs/tracing.md 的说明若 workload 仍在运行collector 中可能看到trace-without-root-span的不完整展示需等待 workload 结束或停止容器后再查看完整 trace。关闭行为变化agent 追踪开启后VM 关闭改由 agent 负责以确保所有 trace 事务完成容器关闭耗时会有轻微增加。配置只对后续容器生效修改enable_tracing后只有之后启动的容器才会带追踪能力。综上kata-trace-forwarder是打通VM 内 agent → 宿主机收集器追踪链路的关键组件。理解其 VSOCK 双模式与特权模型按 hypervisor 选择正确的启动参数即可快速为 Kata Containers 的 agent 建立完整的可观测性。赞分享云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载相关推荐Kata Containers 追踪Tracing设计提案解析从 Agent 静态追踪到 Trace Forwarder 采集架构Kata Containers 追踪Tracing设计提案解析从 Agent 静态追踪到 Trace Forwarder 采集架构 导读 本文以 Kata云原生容器运行时Kata Containers Tracing 全解析基于 OpenTelemetry 实现 Runtime 与 Guest Agent 的全链路追踪Kata Containers Tracing 全解析基于 OpenTelemetry 实现 Runtime 与 Guest Agent 的全链路追踪 Kat云原生容器运行时Kata Containers 与 AWS Firecracker 集成指南配置、部署与验证Kata Containers 与 AWS Firecracker 集成指南配置、部署与验证 本篇技术指南围绕 Kata Containers 官方文档中关于云原生容器运行时上一篇ctf-wiki Android 逆向指南Smali 语法与 Dalvik 字节码指令全解下一篇Alchemy 2.0.0-beta.63 实战指南Durable Object 跨 Worker 数据迁移、Action 资源绑定与全局 CLI 登录创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kata Containers Agent 链路追踪实战：kata-trace-forwarder 部署与配置指南
云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载Kata Containers 的 agent 运行在虚拟机VM内部无法直接向宿主机的追踪收集器上报 OpenTelemetry 链路数据。本文聚焦 src/tools/trace-forwarder 目录下的kata-trace-forwarder组件讲解它如何作为宿主机侧的转发器通过 VSOCK 通道接收 VM 内 agent 产生的 trace span并以 OTLP 协议导出到 OpenTelemetry 兼容收集器。读完本文你将掌握该组件的运行原理、QEMU / Cloud Hypervisor / Firecracker 三种 hypervisor 下的启动方式、OTLP 端点与 Kata 配置文件的联动配置以及完整的 CLI 参数与排障要点。组件定位宿主机上的 Agent 追踪摆渡人Kata Containers 运行时runtime和 agent 都能生成 OpenTelemetry trace span用于观察各组件的行为与耗时。运行时运行在宿主机环境可以直连宿主机上的 trace collector但 agent 运行在 VM 内部与 collector 不在同一上下文中无法直接上报。kata-trace-forwarder正是为解决这一隔离问题而设计的组件它运行在宿主机上与 collector 处于同一上下文必须在容器sandbox启动之前启动通过VSOCK通道监听 VM 内 agent 发出的 trace 数据再使用 OpenTelemetry ProtocolOTLP把 span 导出到默认运行在宿主机上的 OpenTelemetry 兼容收集器。整体架构如下参考 docs/tracing.md 的架构说明-------------------------------------------- | Host | | | | --------------- | | | OpenTelemetry | | | | Trace | | | | Collector | | | --------------- | | ^ --------------- | | | spans | Kata VM | | | ---------- | | | | | Kata | spans o ------- | | | | Trace |-----------------| Kata | | | | | Forwarder | VSOCK o | Agent | | | | ----------- Channel | ------- | | | --------------- | --------------------------------------------说明这种设计无需修改 guest 镜像即可支持 agent 追踪自定义镜像osbuilder 构建的镜像同样能受益。工作原理VSOCK 通道与头-负载帧协议追踪链路分为两端VM 内agent 侧agent 通过vsock-exporter源码见 src/agent/vsock-exporter/src/lib.rs把 trace span 发送给 forwarder。它默认连接 CID 为VMADDR_CID_HOST宿主机、端口为10240源码中的DEFAULT_PORT并采用最简单的帧协议先是 8 字节HEADER_SIZE_BYTES size_of::u64()的头部用大端序NetworkEndian::write_u64编码后续 payload 的字节数然后才是序列化后的 span 数据见write_span实现。宿主机forwarder 侧forwarder 在 VSOCK 端口上监听handler.rs 中同样以 8 字节头部解析出 payload 长度再完整读取 payload从而逐条消费来自 agent 的 span。注释明确要求头部大小常量必须与 agent 侧vsock-exporter中同名变量的值保持一致。两种 VSOCK 模式的差异决定了运行方式该对照表也内置于--help的长帮助文本中见 main.rsHypervisorVSOCK 类型forwarder 运行身份Cloud Hypervisor (CLH)Firecracker Hybrid宿主机内核之外的本地 UNIX socket需要 rootQEMUStandard宿主机内核原生 vsock普通用户即可Firecracker (FC)Firecracker Hybrid需要 root其中Hybrid VSOCK的实现细节值得注意forwarder 传入的master socket路径本身并不会被直接使用而是以该路径为前缀、追加_{端口号}后缀生成真正与 agent 通信的 socket 路径。这一逻辑实现在 utils.rs 的make_hybrid_socket_path中例如/run/vc/vm/foo/clh.sock加端口后变为/run/vc/vm/foo/clh.sock_10240并有对应的单元测试验证。部署前置条件内核与模块要求宿主机内核需支持 VSOCKCONFIG_VHOST_VSOCK并加载内核模块sudo modprobe vhost_vsockguest 内核需支持 VSOCKCONFIG_VIRTIO_VSOCKETSKata Containers 默认 guest 内核已内置该特性。追踪收集器必须先启动必须有一个OTLP 兼容的 trace collector在运行。forwarder 启动前若 collector 未运行forwarder 会报错退出。常用收集器包括Jaegerv1.35、OpenTelemetry Collector、Grafana Tempo。测试时最快捷的方式是运行 Jaeger 的 all-in-one 镜像并确保其在 4317gRPC或 4318HTTP端口接收 OTLP 数据。在 Kata 配置文件中启用 agent 追踪以 QEMU 配置模板 configuration-qemu.toml.in 为例[agent.PROJECT_TYPE]段下的enable_tracing默认关闭[agent.kata] # Enable agent tracing. # (default: disabled) enable_tracing true同样地若要追踪运行时本身可在[runtime]段开启configuration-qemu.toml.in[runtime] enable_tracing true注意开启该选项只对之后启动的容器生效若同时开启 runtime 与 agent 追踪生成的 span 会被拼接collated在 collector Web UI 中展开某个 runtime span 即可看到对应的 agent span。快速开始按以下四步即可完成一次 agent 追踪的部署启动一个 OTLP 兼容收集器如 Jaeger v1.35、OpenTelemetry Collector 或 Grafana Tempo以合适的 OTLP 端点启动 trace forwarder在 Kata 配置文件中启用 agent 追踪[agent.kata]段的enable_tracing true照常创建 Kata 容器。说明若已启用 agent 追踪但 forwarder 未运行agent 会记录一条错误日志提示无法生成 trace span但容器本身仍能正常工作。OTLP 端点配置forwarder 把 span 发送到 OTLP 端点默认值为http://localhost:4317gRPC该默认值定义在 main.rs 的DEFAULT_OTLP_ENDPOINT常量中。如需指定其他端点使用--otlp-endpoint参数kata-trace-forwarder --otlp-endpoint http://my-collector:4317常见 OTLP 端点收集器端点Jaegerv1.35http://localhost:4317gRPC或http://localhost:4318HTTPOpenTelemetry Collectorhttp://localhost:4317gRPC或http://localhost:4318HTTPGrafana Tempo取决于其配置在 tracer.rs 的create_otlp_trace_exporter中可以看到导出器的构建方式使用opentelemetry-otlp的 tonic 实现gRPC创建SpanExporter并通过SdkTracerProvider::with_batch_exporter以批量方式导出资源属性包含service.name默认kata-agent与exporterotlp。根据 hypervisor 选择运行方式先确认 Kata 配置的 hypervisor查看配置文件或直接运行kata-runtime env --json | jq .Hypervisor.PathQEMU标准 VSOCK默认参数直接运行QEMU 以标准方式支持 VSOCK socket因此使用默认选项即可。在 src/tools/trace-forwarder 目录下运行cargo run随后照常创建 Kata 容器即可无需额外参数或特权。Cloud Hypervisor / FirecrackerHybrid VSOCK需指定 UNIX socket 路径CLH 与 Firecracker 都使用 hybrid VSOCK——通过本地 UNIX socket而非宿主机内核与 guest 通信因此必须指定 UNIX socket 路径。由于 forwarder 必须在 VMsandbox启动前运行而 socket 路径与具体 sandbox 绑定需要先用env命令确定模板路径该路径包含代表真实 sandbox ID/名称的{ID}占位符。配置的 hypervisor 为 Cloud Hypervisor 时$ socket_path_template$(sudo kata-runtime env --json | jq .Hypervisor.SocketPath) $ echo $socket_path_template /run/vc/vm/{ID}/clh.sock配置的 hypervisor 为 Firecracker 时$ socket_path_template$(sudo kata-runtime env --json | jq .Hypervisor.SocketPath) $ echo $socket_path_template /run/vc/firecracker/{ID}/root/kata.hvsock注意不要依赖上面展示的路径——请务必自行运行命令获取因为这些路径可能发生变化。得到模板路径后按以下顺序操作。构建与安装QEMU 场景无需此步骤CLH / Firecracker 场景下先安装好工具会更方便。构建make安装cargo install --path . sudo install -o root -g root -m 0755 ~/.cargo/bin/kata-trace-forwarder /usr/local/binmake对应 Makefile 中的构建目标实际执行的是cargo build -p kata-trace-forwarder。创建 sandbox 目录将下面的sandbox_id变量改成你计划在启动 forwarder 之后创建的容器sandbox名称sandbox_idfoo socket_path$(echo $socket_path_template | sed s/{ID}/${sandbox_id}/g | tr -d ) sudo mkdir -p $(dirname $socket_path)sed用于把模板中的{ID}替换成真实 sandbox IDtr -d 用于去除env --json输出中 JSON 字符串的引号。以 socket 路径启动 forwardersudo kata-trace-forwarder --socket-path $socket_path启动完成后即可照常创建名为 foo 的 Kata 容器。注意因为 forwarder 需要在 sandbox 目录中创建 socket而该目录归root用户所有所以 hybrid VSOCK 场景下 forwarder 也必须以root身份运行。这是 hybrid VSOCK 独有的要求——QEMU 场景下运行 forwarder 不需要任何特殊权限。为了降低影响forwarder 启动绑定 socket后会立即降权以nobody用户继续运行。特权模型root 启动与 nobody 降权该行为在 server.rs 中有完整实现NON_PRIV_USER常量定义为nobody见 server.rsstart_hybrid_vsock首先检查当前进程是否为 rootUid::effective().is_root()否则报 You need to be root删除可能残留的 socket 文件后通过UnixListener::bind(socket_path)绑定绑定成功后立即调用drop_privsdrop_privs先把工作目录切换到/再通过privdropcrate 的PrivDrop::default().user(nobody).apply()降权见 server.rs标准 VSOCK 路径则直接以VsockListener::bind(SockAddr::new_vsock(cid, port))监听无需特权。完整 CLI 参数参考除--otlp-endpoint外main.rs 还定义了以下参数运行cargo run -- --help可查看完整帮助参数默认值说明--otlp-endpointhttp://localhost:4317OTLP 端点 URLgRPC--trace-namekata-agent为 trace 指定的名称不可为空--socket-path无hypervisor socket 的完整路径仅 CLH / Firecracker需要 root--vsock-cidanyVSOCK CID 数字或any仅 QEMUany对应内核常量VMADDR_CID_ANY--vsock-port10240VSOCK 端口号仅 QEMUhybrid 模式下作为 socket 路径后缀不可为 0--log-level/-linfo日志级别支持运行时修改--dump-only关闭不转发 span而是写入 stdout用于测试其中 VSOCK 端口默认值10240必须与 agent 侧vsock-exporter的DEFAULT_PORTsrc/agent/vsock-exporter/src/lib.rs保持一致否则两侧无法建立连接。--vsock-cid、--vsock-port的解析与校验空值、非数字、端口为 0 等错误场景在 utils.rs 中有完整实现与单元测试覆盖。--help中还内置了三种 hypervisor 的示例after_help文本# QEMU $ kata-trace-forwarder --trace-name kata-agent # Cloud Hypervisorsandbox 名称 foo $ sandbox_idfoo $ sudo kata-trace-forwarder --trace-name kata-agent --socket-path /run/vc/vm/foo/clh.sock # Firecrackersandbox 名称 foo $ sandbox_idfoo $ sudo kata-trace-forwarder --trace-name kata-agent --socket-path /run/vc/firecracker/foo/root/kata.hvsock测试与调试运行单元测试make test对应 Makefile 中的cargo test -p kata-trace-forwarder -- --nocapture测试覆盖了 hybrid / standard VSOCK 参数解析、端口与 CID 校验、socket 路径拼接等逻辑。使用--dump-only模式forwarder 不再把 span 导出到 collector而是把收到的原始字节打印到 stdout便于在无收集器环境下验证 VM 内 agent 是否能成功发送数据。从当前仓库源码看handler.rshandler 在读取 payload 后存在一处已知的状态限制由于 OpenTelemetry 0.27 的SpanData不再实现Deserialize非 dump 模式下 forwarder 会输出一条警告提示 agent 与 forwarder 的 OpenTelemetry 版本可能不兼容dump 模式则仅记录接收字节数。使用该组件时建议留意此警告与两侧依赖版本的一致性。注意事项与常见问题collector 必须先于 forwarder 启动若收集器未运行forwarder 会直接报错退出。forwarder 未运行时 agent 不受影响agent 追踪开启但 forwarder 未运行时agent 仅记录错误日志正常工作不受阻。不要硬编码 socket 路径CLH / Firecracker 的 socket 模板路径以kata-runtime env --json的实际输出为准示例路径可能随版本变化。混合 VSOCK 必须用 root 启动但绑定 socket 后 forwarder 会自动降权为nobody无需常驻特权进程。追踪完成时机agent 的 trace 事务只有在 workload 与 agent 进程都退出后才算完成可参考 docs/tracing.md 的说明若 workload 仍在运行collector 中可能看到trace-without-root-span的不完整展示需等待 workload 结束或停止容器后再查看完整 trace。关闭行为变化agent 追踪开启后VM 关闭改由 agent 负责以确保所有 trace 事务完成容器关闭耗时会有轻微增加。配置只对后续容器生效修改enable_tracing后只有之后启动的容器才会带追踪能力。综上kata-trace-forwarder是打通VM 内 agent → 宿主机收集器追踪链路的关键组件。理解其 VSOCK 双模式与特权模型按 hypervisor 选择正确的启动参数即可快速为 Kata Containers 的 agent 建立完整的可观测性。赞分享云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载相关推荐Kata Containers 追踪Tracing设计提案解析从 Agent 静态追踪到 Trace Forwarder 采集架构Kata Containers 追踪Tracing设计提案解析从 Agent 静态追踪到 Trace Forwarder 采集架构 导读 本文以 Kata云原生容器运行时Kata Containers Tracing 全解析基于 OpenTelemetry 实现 Runtime 与 Guest Agent 的全链路追踪Kata Containers Tracing 全解析基于 OpenTelemetry 实现 Runtime 与 Guest Agent 的全链路追踪 Kat云原生容器运行时Kata Containers 与 AWS Firecracker 集成指南配置、部署与验证Kata Containers 与 AWS Firecracker 集成指南配置、部署与验证 本篇技术指南围绕 Kata Containers 官方文档中关于云原生容器运行时上一篇ctf-wiki Android 逆向指南Smali 语法与 Dalvik 字节码指令全解下一篇Alchemy 2.0.0-beta.63 实战指南Durable Object 跨 Worker 数据迁移、Action 资源绑定与全局 CLI 登录创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考