• 云原生
• 运维
• 可观测性

本文基于 LitmusChaos 开源仓库中的技术提案 proposals/distributed-tracing-for-chaos-experiments.md，详细解读其提出的"为 chaos-operator、chaos-runner 及所有混沌实验组件接入 OpenTelemetry SDK，并以 Jaeger 可视化实验步骤"的方案。读完本文，你将理解混沌实验为何需要从监控指标升级到分布式追踪、Kubernetes 环境下 trace context 传递的特殊难点，以及该方案如何做到不改变现有 API 与实验结构的非破坏性演进。

背景与动机：为什么"可度量"还不够

LitmusChaos 一直信奉一句经典工程格言："You can't manage what you don't measure"（无法度量，就无法管理）。围绕这一理念，项目早已通过暴露/metrics端点提供了一整套混沌监控能力，仓库中的 monitoring 目录就集中存放了混沌相关的 Grafana 仪表盘、Prometheus 部署工具与监控教程，例如：

• Node-and-pod-metrics-dashboard.json 等混沌交织型 Grafana 仪表盘；
• utils 下的 Prometheus、Grafana、chaos-exporter、各类 metrics exporter 及其 service monitor 部署清单；
• chaos-exporter 读取 ChaosResult 并以 Prometheus 指标形式暴露实验结果的执行链路。

然而，指标只能回答"系统状态如何"，却难以回答"一个混沌实验为什么慢、慢在哪一步"。一次混沌实验的完整生命周期中，会有大量 Pod 被创建、运行并销毁：workflow-controller 调度工作流、chaos-operator 调和 ChaosEngine、chaos-runner 编排实验步骤、各类探针（probes）做稳态校验、chaos-exporter 采集结果。这些组件各自独立运行，一旦出现性能问题，你无法知道究竟是哪个 Pod、哪个环节在拖慢实验，也就难以定位与排障。

分布式追踪（distributed tracing）正是为解决这一问题而生：它能够精确定位故障发生在哪一环、性能劣化的根因是什么，是调试和理解复杂系统的基础工具。该提案的构思深受 Tekton 社区《Distributed Tracing for Tasks and Pipelines》提案的启发，目标是把这一能力引入混沌实验的执行链路。

目标与边界：做什么，不做什么

提案对本次工作划定了清晰的范围。

目标（Goals）：

• 将 OpenTelemetry SDK 引入 chaos-operator、chaos-runner 以及所有参与混沌实验执行的组件；
• 实现基于 Jaeger 的 OpenTelemetry 链路追踪；
• 能够在 Jaeger 中可视化混沌实验的各个步骤；
• 将相关使用文档补充到monitoring目录与 Litmus 官方文档中。

非目标（Non-Goals）：

• 不改变现有的混沌实验结构；
• 不改变现有的监控指标（/metrics体系保持不变）；
• 不改变现有的 API。

换句话说，这是一次"纯增量"的可观测性增强，所有既有功能与接口均保持兼容。

使用场景：两类核心用户

提案从用户视角描述了两种典型使用场景：

1. LitmusChaos 普通用户：作为用户，我希望了解混沌实验中正在发生什么，以便追踪实验的性能表现。例如当一次 Pod 删除实验整体耗时异常偏高时，能够在追踪视图中按步骤排查是哪一段注入、校验或恢复逻辑产生了延迟。
2. 开源开发者：作为开发者，我希望知道性能问题发生在混沌实验的哪个环节，从而定位并修复问题。分布式追踪把原本散落在多个 Pod 中的执行日志串联成一条完整的链路，显著降低问题排查成本。

实现细节：Kubernetes 环境下 trace context 的传递难题

常规思路为何失效

在常规的分布式系统里，各组件之间通过 HTTP 或 gRPC 通信，因此可以直接把 trace context 写入**请求头（request header）**进行传播，这也是 OpenTelemetry 上下文传播（context propagation）的标准做法。

但混沌实验的执行链路不走这条路径：chaos-operator、chaos-runner 与各类辅助容器之间，主要通过Kubernetes API 创建资源来协作，组件之间没有直接的 HTTP/gRPC 调用可供"搭车"。因此，提案必须寻找请求头之外的 trace context 传递方式。

Demo 验证：通过环境变量传递 trace context

提案作者为此制作了一个最小验证 demo（async-trace）。其架构如图所示：

demo 的架构演示了两种容器：

• 父容器（parent container）：负责通过 docker client API 创建子容器，并在创建子容器时把自身持有的 trace context 写入子容器的环境变量；
• 子容器（child container）：启动后从环境变量中读取 trace context，并带着该上下文向 Jaeger 上报自己的 span。

两个容器都使用 OpenTelemetry SDK 发送各自的 trace context，OpenTelemetry 会把这两段上下文识别为同一条 trace，从而在 Jaeger 中呈现为完整的父子调用链。

这个 demo 验证了核心思路的可行性：在无法通过请求头传播上下文的环境里，环境变量完全可以作为 trace context 的传播载体（OpenTelemetry 规范社区也专门讨论过"将环境变量作为进程间传播载体"这一议题，参见提案的 References 部分）。

提案的实施计划

基于上述验证，提案给出了明确的实施路线：

1. 为 chaos-operator 添加 OpenTelemetry SDK；
2. 为所有参与混沌实验执行的组件添加 OpenTelemetry SDK；
3. 通过环境变量把 trace context 传递给子容器（即后续实验步骤）；
4. 各组件将 trace context 上报到 OpenTelemetry Collector；
5. 在 Jaeger 中可视化混沌实验的各个步骤；
6. 将使用文档补充到monitoring目录与 Litmus 文档。

