You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recent spec changes removed the notion of custom ExemplarFilter and only allows 3 built-in values (on/off/tracebased).
We need to remove ExemplarFilter and adhere to this new spec. (ExemplarFilter was only public in experimental builds, but this is breaking change for those releases)
The OpenTelemetry Specification doesn't explicitly prohibit the creation of custom exemplar filters, while it mandates support for standard filters like AlwaysOn, AlwaysOff, and TraceBased. Given this, should we still consider the removal of the ExemplarFilter API?
Should we drive clarity in the spec to call out that custom exemplar filters are not supported?
https://github.com/open-telemetry/opentelemetry-specification/pull/3820/files
It does not prohibit, but does not support either. I don't see a need for keeping Filter - it is not particularly useful, as it does not have access even to meter.name or instrument.name, so can't use it for customizing filter based on the meter/instrument.
Recent spec changes removed the notion of custom ExemplarFilter and only allows 3 built-in values (on/off/tracebased).
We need to remove ExemplarFilter and adhere to this new spec. (ExemplarFilter was only public in experimental builds, but this is breaking change for those releases)
https://github.com/open-telemetry/opentelemetry-specification/pull/3820/files
The text was updated successfully, but these errors were encountered: