LitmusChaos 混沌实验分布式追踪提案解读：用 OpenTelemetry 与 Jaeger 定位混沌注入的性能瓶颈-北京尧图网络

云原生运维可观测性【免费下载链接】litmusLitmus helps SREs and developers practice chaos engineering in a Cloud-native way. Chaos experiments are published at the ChaosHub (https://hub.litmuschaos.io). Community notes is at https://hackmd.io/a4Zu_sH4TZGeih-xCimi3Q项目地址https://gitcode.com/gh_mirrors/li/litmus点击查看免费下载本文基于 LitmusChaos 开源仓库中的技术提案 proposals/distributed-tracing-for-chaos-experiments.md详细解读其提出的为 chaos-operator、chaos-runner 及所有混沌实验组件接入 OpenTelemetry SDK并以 Jaeger 可视化实验步骤的方案。读完本文你将理解混沌实验为何需要从监控指标升级到分布式追踪、Kubernetes 环境下 trace context 传递的特殊难点以及该方案如何做到不改变现有 API 与实验结构的非破坏性演进。背景与动机为什么可度量还不够LitmusChaos 一直信奉一句经典工程格言You cant manage what you dont 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。换句话说这是一次纯增量的可观测性增强所有既有功能与接口均保持兼容。使用场景两类核心用户提案从用户视角描述了两种典型使用场景LitmusChaos 普通用户作为用户我希望了解混沌实验中正在发生什么以便追踪实验的性能表现。例如当一次 Pod 删除实验整体耗时异常偏高时能够在追踪视图中按步骤排查是哪一段注入、校验或恢复逻辑产生了延迟。开源开发者作为开发者我希望知道性能问题发生在混沌实验的哪个环节从而定位并修复问题。分布式追踪把原本散落在多个 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提案作者为此制作了一个最小验证 demoasync-trace。其架构如图所示demo 的架构演示了两种容器父容器parent container负责通过 docker client API 创建子容器并在创建子容器时把自身持有的 trace context 写入子容器的环境变量子容器child container启动后从环境变量中读取 trace context并带着该上下文向 Jaeger 上报自己的 span。两个容器都使用 OpenTelemetry SDK 发送各自的 trace contextOpenTelemetry 会把这两段上下文识别为同一条 trace从而在 Jaeger 中呈现为完整的父子调用链。这个 demo 验证了核心思路的可行性在无法通过请求头传播上下文的环境里环境变量完全可以作为 trace context 的传播载体OpenTelemetry 规范社区也专门讨论过将环境变量作为进程间传播载体这一议题参见提案的 References 部分。提案的实施计划基于上述验证提案给出了明确的实施路线为 chaos-operator 添加 OpenTelemetry SDK为所有参与混沌实验执行的组件添加 OpenTelemetry SDK通过环境变量把 trace context 传递给子容器即后续实验步骤各组件将 trace context 上报到 OpenTelemetry Collector在 Jaeger 中可视化混沌实验的各个步骤将使用文档补充到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:4317otlphttp/prometheus导出器把指标写入 Prometheus连接器spanmetrics把 span 数据转化为指标实现追踪反哺指标管道编排traces 管道经过 memory_limiter、resource、transform、batch 处理后导出到 Jaeger 与 spanmetricsmetrics 管道汇总后写入 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 清单明确列出了四个待合并的改动入口组件实现 PR合并状态chaos-runnerchaos-runner PR #221未合并chaos-operatorchaos-operator PR #498未合并litmus-golitmus-go PR #706未合并chaos centerlitmus PR #4746未合并从清单可以看出该提案计划覆盖从执行平面chaos-operator、chaos-runner到故障注入库litmus-go再到控制面chaos center的完整链路四个 PR 均标注为未合并状态。对希望跟进或贡献该特性的开发者来说这是一个很好的切入点对使用 LitmusChaos 的 SRE 与开发者而言理解这份提案的设计思路也有助于提前规划自身集群的可观测性方案——在追踪能力正式合入之前即可先借助 monitoring 下的现有监控体系与 Otel-demo 教程建立混沌实验的观测基线。赞分享云原生运维可观测性【免费下载链接】litmusLitmus helps SREs and developers practice chaos engineering in a Cloud-native way. Chaos experiments are published at the ChaosHub (https://hub.litmuschaos.io). Community notes is at https://hackmd.io/a4Zu_sH4TZGeih-xCimi3Q项目地址https://gitcode.com/gh_mirrors/li/litmus点击查看免费下载相关推荐noteForOpenGL 法线映射Normal MappingTBN坐标系与低模凹凸细节增强实战noteForOpenGL 法线映射Normal MappingTBN坐标系与低模凹凸细节增强实战本文基于 OpenGL 学习笔记项目 noteForOpe示例工程osv.dev分布式追踪Jaeger集成与性能瓶颈定位osv.dev分布式追踪Jaeger集成与性能瓶颈定位项目背景与追踪需求 osv.dev作为开源漏洞数据库和分类服务其分布式架构包含API服务、索引器、工使用 LitmusChaos 与 OpenTelemetry 观测混沌实验Otel-demo 实战教程使用 LitmusChaos 与 OpenTelemetry 观测混沌实验Otel demo 实战教程导读本教程基于 litmus 仓库的 monitor云原生运维可观测性上一篇TypeSpec 编译器性能报告与 Emitter 性能插桩完全指南下一篇korean-scholarship-search 学校级奖学金发现方法论基于 k-skill 的 *.ac.kr 全量探测检查清单创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

LitmusChaos 混沌实验分布式追踪提案解读：用 OpenTelemetry 与 Jaeger 定位混沌注入的性能瓶颈

相关推荐

UE4 C++设计模式实战：用Actor、Component和状态机重构玩法代码

密码学基本理论

水务环保数字化转型的路径是什么？盈链生态工业互联网平台五大阶段详解

更多资讯

职场心理博弈漫画创作指南

华为OD机试真题精讲：机场航班调度程序（Python/Java/C++多语言实现）

Archify：架构即代码的开源实践与商业化路径

多智能体协作新范式：基于信息素网络的去中心化上下文管理

用分形几何驯服AI音乐：一场数学建模专家的实测手记

租房数据采集与可视化平台：Python爬虫+Flask+Layui+ECharts实战

今日更新

声子晶体仿真：三角晶格与六角晶格的能带计算实战

度假村安保定岗定编：岗位梳理、编制测算与排班设计

COMSOL等离子体模块实战：氩气双层DBD仿真建模全解析

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？