Makes all span/metric/event/resource groups id meaningful

[lmolkova]

Fixes #1324

Part of #1472

In order to provide stability guarantees, we need to make semconv groups identifiable.

We currently have different identifying properties - name on event, metric_name on metric, name on resource, but

• nothing for spans
• these properties are called differently and it's hard to use them in generic way leading to issues like semconv_grouped_metrics group by root namespace uses group.id instead of metric_name to determine root namespace weaver#289
• these properties are unique within signal, but could be the same across signals (e.g. dns.lookup.duration could be a metric and an attribute)

The group id is the common identity we can have, but it does not have any meaning now. This PR enforces the following pattern for id

• metric.{metric_name} for metrics
• event.{name} for events
• resource.{name} for resources
• span.\.+.{span_kind} for spans - spans don't have identifying property, so there is nothing to check at the moment. We should be able to change this format if we introduce something better.

[lmolkova]

that's effectively the same change as made in the https://github.com/open-telemetry/semantic-conventions/pull/1440/files#diff-1db9b9bcfb009755e349125b55d3c945e2b5636723e91ee73ac4cd9184108036

[lmolkova]

one of identical feature_flag events has to go so that we can have one group id that follows the pattern.

Removing it also partially unblocks open-telemetry/weaver#306

[joaopgrassi]

Is the change from recommended to required here intentional? 🤔

[lmolkova]

It actually is.

We currently have two almost identical feature flag definitions (one for events, one for logs) and they are only different in the requirement level on this attribute. I stole the fix from #1440

@dyladan and @open-telemetry/semconv-feature-flag-approvers to confirm

[dyladan]

I wasn't sure when to have an events.yaml and when to have a logs.yaml. Is there anywhere documentation which describes when to use which one?

[lmolkova]

I think it should be event.yaml, but really the file name is not enforced or regulated.

The convention itself should be for events because of

• A semantic convention needs to be defined. We do not define semantic
  conventions for LogRecords that are not Events.

https://github.com/open-telemetry/opentelemetry-specification/blob/8548dfc199a76504d573880c4a3fe5a0e483357b/specification/logs/event-api.md?plain=1#L75

Let me create an issue so we document our stance on span events vs events vs logs in semantic conventions

[dyladan]

Approving from feature_flag perspective. What is the reason you removed event.yaml and kept log.yaml instead of the other way around as it appears in most other semconvs? Is that just to mimic what I did in my other PR?

[lmolkova]

Approving from feature_flag perspective. What is the reason you removed event.yaml and kept log.yaml instead of the other way around as it appears in most other semconvs? Is that just to mimic what I did in my other PR?

Thanks @dyladan ! Yes, just to mimic what you've done in the other PR.

[dyladan]

Approving from feature_flag perspective. What is the reason you removed event.yaml and kept log.yaml instead of the other way around as it appears in most other semconvs? Is that just to mimic what I did in my other PR?

Thanks @dyladan ! Yes, just to mimic what you've done in the other PR.

OK. For consistency with other areas of semconv should we use events.yaml instead? Looks like most are using that and the id you used is using the event prefix.

[MSNev]

General Observation, while I (believe) that I understand the desire to make this change it seems a little redundant to basically have the group id prefixed with the type.

Would it not be better to just enforce this via weaver so that the id (when loaded) is always prefixed with its explicit type (so that all ids become unique based on the type. So all ids and then unique across all types and it would avoid someone trying to bypass the logic rules of "naming" a span some other type....

And then we should enforce that any references / extend to the existing id must use the fully constructed type.id, so we still enforce the isolation of the types?

So as an example of the change the following would be what was required

  - id: the.group.id    # resulting id becomes span.the.group.id.client
    type: span   
    brief: group brief
    extends: span.the.other.group.id.client    # You still MUST use the fully qualified group id here
    span_kind: client
    attributes:
      - ref: aws.dynamodb.table_names

  - id: the.other.group.id
    type: span
    span_kind: client
    # ...