云原生运维可观测性【免费下载链接】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点击查看免费下载在 Litmus 混沌工程体系中每一次实验的运行状态与最终判定并不写在 ChaosEngine 或 ChaosExperiment 里而是由一个名为ChaosResult的独立自定义资源承载。本文以官方文档 chaos-result/contents.md 为核心系统讲解 ChaosResult 的spec与status字段规范、探针状态记录方式并结合仓库中的 CRD 定义、Go 订阅器与前端 TypeScript 模型说明这份结果数据在 Litmus 控制平面中如何被采集与消费。读完本文你将能完整读懂任意一次混沌实验的 ChaosResult 输出并据此定位实验失败环节。一、ChaosResult 是什么ChaosResult 是 Litmus 实验执行链路中的结果载体。官方文档对其定位概括为Hold engine reference, experiment state, verdict (on complete), salient application/result attributes, sources for metrics collection.即它保存了四类关键信息实验关联的引擎引用engine reference、实验运行状态experiment state、完成时的最终判定verdict、被攻击应用的属性与指标采集来源salient application/result attributes。从仓库中的 CRD 定义可以看到它的资源形态定义位置litmus-portal-crds.ymlAPI Grouplitmuschaos.io版本v1alpha1KindChaosResult复数形式chaosresults单数形式chaosresultScopeNamespaced命名空间级资源spec与status均以x-kubernetes-preserve-unknown-fields: true保留字段保证向后兼容每次实验运行结束后会生成一个以engineName-experimentName命名的 ChaosResult 实例。例如执行engine-nginx引擎下的pod-delete实验对应的结果对象名为engine-nginx-pod-delete。按照官方文档ChaosResult 的字段体系分为三大部分字段分组作用详细说明Spec Specification定义 ChaosResult 的 spec 细节spec-specification.mdStatus Specification定义 ChaosResult 的 status 细节status-specification.mdProbe Specification定义 ChaosResult 中探针组件的结果细节probe-specification.md下文逐一展开。二、spec 规范引擎与实验的关联标识ChaosResult 的spec只做一件事标记本次结果属于哪个引擎、哪个实验。规范定义于 spec-specification.md。字段类型说明.spec.enginestring记录本次实验所属 ChaosEngine 的名称.spec.experimentstring记录注入故障的 ChaosExperiment 名称.spec.engine保存当前实验流程所使用的 ChaosEngine 名称是关联引擎的指针。.spec.experiment保存执行故障注入的 ChaosExperiment 名称是关联实验定义的指针。官方文档给出的完整示例一个典型的pod-delete结果对象Name: engine-nginx-pod-delete Namespace: default Labels: app.kubernetes.io/componentexperiment-job app.kubernetes.io/part-oflitmus app.kubernetes.io/version1.13.8 chaosUIDaa0a0084-f20f-4294-a879-d6df9aba6f9b controller-uid6943c955-0154-4542-8745-de991eb47c61 job-namepod-delete-w4p5op nameengine-nginx-pod-delete Annotations: none API Version: litmuschaos.io/v1alpha1 Kind: ChaosResult Metadata: Creation Timestamp: 2021-09-29T13:28:59Z Generation: 6 Resource Version: 66788 Self Link: /apis/litmuschaos.io/v1alpha1/namespaces/default/chaosresults/engine-nginx-pod-delete UID: fe7f01c8-8118-4761-8ff9-0a87824d863f Spec: # name of the chaosengine Engine: engine-nginx # name of the chaosexperiment Experiment: pod-delete Status: Experiment Status: Fail Step: N/A Phase: Completed Probe Success Percentage: 100 Verdict: Pass History: Failed Runs: 1 Passed Runs: 1 Stopped Runs: 0 Targets: Chaos Status: targeted Kind: deployment Name: hello Events: none注意示例中的两个细节一是对象标签中带有job-namepod-delete-w4p5op说明该结果对象由实验 Job 创建二是Spec区块只有Engine与Experiment两个字段status才是承载运行信息的核心区域。三、status 规范上experimentStatus 实验状态status.experimentStatus记录了实验运行期与收尾期的核心状态规范定义于 status-specification.md共四个字段字段类型取值范围说明.status.experimentStatus.failStepstringn/a实验失败的具体步骤便于快速定位失败环节.status.experimentStatus.phasestringAwaited、Running、Completed、Aborted实验当前所处阶段随执行推进而更新.status.experimentStatus.probeSuccessPercentageint1 到 100探针成功率即成功校验次数与总探针数的比值.status.experimentStatus.verdictstringAwaited、Pass、Fail、Stopped实验最终判定逐字段解读failStep标记实验在哪一步失败是排障的第一入口。若实验未失败则为N/A。phase实验阶段的实时状态。正常情况下按Awaited → Running → Completed推进若实验被中止则为Aborted。probeSuccessPercentage探针成功率的百分比评分。例如总共 1 个探针全部通过则为100。它是 Litmus 判定实验质量的重要量化指标。verdict最终判定。实验进行中为Awaited结束后依据探针与内置检查的结果收敛为Pass或Fail实验被手动停止时为Stopped。官方文档示例节选Status: Experiment Status: # step on which experiment fails Fail Step: N/A # phase of the chaos result Phase: Completed # Success Percentage of the litmus probes Probe Success Percentage: 100 # Verdict of the chaos result Verdict: Pass四、status 规范下history 结果历史与目标信息status.history记录该 ChaosResult 对象维度的累计运行统计与被攻击目标信息。字段如下字段类型取值范围说明.status.history.passedRunsint任意非负整数累计通过Pass的运行次数.status.history.failedRunsint任意非负整数累计失败Fail的运行次数.status.history.stoppedRunsint任意非负整数累计停止Stopped的运行次数.status.history.targets.namestring-被攻击应用目标应用的名称.status.history.targets.kindstring-被攻击应用的资源类型如 deployment.status.history.targets.chaosStatusstringtargeted、injected、reverted混沌注入状态passedRuns/failedRuns/stoppedRuns三个累计计数反映该引擎下同一实验的多次执行结果分布。targets记录本次实验打到了谁——目标应用名称如hello、资源类型如deployment以及混沌状态targeted已锁定目标、injected已注入故障、reverted已回滚恢复。官方文档示例节选History: # fail experiment run count Failed Runs: 1 # passed experiment run count Passed Runs: 1 # stopped experiment run count Stopped Runs: 0 Targets: # status of the chaos Chaos Status: targeted # kind of the application Kind: deployment # name of the application Name: hello五、Probe Specification探针执行结果status.probeStatus记录实验中每个探针在不同模式下的执行结果规范定义于 probe-specification.md。字段如下字段类型取值范围说明.status.probeStatus.namestringn/a实验中所使用探针的名称.status.probeStatus.typestringHTTPProbe、K8sProbe、CmdProbe探针类型.status.probeStatus.status.continuousstringAwaited、Passed、Better Luck Next TimeContinuous 模式下的探针结果.status.probeStatus.status.prechaosstringAwaited、Passed、Better Luck Next TimeSOT 模式测试开始前的探针结果.status.probeStatus.status.postchaosmap[string]stringAwaited、Passed、Better Luck Next TimeEOT 模式测试结束后的探针结果关于探针模式需要结合 litmus-probes.md 理解Litmus 探针是定义在 ChaosEngine 中的可插拔校验实验 Pod 会按探针设定的模式执行这些校验并将其成功与否作为实验判定verdict的必要条件。探针共五种运行模式SOTStart of Test作为故障注入前的预检执行EOTEnd of Test作为故障注入后的后检执行Edge故障注入前后各执行一次Continuous故障注入期间按指定轮询间隔持续执行OnChaos仅在混沌注入的持续时间内按指定间隔执行官方文档给出的探针结果示例一次同时使用了三种探针的实验Probe Status: # name of probe Name: check-frontend-access-url # status of probe Status: Continuous: Passed #Continuous # type of probe Type: HTTPProbe # name of probe Name: check-app-cluster-cr-status # status of probe Status: Post Chaos: Passed #EoT # type of probe Type: K8sProbe # name of probe Name: check-database-integrity # status of probe Status: Post Chaos: Passed #Edge Pre Chaos: Passed # type of probe Type: CmdProbe从示例可以看出三件事HTTPProbe更适合 Continuous 模式持续探测前端访问 URL 可用性K8sProbe常用于 EOT 模式实验结束后校验集群资源状态是否恢复CmdProbe可同时挂载 Pre Chaos 与 Post ChaosEdge 模式例如校验数据库在注入前后的一致性。探针结果取值中的Better Luck Next Time表示该轮探针校验未通过下次好运是 Litmus 对探针失败的固定表述最终 verdict 是否通过取决于探针在这些模式下的综合表现。探针的配置方式以httpProbe的 Continuous 模式为例可在 probe-modes.yaml 中查看完整示例apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: active appinfo: appns: default applabel: appnginx appkind: deployment chaosServiceAccount: pod-delete-sa experiments: - name: pod-delete spec: probe: - name: check-frontend-access-url type: httpProbe httpProbe/inputs: url: url insecureSkipVerify: false responseTimeout: value method: get: criteria: responseCode: response code # modes for the probes # supports: [SOT, EOT, Edge, Continuous, OnChaos] mode: Continuous runProperties: probeTimeout: 5 interval: 2 retry: 1 probePollingInterval: 2其中runProperties中的probeTimeout单次校验超时、interval重试间隔、retry失败重试次数、probePollingInterval连续/OnChaos 模式每轮探测后的等待间隔共同决定了探针的时序行为也直接影响probeSuccessPercentage与最终 verdict 的取值。六、源码印证ChaosResult 在控制平面中的消费链路ChaosResult 不只是给人类排障看的 YAML它还贯穿 Litmus 控制平面的数据链路。从仓库源码可以确认其真实消费方式。1. 订阅器subscriber按engine-experiment命名拉取结果在 chaoscenter/subscriber/pkg/events/util.go 的getChaosData中订阅器通过 litmus 官方 Go client 直接读取 ChaosResultif len(crd.Status.Experiments) 1 { expRes, err : chaosClient.ChaosResults(cd.Namespace).Get(context.Background(), crd.Name-crd.Status.Experiments[0].Name, v1.GetOptions{}) if err ! nil { return cd, err } // annotations sometimes cause failure in gql message escaping expRes.Annotations nil cd.ChaosResult expRes cd.ProbeSuccessPercentage expRes.Status.ExperimentStatus.ProbeSuccessPercentage if expRes.Status.ExperimentStatus.ErrorOutput ! nil { cd.FailStep fmt.Sprintf(%s : %s, expRes.Status.ExperimentStatus.ErrorOutput.ErrorCode, expRes.Status.ExperimentStatus.ErrorOutput.Reason) } cd.ExperimentStatus string(expRes.Status.ExperimentStatus.Phase) }这段代码印证了两个关键事实ChaosResult 的对象名确实为ChaosEngine名-实验名这里拼接为crd.Name - crd.Status.Experiments[0].Name订阅器直接从expRes.Status.ExperimentStatus提取ProbeSuccessPercentage、Phase并读取ErrorOutput错误码 原因拼接为FailStep这些数据最终被打包进事件负载上报给控制平面GraphQL 服务。对应的数据结构定义在 chaoscenter/subscriber/pkg/types/event.goChaosData中携带EngineName、ExperimentName、ExperimentVerdict、ProbeSuccessPercentage、FailStep以及完整的ChaosResult对象指针并定义了Completed、Completed_With_Probe_Failure、Error、Stopped四种故障状态。这与phase/verdict的字段语义一一对应。2. 前端模型TypeScript 侧的字段映射前端用于渲染实验运行详情与 Pipeline 节点的数据模型定义在 chaoscenter/web/src/models/chaosResult.ts与文档字段逐项对应ChaosResultSpecengine、experiment与.spec.engine/.spec.experiment对应ResultPhaseRunning | Completed | StoppedResultVerdictPass | Fail | Stopped | AwaitedProbeVerdictPassed | Failed | N/A | NA | AwaitedChaosResultStatusexperimentStatus含phase、verdict、probeSuccessPercentage、failureOutput、probeStatuses[]含name、type、mode、status、historypassedRuns、failedRuns、stoppedRuns、targets[]TargetDetailsname、kind、chaosStatus。可见从 K8s CRD 到 Go 后端再到前端 TS 模型ChaosResult 的字段体系始终保持一致这也是它在 Web 控制台ChaosCenter中能直接展示实验通过率、失败步骤与目标信息的原因。七、如何查看与使用 ChaosResult由于 ChaosResult 是标准 Kubernetes CRD可直接通过kubectl查看# 查看命名空间下所有 ChaosResult kubectl get chaosresults # 查看特定结果对象的完整 YAML含 spec 与 status kubectl get chaosresult engine-nginx-pod-delete -n default -o yaml # 关注关键字段verdict、phase、probeSuccessPercentage kubectl get chaosresult engine-nginx-pod-delete -n default -o jsonpath{.status.experimentStatus}需要说明的是读取 ChaosResult 需要相应的 RBAC 权限。在各类实验的安装清单如 ebs-loss-by-id.md 的 RBAC 示例中ServiceAccount 通常被授予对chaosengines、chaosexperiments、chaosresults三类资源的 CRUD 权限即resources: [chaosengines,chaosexperiments,chaosresults]实际排障时建议按以下顺序阅读结果对象看spec.engine/spec.experiment确认结果对象属于哪次实验看status.experimentStatus.verdict与phase确认实验是 Pass / Fail 还是被 Stopped / Aborted若为 Fail看failStep以及源码中提到的errorOutput的错误码与原因定位失败环节看probeSuccessPercentage与status.probeStatus确认是哪个探针、哪个模式Pre/Post/Continuous未通过最后看history.targets确认被攻击的目标应用及其混沌状态targeted / injected / reverted。八、总结ChaosResult 是 Litmus 混沌实验的成绩单spec用engine与experiment两个字段锚定结果归属status.experimentStatus用phase、verdict、probeSuccessPercentage、failStep四个字段回答实验处于什么阶段、结果如何、探针通过率多少、失败在哪一步status.history累计多次运行的通过/失败/停止次数并记录目标应用status.probeStatus则按 SOT / EOT / Edge / Continuous / OnChaos 五种模式分别记录每个探针的执行结果。理解这些字段是使用kubectl排查实验失败、接入 CI/CD 断言结果以及阅读 ChaosCenter 前端展示数据的共同基础。建议继续阅读同目录下的 spec-specification.md、status-specification.md、probe-specification.md 三份规范原文并结合 litmus-probes.md 理解探针模式对结果判定的影响从而形成对 Litmus 实验结果体系的完整认知。赞分享云原生运维可观测性【免费下载链接】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点击查看免费下载相关推荐Elsa Core Shell Reload API 数据模型详解实体定义、验证规则与状态转换Elsa Core Shell Reload API 数据模型详解实体定义、验证规则与状态转换 本指南基于 Elsa Core 仓库中 001 shell r后端工作流自动化流程编排低代码Tendermint Core 协议核心规范详解数据结构、编码、创世文件与状态验证Tendermint Core 协议核心规范详解数据结构、编码、创世文件与状态验证 本文以 Tendermint 仓库中 spec/core/readme.m区块链共识算法MCProtocolLib数据包编解码原理深入理解Minecraft协议序列化机制MCProtocolLib数据包编解码原理深入理解Minecraft协议序列化机制 MCProtocolLib是一个强大的Java库专门用于与Minecra创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考