Explore native OTel telemetry in SDKs vs hook-based approach

Context

At KubeCon EU 2026, the OTel observability discussion (recap) proposed moving telemetry from hooks into the SDKs natively.

Problem

Today, OTel integration in OpenFeature is done through hooks. This means every user or provider has to set up telemetry hooks separately. The group discussed whether traces and metrics should be built into the SDKs directly, so telemetry is available out of the box, particularly in the flagd providers.

Questions

• Should the SDK spec define optional native OTel support (traces and metrics) as a built-in capability?
• Or is the hook-based approach sufficient if we provide well-maintained official hooks?
• If native, should it be opt-in (e.g. enabled when an OTel SDK is detected) to avoid adding a hard dependency?
• Should flagd providers ship with telemetry enabled by default?

Considerations

• Native support improves developer experience by removing setup friction
• Hook-based approach keeps the SDK core lightweight and avoids coupling to OTel
• A middle ground could be official OTel hooks that providers wire up automatically
• The existing Feature Flag Semantic Conventions SIG defines the attributes we should emit

Related

• #281: Support expanded OpenTelemetry semantic attributes (closed)
• open-feature/flagd#1778: Add comprehensive metrics and tracing
• open-feature/flagd#1806: OFREP evaluation is missing tracing semconv attributes

Start by reading the OpenTelemetry semantic conventions and the related issues #281, flagd#1778, and flagd#1806. Compare native SDK telemetry, official hooks, and opt-in behavior, then document a decision on the SDK spec and whether flagd providers should enable telemetry by default.