预期效果：Jaeger 中的混沌实验链路

实施完成后，一次混沌实验的执行步骤将在 Jaeger 中呈现为类似下图的可视化链路：

从图中可以看到，原本分散在 operator、runner、探针等多个组件中的执行记录，被按时间与调用关系组织成一条可逐段下钻的 trace：每个 span 对应实验的一个步骤（如创建 runner、执行故障注入、运行探针校验、收集结果），任一步骤出现耗时异常或失败都能被一眼定位。

风险与缓解：追踪带来的额外开销

OpenTelemetry SDK 在上报数据的同时会执行额外的序列化、批处理与网络发送任务，理论上会引入一定的延迟开销。对此，提案给出的缓解策略简单而直接：追踪功能对终端用户完全可选。

如果用户禁用追踪，或未配置正确的追踪后端地址，各调和器（reconciler）将照常工作，行为与未接入前完全一致。因此，整个方案可以被归类为非破坏性变更（non-breaking change）。

兼容性与升级 / 降级策略

提案明确指出：API 保持不变，启用追踪完全是终端用户的可选项，这从架构上保证了升级过程的安全性。对于升级 / 降级策略、已知缺点与替代方案，提案正文目前尚留白，属于待后续实现与讨论阶段补充的内容——这从侧面说明该提案仍处于早期设计状态，读者在评估时可以关注后续实现 PR 的进展。

仓库中的可观测性实践佐证

虽然该提案尚在推进中，但仓库中已有的相关实践能够帮助读者理解其落地后的形态。

现有监控体系：指标与追踪互补

monitoring/README.md 展示了 Litmus 现有的监控基础设施：部署 Prometheus TSDB（支持 scrape 配置模型与 service monitor / Prometheus operator 模型两种方式）、安装 node-exporter / kube-state-metrics 等指标导出器、在未接入控制面 agent 的集群中单独部署 chaos-exporter，最后用 Grafana 汇总呈现节点与 Pod 指标。这套体系解决的是"资源与实验结果的度量"，而提案所补足的则是"实验内部步骤的追踪"，两者互为补充。

Otel-demo 教程：OpenTelemetry 观测混沌的完整闭环

仓库中的 monitoring/tutorials/otel-demo/README.md 提供了一份端到端教程：在 Kubernetes 集群中安装 Litmus、通过 Helm 部署 OpenTelemetry Demo（包含微服务、OpenTelemetry Collector、Prometheus、Jaeger、Grafana、OpenSearch 等），然后对 cart-service 注入 Pod 网络延迟、对 recommendation-service 执行 Pod 删除实验，最后在 Grafana/Jaeger 中观测效果。

其中 custom_otel_demo_values.yml 展示了 OpenTelemetry Collector 的典型配置形态，正是提案实施计划中"将 trace context 上报到 Collector"的具体参考：

• 接收端：通过otlp接收器（HTTP 协议）接收 SDK 上报的 trace，并额外配置prometheus接收器抓取chaos-exporter.litmus.svc.cluster.local:8080的指标；
• 导出端：otlp导出器把 trace 以 OTLP 格式发送到jaeger:4317，otlphttp/prometheus导出器把指标写入 Prometheus；
• 连接器：spanmetrics把 span 数据转化为指标，实现"追踪反哺指标"；
• 管道编排：traces 管道经过 memory_limiter、resource、transform、batch 处理后导出到 Jaeger 与 spanmetrics，metrics 管道汇总后写入 Prometheus。

教程中 cart-service/README.md 还示范了如何利用 span 派生的指标编写 Prometheus 探针查询（例如以histogram_quantile计算 cart 服务 99 分位延迟），并用它作为混沌实验的稳态校验探针——这正是"用追踪能力服务混沌实验验证"的实战样例。

控制面依赖：OpenTelemetry 组件已进入技术栈

从 chaoscenter/graphql/server/go.sum 可以看到，控制面服务已引入go.opentelemetry.io/otel、otel/sdk、otel/trace、otel/metric等 v1.44.0 系列依赖（含otel/auto/sdk自动插桩能力），说明 OpenTelemetry 生态已被项目正式纳入技术栈，为提案中"在 Go 组件中接入 OpenTelemetry SDK"提供了现成的依赖基础。同时，chaoscenter/manifests/litmus-installation.yaml 中的INFRA_DEPLOYMENTS环境变量列出了 agent 侧需要部署与监控的组件（chaos-exporter、chaos-operator、workflow-controller、event-tracker），这些正是提案所说"参与混沌实验执行的组件"的构成范围。

提案现状与后续跟踪

提案末尾附有实现 PR 清单，明确列出了四个待合并的改动入口：

从清单可以看出，该提案计划覆盖从执行平面（chaos-operator、chaos-runner）到故障注入库（litmus-go）再到控制面（chaos center）的完整链路，四个 PR 均标注为未合并状态。对希望跟进或贡献该特性的开发者来说，这是一个很好的切入点；对使用 LitmusChaos 的 SRE 与开发者而言，理解这份提案的设计思路，也有助于提前规划自身集群的可观测性方案——在追踪能力正式合入之前，即可先借助 monitoring 下的现有监控体系与 Otel-demo 教程 建立混沌实验的观测基线。

• 云原生
• 运维
• 可观测性