Clarify meaning of the Attribute Requirement Levels

[dmitryax]

In the OTel Collector, we are adding an option for end users to re-aggregate metrics scraped by receivers. The config interface will be automatically generated for each receiver and will allow users to disable certain attributes that are emitted by default, or enable opt-in attributes.

We want to adopt Attribute Requirement Levels to mark which attributes are emitted by default and which are opt-in.

The initial idea was to allow users to disable any attributes emitted by default. The question from @ChrsMark in this thread is how to treat the Required level. Does it mean that required attributes cannot be disabled by users? If so, do we enforce this requirement in SDKs in any way?

[thompson-tomo]

@dmitryax I ran into a similar scenario with another contrib project, so I proposed #2577 to summarise this behaviour via a table.

[joaopgrassi]

The whole point of having conventions and attributes marked as required is so tooling/observability backends can infer things from the data. So basically if we allow disabling those we are throwing away all the work done not only by semconv, but by vendors on following/trusting them.

When adding conventions, we always aim to have required attributes only when they really make sense and really have a strong meaning.

So yes, required attributes cannot be disabled and I would never consider allowing such thing. As conventions we cannot enforce it in reality, but I'd hope that telemetry generated by official OTel components do enforce it (or at least not offer an option to remove them).

[dmitryax]

@joaopgrassi thank you for the detailed reply. Seems like #2577 would resolve this issue and make it clear

[dmitryax]

The whole point of having conventions and attributes marked as required is so tooling/observability backends can infer things from the data.

I'm wondering if this is applicable to the datapoint attributes. I understand this use case for resource attributes and maybe spans, but do we have any required datapoint attribute in SemConv?

I'm asking because the current collector implementation in question is for metrics re-aggregation, not disabling resource attributes. So supporting required datapoint attributes would require extra logic which would unlikely be ever executed.

Disabling any resource attributes is actually already available 🙈, I'll take your feedback to address that separately.

[joaopgrassi]

I'm wondering if this is applicable to the datapoint attributes. I understand this use case for resource attributes and maybe spans, but do we have any required datapoint attribute in SemConv?

Yes for sure it is. For ex the http.server.request.duration metric requires the http.request.method attribute and allowing it to be removed would kinda decrease the value of the metric considerably I'd say.

I get though where you come from, but I'd treat attributes used in metrics the same way.

[dmitryax]

Yes for sure it is. For ex the http.server.request.duration metric requires the http.request.method attribute and allowing it to be removed would kinda decrease the value of the metric considerably I'd say.

That said, I get your point. Not to argue against it, but as a user I can see a case for aggregating http.server.request.duration without http.request.method if I only care about overall latency. For instance, if my endpoint accepts only POST and PUT and I don’t care which one is used.

[dmitryax]

I'll take it to the collector. It'll be cleaner if definitions for resource attributes and metric attributes have the same field to define the requirement level aligned with the SemConv