@opentelemetry/semantic-conventions constants differ from spec

[MikeQDev]

• This only affects the JavaScript OpenTelemetry library
• This may affect other libraries, but I would like to get opinions here first

Noticed a couple of inconsistencies between the trace semantic-conventions spec and the JS semantic-conventions package, particularly around messaging system attributes

Some of the attributes defined in @opentelemetry/semantic-conventions seem to be attribute namespaces, and several other attributes from the spec are not present in @opentelemetry/semantic-conventions

.NET seems to have similar inconsistencies (see open-telemetry/opentelemetry-dotnet#4101), while Java matches the spec closer

3 examples:

OTel Spec	JS	.NET	Java
messaging.destination.name	messaging.destination	messaging.destination	messaging.destination.name
messaging.message.id	messaging.message_id	messaging.message_id	messaging.message.id
messaging.source.name	N/A - not present	N/A - not present	messaging.source.name

Fairly new to contributing, but if a contribution is needed, I'll do my best to dive in (any guidance appreciated). I noticed there is a semconv build script in this repo, as well as a build tool for semantic-convention auto-generation mentioned in #2064

[Flarna]

There were quite some changes done in the spec regarding this. e.g. the HTTP conventions show also some warning and hints regarding transition from old to new.

Seems now it's up to all of us to follow this changes. I added the help wanted label because I think such an adaption is quite some work and more hands are really welcome.

[MikeQDev]

Started some work to upgrade to semconv v1.19.0 in a separate branch, following opentelemetry-java's implementation

I'll work on getting the test suite working, then update tests as needed

A couple of thoughts while proceeding:

• Only updated semconv to v1.19.0; upgrading to v1.20.0,v1.21.0 may be a bit more than I have capacity for, based on the warnings/hints from the link @Flarna provided
• Not sure if we want to hold off on this change until semantic conventions moves to https://github.com/open-telemetry/semantic-conventions
• There is also a metric type in v1.19.0, however, I was unable to generate values from it

Thank you for the assistance; all is appreciated!

EDIT:
After re-reading the note,

Warning Existing HTTP instrumentations that are using v1.20.0 of this document (or prior):
SHOULD NOT change the version of the HTTP or networking attributes that they emit until the HTTP semantic conventions are marked stable (HTTP stabilization will include stabilization of a core set of networking attributes which are also used in HTTP instrumentations).

This seems like we should stick with our current semconv version until HTTP semconvs are stable? Will hold off on changes for now. Please LMK if I am misunderstanding, or if there's a different approach we should take

[daniel-white]

@Flarna have you all considered putting these into some meta format then code generating into all the libraries?

[Flarna]

@daniel-white There are yaml files in the spec repo one could use instead the generated js files. But I doubt they are easier to consume. Or which sort of meta format do you have in mind here?

[daniel-white]

@daniel-white There are yaml files in the spec repo one could use instead the generated js files. But I doubt they are easier to consume. Or which sort of meta format do you have in mind here?

@Flarna oh I was meaning that meta format would be converted into typescript for release for the package. That way some tool/process could automatically update them when the yaml changes

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue was closed because it has been stale for 14 days with no activity.