Clarify that View-dropped attributes may appear on Exemplars#5073
Conversation
jack-berg
left a comment
jack-berg
left a comment
There was a problem hiding this comment.
I think the other good option is to scrub attributes in the collector instead of the SDK. Not sure I want to clutter the metrics SDK spec with refs to the collector though.
Agree. I also didn't want to make that recommendation/guidance in the sdk spec. Moreover, in some companies/organizations, if the sensitive-value leaves the process ever, it maybe considered a violation, so there'd be good reasons to do it in-proc too. |
|
@reyang I dismissed your approval and re-requested review, as the content placement has changed since approval. Please re-review! |
|
Thanks @martincostello @Kielek for raising this issue originally! |
…eraction (open-telemetry#5077) Adds a row to the spec compliance matrix tracking whether each SDK's user documentation notes that attributes filtered out by a `View` may still appear on Exemplars. Follows the style of the existing `Documentation defines adding attributes at span creation as preferred` row - tracks user-facing documentation, not behavioral conformance. Companion to open-telemetry#5073. .NET docs updated in open-telemetry/opentelemetry-dotnet#7270.
8 participants
Adds a non-normative note to the View section of the metrics SDK spec: an attribute key dropped via a View may still be exported on Exemplars as a filtered attribute. Points to the
AlwaysOffExemplarFilter, or a customExemplarFilter/ExemplarReservoir, as the mechanism to disable or control Exemplar sampling.