Repurposing OpenTelemetry Traces as Test Data: Breaking the Cost Barrier in System…
summary
Repurposes OpenTelemetry traces as ground-truth test fixtures and demonstrates a PoC migration from Java to Go where PoC: Java→Go, 4 CRUD endpoints, E2E tests driven by spans; shows traces can record request/response pairs but OTel requires custom attributes for HTTP bodies (not captured by default), and that OBI (opentelemetry-ebpf-instrumentation) can collect traces without code changes but cannot reliably add custom body attributes, so OBI alone is insufficient for test-quality traces. Performance, PII leakage, and selector/collector rules are the control points.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 1:09Proving system behavior in migrations
- 5:51Traces as test data
- 7:35OpenTelemetry traces for test data
- 9:23Conditions for capture system
- 10:27Proof-of-concept pipeline
- 11:37Setting up environment
- 13:06Instrumenting traces with bodies
- 13:50Performance and data boundaries
- 16:47Limitations in migrations
- 17:55eBPF zero-code instrumentation
- 21:51Moving instrumentation outside process
- 22:59Java to Go migration case
- 23:20Conditions summary
- 24:25Future work
- 25:35Q&A
related talks
34mOpenTelemetry for Dummies: Instrumenting Go Apps
19mInstrumenting Go Apps With OpenTelemetry
39mEfficient Debugging and Logging with OpenTelemetry in Go
55mCloud-Native Observability with OpenTelemetry
40mPractical introduction to OpenTelemetry tracing
32mUsing OpenTelemetry in a polyglot environment
30mMastering Distributed Tracing with Go
36mObservability For You and Me with OpenTelemetry
