Explanation¶

Background and reasoning. Nothing here is needed to get telemetry flowing; all of it is useful when deciding whether this module fits, or when something behaves in a way that looks wrong until you know why.

• Endpoint resolution and the config model — why otelcore takes typed values rather than a config container, how shared and per-signal settings merge, and why an empty endpoint is a feature.
• What this module does not do — the transports, exporters and conveniences deliberately left out, and the combinations that do not work.
• Why the OpenTelemetry versions are pinned in lockstep — what the pins protect against, and what it costs.

Three ideas the rest of the documentation assumes¶

Typed values in, providers out. The module does no configuration parsing and no environment scanning of its own. You resolve a Settings from wherever your configuration lives; it turns that into a provider. Removing the coupling to a config framework is the reason the module exists separately at all.

The signal packages are independent. logs, metrics and tracing each build their own exporter from the shared core. A service that only traces never links the log or metric exporter code, which is what lets all three sit on otelcore without dragging a heavyweight common import behind them.

An empty endpoint is intentional. It means "fall back to the standard OTEL_EXPORTER_OTLP_* environment variables", not "misconfigured". It is never treated as an error, in code or in documentation.