How ChaosLab's components divide the work of turning a controlled failure into a provable recovery-correctness verdict.
Parses and evaluates declarative recovery-correctness oracles — the business invariants a system must satisfy after recovering from failure.
Gathers raw evidence after an experiment: service logs, database snapshots, and OpenTelemetry traces from the affected services.
Drives Chaos Mesh to schedule and execute controlled fault experiments against the target application, and tracks experiment lifecycle.
Merges evidence from all three upstream components into a single, time-ordered account of what happened across every service.
Evaluates the correlated evidence against the Oracle Engine's invariants and emits a PASS/FAIL recovery-correctness verdict with supporting evidence.
The entry point users and the future dashboard talk to — triggers experiments, and exposes verdicts and evidence for review.
ChaosLab doesn't reimplement any of these — it orchestrates and reads from them.
| System | Role |
|---|---|
| Chaos Mesh | Executes the controlled fault (pod kill, network partition, latency injection) inside the Kubernetes cluster. |
| Online Boutique | The target distributed microservices application under test. |
| Database | Source of ground-truth persisted business state, queried post-recovery. |
| Logs | Per-service structured logs collected as raw evidence. |
| OpenTelemetry | Distributed tracing used to reconstruct the cross-service request path during recovery. |