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.

[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
    # ...

[lmolkova]

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.

Agreed, I'll rename to event.yaml.

[lmolkova]

@MSNev I'd prefer to keep things explicit and self-contained in semconv. It'd be surprising to write http.client when defining something and then reference it as a span.http.client.

[jsuereth]

@lmolkova is in danger of being an Rego expert....

I think this is a good directon forward.