OpenTelemetry

Distributed tracing and observability instrumentation.

Goals

Instrument every program in the workspace with traces so we can observe what actually happens during long-running pipeline runs — which tasks are processed, how long each axe call takes, where failures cluster. Established as a workspace-wide policy 2026-03-25.

Effectiveness

Not yet proven. Packages are installed in the podcast pipeline; instrumentation is not yet live in either program. Verdict is deferred until we have traces flowing to an actual collector and can evaluate whether the data is useful.

What made it effective

No evaluation yet.

Bonus utility

No evaluation yet.

Friction / pain points / surprises

The OTLP exporter target is undefined. We have a projects/otel-explorer/ directory that likely contains a local collector, but it's untracked and unverified. Without a collector running, the exporter silently swallows spans. Instrumentation code running against a no-op collector gives false confidence that tracing is working.

Inertia Mill is not yet instrumented. Despite being the program most in need of observability (590+ tasks, nightly runs, silent failures), the mill has no spans. The instrumentation points are designed; the code doesn't exist.

Six packages for one concern. The OpenTelemetry JavaScript SDK requires @opentelemetry/api, sdk-trace-node, sdk-trace-base, exporter-trace-otlp-http, resources, and semantic-conventions as separate packages. The split is principled (API vs. SDK vs. exporter) but adds package management surface area.