CI や build のステップも OTel でトレースできます。build は CI runner 上で実行され、より高速なマネージド runner はそれを短縮します。
Benchmark on your repository before choosing
Build-tool benchmarks published by vendors use repositories chosen to show a difference. Yours is the only one that matters, and both a cold and a warm measurement are needed because CI mostly runs cold.
Terminal
# cold: no cache, the CI condition
rm -rf node_modules/.cache dist && time <tool> build
# warm: the local development condition
time <tool> build
# and the one people forget: incremental after a one-line change
echo "// touch" >> src/index.ts && time <tool> build
OpenTelemetry vs Jaeger: Standard vs Tracing Backend?
OpenTelemetry (OTel) is the CNCF standard - SDKs, APIs, and a collector - for instrumenting apps and exporting traces, metrics, and logs to any backend. Jaeger is a distributed tracing backend with storage and a query UI. They are complementary: OTel produces the data, Jaeger (among others) stores and displays it.
In practice?
These are not really either/or: instrument your apps with OpenTelemetry, then send traces to a backend - which can be Jaeger. OTel future-proofs you against vendor lock-in; Jaeger gives you a mature open-source place to store and explore traces.
Note?
You can trace CI and build steps with OTel too. The builds run on CI runners; faster managed runners shorten them.
Which should I choose?
They work together: use OpenTelemetry to instrument and export, and Jaeger (or another backend) to store and visualize traces. Standardize on OTel; pick Jaeger as one solid open-source tracing backend.
