Semconv 1.25 #4690

dyladan · 2024-05-09T15:26:47Z

This is a big PR but most of it is autogenerated. Below is a list of changes:

Update semconv to 1.25
Update semconv generator to 0.24
Output to experimental.ts and stable.ts so we can export separately in the future if required
- experimental attributes and metrics now have @experimental jsdoc tag
Change SEMRESATTRS_ and RESATTRS_ to just ATTR_ for attributes
Generate constants for metric names with METRIC_ prefix
Deprecate all old names. These files will never change again and be removed in 2.0 if we ever release one
All names are constants now. Removes requirement for all the weird type stuff (sorry @MSNev I know you spent a lot of time on that)

Notes:

Template attributes are still not supported such as http.request.header.<key> for now. It's not clear how we can/should support them and until we make a decision i'd leave them out (they were excluded/didn't exist before)

Questions:

For the main export import {} from '@opentelemetry/semantic-conventions' should ALL semconv be exported experimental and stable, or should only the stable be exported and experimental would be imported from @opentelemetry/semantic-conventions/experimental? main export is stable only with backwards compatibility for previous releases.

Example: this is what it would look like to update the utils.ts file in the http instrumentation.

import {
  ATTR_HTTP_ROUTE,
  // These are not in the updated semconv and need to be imported with old names for now
  SEMATTRS_HTTP_CLIENT_IP,
  SEMATTRS_HTTP_HOST,
  SEMATTRS_HTTP_REQUEST_CONTENT_LENGTH_UNCOMPRESSED,
  SEMATTRS_HTTP_RESPONSE_CONTENT_LENGTH_UNCOMPRESSED,
  SEMATTRS_HTTP_SERVER_NAME,
  SEMATTRS_NET_HOST_IP,
  SEMATTRS_NET_PEER_IP,
} from '@opentelemetry/semantic-conventions';
import {
  NET_TRANSPORT_VALUES_IP_TCP,
  NET_TRANSPORT_VALUES_IP_UDP,
  ATTR_HTTP_FLAVOR,
  ATTR_HTTP_METHOD,
  ATTR_HTTP_REQUEST_CONTENT_LENGTH,
  ATTR_HTTP_RESPONSE_CONTENT_LENGTH,
  ATTR_HTTP_SCHEME,
  ATTR_HTTP_STATUS_CODE,
  ATTR_HTTP_TARGET,
  ATTR_HTTP_URL,
  ATTR_HTTP_USER_AGENT,
  ATTR_NET_HOST_NAME,
  ATTR_NET_HOST_PORT,
  ATTR_NET_PEER_NAME,
  ATTR_NET_PEER_PORT,
  ATTR_NET_TRANSPORT,
} from '@opentelemetry/semantic-conventions/experimental';

dyladan

Added some quick comments to explain some of my thought process

dyladan · 2024-05-09T15:28:03Z

scripts/semconv/templates/SemanticAttributes.ts.j2

Template is a lot smaller now because I removed all the namespaced stuff that will never be updated and is considered deprecated.

dyladan · 2024-05-09T15:28:28Z

scripts/semconv/generate.sh

@@ -54,4 +80,4 @@ npm run lint:fix:changed

 # Run the size checks for the generated files
 cd "${ROOT_DIR}/packages/opentelemetry-semantic-conventions"
-npm run size-check
+npm run size-check


@MSNev do you think this is really required anymore if we're never going to update the constmap stuff? Everything is a constant now

I'm also curious about this.

We could, but it would be "nice" to have some tests around this so that someone in the future doesn't "undo" all of the good work that this created.

scripts/semconv/generate.sh

dyladan · 2024-05-09T15:31:14Z

packages/opentelemetry-semantic-conventions/src/trace/SemanticAttributes.ts

@@ -2717,30 +3127,40 @@ const TMP_NETHOSTCONNECTIONTYPEVALUES_UNKNOWN = 'unknown';

 /**
 * The internet connection type currently being used by the host.
+ *
+ * @deprecated Use NET_HOST_CONNECTION_TYPE_VALUES_WIFI.


@MSNev I suspect this was a mistake in the original PR that the whole name is a single uppercase block like NETHOSTCONNECTIONTYPEVALUES_*. Since we've released this it can't be removed so I just deprecated it in favor of the better names exported in experimental.ts and stable.ts

No, it was a case of using the existing conversions to map the type names.

This also avoided any possible clashes, now or in the future with the names of an attribute name with some defined value type.

And I don't think we should do this either as it will further conflate the issues for the build tools (ie the issue around the semantic conventions client_id and client.id being mapped to the same value), as this then cause the issue in that now we have CamelCase conversion could also cause name clashes

I think it's actually (practically) impossible to clash? The attributes are prefixed with ATTR_ which means in order to have a clash the attribute would have to have the word "values" in it AND the enum would have to begin with the word "Attr". Each of these on their own seem quite unlikely, but together I think it's safe to say it will never happen.

dyladan · 2024-05-09T15:31:50Z

packages/opentelemetry-semantic-conventions/src/experimental.ts

+ *
+ * Note: Total CPU time consumed by the specific container on all available CPU cores.
+ *
+ * @experimental this metric is experimental and is subject to change in minor releases of `@opentelemetry/semantic-conventions`.


Everything in this file is experimental

dyladan · 2024-05-09T15:32:16Z

scripts/semconv/.gitignore

@@ -1 +1,2 @@
 opentelemetry-specification/
+semantic-conventions/


Added a new ignore. Kept the old one since a lot of people have already checked it out and it isn't hurting anything

dyladan · 2024-05-09T15:33:32Z

packages/opentelemetry-semantic-conventions/src/experimental.ts

+ *
+ * @experimental this metric is experimental and is subject to change in minor releases of `@opentelemetry/semantic-conventions`.
+ */
+export const METRIC_CONTAINER_CPU_TIME = 'container.cpu.time';


Added metric names with METRIC_ prefix

dyladan · 2024-05-09T15:34:03Z

packages/opentelemetry-semantic-conventions/src/experimental.ts

+ *
+ * @experimental this attribute is experimental and is subject to change in minor releases of `@opentelemetry/semantic-conventions`.
+ */
+export const LOG_IOSTREAM_VALUES_STDOUT = 'stdout';


The values didn't have a prefix before. Do we think they should have one now or is it ok to leave them out?

I'm not sure exactly what you mean here.

Like the attributes have the prefix ATTR_ and metrics constants have the prefix METRIC_. The enum values don't have a prefix. They're just named by whatever the enum name was. Should it be LOG_IOSTREAM_VALUES_STDOUT or should it be ENUM_LOG_IOSTREAM_VALUES_STDOUT?

In @MSNev's constant version he had LOGIOSTREAMVALUES_STDOUT.

dyladan · 2024-05-09T15:34:47Z

/cc @trentm @JamieDanielson since you seemed interested in this

/cc @MSNev since you have done the most work on this recently

trentm · 2024-05-09T21:10:42Z

I'll take a while to review this. I'm still trying to grok the generation, the semantic-conventions/model vs schemas/... subdirs, etc. Some early Qs/thoughts:

I gather merging the SEMRESATTRS_ and SEMATTRS_ groups is related to the "Problem" described at Reconsidering what semantic conventions code generation should produce semantic-conventions#551 A hearty +1 to not using those prefixes. Did you consider also dropping the "ATTRS_" prefix? IIUC the Go semconv does not have any prefix on the exports from its semconv package. Java has namespacing of a different sort via the HttpAttributes part of import io.opentelemetry.semconv.HttpAttributes.
Similar to above, did you consider not having the METRIC_ prefix on metrics-related constants? (I don't see metrics-related values in open-telemetry/semantic-conventions-java.git and I'm not sure why. Does OTel Java not publish a package with metrics semconv constants?)

Correctness Qs:

Are you sure that the "deprecated" dirs in "semantic-conventions/model/..." handle all the deprecated values? For example http.resend_count was renamed to http.request.resend_count, but with your PR there is no deprecated HTTP_RESEND_COUNT entry.
http.client_ip is deprecated. There is a SEMATTRS_HTTP_CLIENT_IP but no ATTR_HTTP_CLIENT_IP, even though:

* @deprecated use ATTR_HTTP_CLIENT_IP
*/
export const SEMATTRS_HTTP_CLIENT_IP = TMP_HTTP_CLIENT_IP;

Same for SEMATTRS_DB_CASSANDRA_KEYSPACE, and I assume for others.

trentm · 2024-05-09T21:16:42Z

The _VALUES_ fields are using the description of the field for which they are values as their comment, e.g.:

/**
 * The language of the telemetry SDK.
 */
export const TELEMETRY_SDK_LANGUAGE_VALUES_CPP = 'cpp';

/**
 * The language of the telemetry SDK.
 */
export const TELEMETRY_SDK_LANGUAGE_VALUES_DOTNET = 'dotnet';

/**
 * The language of the telemetry SDK.
 */
export const TELEMETRY_SDK_LANGUAGE_VALUES_ERLANG = 'erlang';

/**
 * The language of the telemetry SDK.
 */
export const TELEMETRY_SDK_LANGUAGE_VALUES_GO = 'go';

Can the description (is that the "brief" yaml field?) of the value be used, instead?

dyladan · 2024-05-10T12:36:30Z

Did you consider also dropping the "ATTRS_" prefix? ... Similar to above, did you consider not having the METRIC_ prefix

Yes I did consider that and I still would consider it if we want to go that route. It is my understanding that the semconv has decided to use a registry of unique attributes that can be applied to any signal or resource so there is no reason to differentiate them. I only kept the ATTR and METRIC prefix just to make it easier to find the value you want when autocompleting and not get confused.

Are you sure that the "deprecated" dirs in "semantic-conventions/model/..." handle all the deprecated values? For example http.resend_count was renamed to http.request.resend_count, but with your PR there is no deprecated HTTP_RESEND_COUNT entry.

I'm actually sure they're NOT all there. The deprecated.yaml didn't exist when many of these were removed and they weren't all added back. I left all the old versions in the file they were already in, so it isn't a breaking change, but I am going to add the missing attributes to the registry anyway (see open-telemetry/semantic-conventions#1025)

Can the description (is that the "brief" yaml field?) of the value be used, instead?

Good catch. I'll update the PR

dyladan · 2024-05-10T12:46:58Z

Can the description (is that the "brief" yaml field?) of the value be used, instead?

Good catch. I'll update the PR

Unfortunately it looks like there aren't actually descriptions on the values themselves. I think the intellisense autocomplete looks ok anyway though:

dyladan · 2024-05-10T12:57:39Z

@trentm what about this?

dyladan · 2024-05-10T13:01:38Z

I ended up with something like this:

/**
 * Enum value 'created' for attribute {@link ATTR_ANDROID_STATE}.
 *
 * @experimental this attribute is experimental and is subject to change in minor releases of `@opentelemetry/semantic-conventions`.
 */
export const ANDROID_STATE_VALUES_CREATED = 'created';

Which looks like this and actually links back to its parent attribute

codecov · 2024-05-13T12:35:12Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.72%. Comparing base (e49c4c7) to head (e9fcfba).
Report is 12 commits behind head on main.

❗ Current head e9fcfba differs from pull request most recent head 3949f1f

Please upload reports for the commit 3949f1f to get more accurate results.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4690      +/-   ##
==========================================
- Coverage   93.32%   89.72%   -3.61%     
==========================================
  Files          84      149      +65     
  Lines        1694     3242    +1548     
  Branches      349      707     +358     
==========================================
+ Hits         1581     2909    +1328     
- Misses        113      333     +220

see 103 files with indirect coverage changes

JamieDanielson

So far this is looking really great, thanks @dyladan and thanks @trentm for the review so far.

I like ATTR better than SEMATTRS and SEMRESATTRS and wish I had realized this sooner and commented on the original PR that introduced them. I'm not clear what the full benefit is of having those other prefixes, although it may have been more relevant before they were in the global registry.

I only kept the ATTR and METRIC prefix just to make it easier to find the value you want when autocompleting and not get confused.

I'm not sure I understand the value of having ATTR prefix for attributes but no prefix for values. In that case I'd think they could be prefixed as well, or prefix neither.

JamieDanielson · 2024-05-13T15:28:43Z

For the main export import {} from '@opentelemetry/semantic-conventions' should ALL semconv be exported experimental and stable, or should only the stable be exported and experimental would be imported from @opentelemetry/semantic-conventions/experimental?

🤔 The benefit of keeping experimental attributes in /experimental subdirectory is that we are making it very explicit that it is an experimental attribute. I guess the downside is when the experimental attribute becomes stable, the consumer of that would have to update their code when they upgrade packages?

dyladan · 2024-05-13T15:31:57Z

So far this is looking really great, thanks @dyladan and thanks @trentm for the review so far.

I like ATTR better than SEMATTRS and SEMRESATTRS and wish I had realized this sooner and commented on the original PR that introduced them. I'm not clear what the full benefit is of having those other prefixes, although it may have been more relevant before they were in the global registry.

Exactly. Previously there was some chance (although probably it wouldn't have happened) that the same attribute could have been defined for different signals. I think the most reasonable way this could have happened would be for an attribute to have bounded specific values for metrics to control cardinality, but be unbounded for other signals or resources.

I only kept the ATTR and METRIC prefix just to make it easier to find the value you want when autocompleting and not get confused.

I'm not sure I understand the value of having ATTR prefix for attributes but no prefix for values. In that case I'd think they could be prefixed as well, or prefix neither.

The way we have it in this PR values have a postfix (actually an infix between the enum name and the value name). It provides separation between the enum name and the value name so it is distinguishable easily. For example, HOST_TYPE_LINUX is less obvious to me than HOST_TYPE_VALUE_LINUX where it is clear that LINUX is the value for the HOST_TYPE enum (these are fake attributes I just made up to prove a point).

JamieDanielson · 2024-05-13T15:39:09Z

For the main export import {} from '@opentelemetry/semantic-conventions' should ALL semconv be exported experimental and stable, or should only the stable be exported and experimental would be imported from @opentelemetry/semantic-conventions/experimental?

🤔 The benefit of keeping experimental attributes in /experimental subdirectory is that we are making it very explicit that it is an experimental attribute. I guess the downside is when the experimental attribute becomes stable, the consumer of that would have to update their code when they upgrade packages?

I guess Java has a separate package for experimental attributes - there's a semconv in instrumentation-api, and a semconv in instrumentation-api-incubator. Python also has semconv in incubating separate from semconv stable. Go seems to have it all in one.

dyladan · 2024-05-13T16:08:40Z

🤔 The benefit of keeping experimental attributes in /experimental subdirectory is that we are making it very explicit that it is an experimental attribute. I guess the downside is when the experimental attribute becomes stable, the consumer of that would have to update their code when they upgrade packages?

This is the definition of experimental... It also would force users to at least consider if they need to make a change. If the semconv attributes you're using change it might be good to force our users to acknowledge that by changing to the stable export. If they can get all from a single export they may never notice if something is renamed/deprecated.

I guess Java has a separate package for experimental attributes - there's a semconv in instrumentation-api, and a semconv in instrumentation-api-incubator. Python also has semconv in incubating separate from semconv stable. Go seems to have it all in one.

I think a single package with multiple entry points is roughly equivalent to having separate packages and less overhead. Go has all in one but they export each version separately so you have to do something to get the new semconv version.

trentm · 2024-05-13T22:46:06Z

I guess Java has a separate package for experimental attributes

My understanding of the OTel Java team's recommendations/requirements is that they do not allow a stable instrumentation package to have a dependency on the instrumentation-api-incubating package. They instead suggest the instrumentation have a copy of the experimental attributes in its own package code. This means that a user of the (non-experimental) semconv package is never broken by a semver-minor update of the package.

I guess we could get the equivalent by either (a) never using the "../experimental" entry point in stable instrumentation packages, or (b) pinning the @opentelemetry/semantic-conventions dep to a particular minor in packages that do.

I think a single package with multiple entry points is roughly equivalent to having separate packages and less overhead.

Agreed.

Go has all in one but they export each version separately so you have to do something to get the new semconv version.

This PR beat me to an attempt to update the semconv package. FWIW, I had been considering having separate entry points for each semconv version. See #4572 (comment)
I'm not advocating that option over this PR, however.

trentm · 2024-05-13T22:55:29Z

I ended up with something like this: [screenshot of intellisense for a _VALUES_ field]

Nice. That looks good.

I only kept the ATTR and METRIC prefix just to make it easier to find the value you want when autocompleting and not get confused.

My soft vote is for no prefixes. The way I thinking/expecting developers to use semconv values was to (a) have a semantic-conventions document open (e.g. https://opentelemetry.io/docs/specs/semconv/http/http-metrics/) and see a string (e.g. http.server.request.duration) and (b) then want to be able to import HTTP_SERVER_REQUEST_DURATION.

IIUC, autocomplete will show ATTR_HTTP_* and METRIC_HTTP_* values when typing HTTP so I think it is fine for autocomplete either way. Having the METRIC_ does help the developer that knows they are scoped to metrics stuff. ATTR_ feels out of place for non-metrics, non-logs stuff.

Another small reason is that I like the shorter names in code.

This is a soft vote though. I don't have a very strong reaction to ATTR_.

trentm · 2024-05-13T22:57:51Z

The way we have it in this PR values have a postfix (actually an infix between the enum name and the value name)

I like the _VALUES_ infix.
I'm not sure if reads better as _VALUE_ (singular).

dyladan · 2024-05-14T17:17:19Z

IIUC, autocomplete will show ATTR_HTTP_* and METRIC_HTTP_* values when typing HTTP so I think it is fine for autocomplete either way

yes.

Having the METRIC_ does help the developer that knows they are scoped to metrics stuff. ATTR_ feels out of place for non-metrics, non-logs stuff.

It helps the developers who don't have the semconv doc open, are just trying to find an attribute quick, and are scanning the autocomplete list. They can type http and quickly either filter or ignore the metric names out.

trentm · 2024-05-14T22:11:30Z

What about providing a Schema URL value (or values)? My very limited understanding is that including a semconv schemaUrl in instrumentationScope is being suggested as a path for downstream observability systems to be able to handle semconv changes.

Go, with a separate explicit import for each semconv version, has a single SchemaURL export for each package (e.g. https://github.com/open-telemetry/opentelemetry-go/blob/main/semconv/v1.25.0/schema.go).
Java has an array of recent ones: https://github.com/open-telemetry/semantic-conventions-java/blob/main/semconv/src/main/java/io/opentelemetry/semconv/SchemaUrls.java

This could be handled separately, as well.

trentm

Thanks very much for doing this.

This is a significant usage change for this package. It would be nice to have more prose in the changelog about the change. It would also be good to update the README example and perhaps explain the ATTR_, METRIC_ and _VALUES_ usage.

or should only the stable be exported and experimental would be imported from @opentelemetry/semantic-conventions/experimental?

I'm in favour of doing this. While it is more work for the user of experimental values, it is much less likely to surprise the developer when updating to a new package minor version that drops those experimental fields.
Throwing out a possible alternative to _VALUES_: use a double-underscore. E.g.:

exports.HTTP_REQUEST_METHOD__GET = 'GET';

It would look like this in autocomplete:

Just an idea.

Question: I'd expect the common import usage would be:

import { ... } from '@opentelemetry/semantic-conventions/';

Do you actually get autocomplete in VSCode in this statement? I don't.

I only get it when doing import * as semconv from '...'; semconv.HTTP, for example.

tl;dr: I think the "experimental" entry-point is the main outstanding discussion point.

scripts/semconv/generate.sh

trentm · 2024-05-14T22:41:41Z

scripts/semconv/templates/SemanticAttributes.ts.j2

+{%- set filtered_attributes = attributes | select(filter) | list %}
+{%- set filtered_metrics = metrics | select(filter) | list %}
+
+{%- for metric in filtered_metrics %}


nit: I'd put the filtered_metrics block below the filtered_attributes so that attributes are top of the file and special cases (e.g. metrics) are after. Granted this is super nitpicking for those actually reading the generated files.

I don't think metrics are a special case. maybe we should put them in their own file just to make them easier to find later?

scripts/semconv/templates/SemanticAttributes.ts.j2

trentm · 2024-05-14T23:11:20Z

scripts/semconv/generate.sh

@@ -54,4 +80,4 @@ npm run lint:fix:changed

 # Run the size checks for the generated files
 cd "${ROOT_DIR}/packages/opentelemetry-semantic-conventions"
-npm run size-check
+npm run size-check


I'm also curious about this.

dyladan · 2024-05-15T11:31:19Z

What about providing a Schema URL value (or values)? My very limited understanding is that including a semconv schemaUrl in instrumentationScope is being suggested as a path for downstream observability systems to be able to handle semconv changes.

Go, with a separate explicit import for each semconv version, has a single SchemaURL export for each package (e.g. https://github.com/open-telemetry/opentelemetry-go/blob/main/semconv/v1.25.0/schema.go). Java has an array of recent ones: https://github.com/open-telemetry/semantic-conventions-java/blob/main/semconv/src/main/java/io/opentelemetry/semconv/SchemaUrls.java

This could be handled separately, as well.

I think I'd rather handle schema url as a separate addition later

This is a significant usage change for this package. It would be nice to have more prose in the changelog about the change. It would also be good to update the README example and perhaps explain the ATTR_, METRIC_ and VALUES usage.

I agree I'll add more detail

Do you actually get autocomplete in VSCode in this statement? I don't.

Yes I do. I hit ctrl+enter to bring up the autocomplete list.

I'll go through the more detailed review responses later today

packages/opentelemetry-semantic-conventions/.size-limit.json

trentm · 2024-05-15T21:29:33Z

Do you actually get autocomplete in VSCode in this statement? I don't.

Yes I do. I hit ctrl+enter to bring up the autocomplete list.

Thanks for teaching me my editor. :) For me it is Control+Space or Cmd+I (https://stackoverflow.com/questions/56143239/how-to-trigger-vs-code-intellisense-using-keyboard-on-os-x).

dyladan · 2024-05-22T20:04:27Z

@MSNev what would you think of combining _VALUES_ infix option in this pr with ENUM_ prefix? Would look something like this:

export const ATTR_LOG_IOSTREAM = 'log.iostream';
export const ENUM_LOG_IOSTREAM_VALUES_STDOUT = 'stdout';
export const ENUM_LOG_IOSTREAM_VALUES_STDERR = 'stderr';

edit: I like someone's suggestion above to singular _VALUE_ instead of plural _VALUES_ so I'd probably make that change

dyladan · 2024-05-23T12:06:13Z

Reverting to draft while we wait on a resolution from open-telemetry/semantic-conventions#1031

trentm · 2024-05-23T22:49:22Z

Interestingly, perhaps, I just noticed that the recently updated Python semconv generation appends _TEMPLATE to the const name if the field is type: template[string[]]. So, for example, http.request.header:

      - id: request.header
        stability: stable
        type: template[string[]]
        brief: >
          HTTP request headers, `<key>` being the normalized HTTP Header name (lowercase), the value being the header values.

Is HTTP_REQUEST_HEADER_TEMPLATE and not HTTP_REQUEST_HEADER
https://github.com/open-telemetry/opentelemetry-python/blob/8b80a28e825b102417eceb429f64d5ce52f3c2e7/scripts/semconv/templates/semantic_attributes.j2#L24

dyladan · 2024-05-24T13:37:11Z

Interestingly, perhaps, I just noticed that the recently updated Python semconv generation appends _TEMPLATE to the const name if the field is type: template[string[]]. So, for example, http.request.header:
      - id: request.header
        stability: stable
        type: template[string[]]
        brief: >
          HTTP request headers, `<key>` being the normalized HTTP Header name (lowercase), the value being the header values.
Is HTTP_REQUEST_HEADER_TEMPLATE and not HTTP_REQUEST_HEADER https://github.com/open-telemetry/opentelemetry-python/blob/8b80a28e825b102417eceb429f64d5ce52f3c2e7/scripts/semconv/templates/semantic_attributes.j2#L24

Yeah we're actually ignoring those for now. I was going to add them in a follow-up because they are handled differently

dyladan · 2024-05-29T15:12:23Z

@MSNev does the limitation on attribute values not being the same as attribute namespaces mentioned by @lmolkova in open-telemetry/semantic-conventions#1064 ease your concerns with enum names? There should be no collision.

MSNev · 2024-05-29T15:35:21Z

@MSNev does the limitation on attribute values not being the same as attribute namespaces mentioned by @lmolkova in open-telemetry/semantic-conventions#1064 ease your concerns with enum names? There should be no collision.

If we want to go with the changing the names of the values to full screaming snake case rather than the existing <attribute name screaming>_<value name as screaming snake case> (eg other languages use camel case for the names) then as we are already prefixing all attributes with ATTR_ I think the better option would be your option 3 and use a more generic prefix (as they may not necessarily be considered to be enums) like VAL_ or VALUE_

so

export const ATTR_LOG_IOSTREAM = 'log.iostream';
export const LOGIOSTREAM_STDOUT = 'stdout';
export const LOGIOSTREAM_STDERR = 'stderr';

becomes

export const ATTR_LOG_IOSTREAM = 'log.iostream';
export const VAL_LOG_IO_STREAM_STDOUT = 'stdout';
export const VAL_LOG_IO_STREAM_STDERR = 'stderr';

This way there would always be zero chance of any conflict, vs the infix option. This would also work for whatever the outcome of the client.id / client_id resolution will be (which looks like the recommendation will be '_' -> '__', with the final option up to each language as not all languages use snake case.

Personally, I prefer the existing (but I guess I'm a little biased as that was my original choice) to convert the CamelCased values classes to the combination to avoid clashes 😀

dyladan added 3 commits May 9, 2024 10:52

feat(semconv): update semantic conventions to 1.25

307d017

Deprecate old values names

a7e5212

Change prefix and deprecate old names

fe400cb

dyladan mentioned this pull request May 9, 2024

Semantic Convention Update: Tracking Issue #4572

Open

7 tasks

dyladan commented May 9, 2024

View reviewed changes

Changelog

f782cb6

dyladan marked this pull request as ready for review May 9, 2024 16:31

dyladan requested a review from a team as a code owner May 9, 2024 16:31

Improve enum docs

dc3f50a

dyladan added 2 commits May 10, 2024 09:11

Remove commented code

f72598e

Merge branch 'main' into semconv-1.25

e9fcfba

JamieDanielson reviewed May 13, 2024

View reviewed changes

Merge branch 'main' into semconv-1.25

1505866

trentm reviewed May 14, 2024

View reviewed changes

dyladan commented May 15, 2024

View reviewed changes

packages/opentelemetry-semantic-conventions/.size-limit.json Outdated Show resolved Hide resolved

MustafaHaddara mentioned this pull request May 21, 2024

Update http.* and url.* attributes to align with Semantic Conventions #4724

Closed

dyladan added 7 commits May 21, 2024 14:16

Remove errant file

7036118

Remove class name

07278df

Blank line between metrics

727d23e

Fix newlines

79738a4

Fix casing

c982f3e

main export should be stable only

a827bb7

Merge branch 'main' into semconv-1.25

a8295e7

dyladan added 2 commits May 22, 2024 16:07

Add experimental index

fbc64da

Use singular value infix

72561ba

dyladan mentioned this pull request May 22, 2024

messaging.client_id -> messaging.client.id rename causes issues with code generation open-telemetry/semantic-conventions#1031

Open

dyladan marked this pull request as draft May 23, 2024 12:05

Add const types to semconv

31da43d

Use VAL_ prefix for enum values

3949f1f

		@@ -1 +1,2 @@
		opentelemetry-specification/
		semantic-conventions/

Semconv 1.25 #4690

Are you sure you want to change the base?

Semconv 1.25 #4690

Conversation

dyladan commented May 9, 2024 • edited

dyladan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MSNev May 22, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dyladan commented May 9, 2024

trentm commented May 9, 2024

trentm commented May 9, 2024

dyladan commented May 10, 2024

dyladan commented May 10, 2024

dyladan commented May 10, 2024

dyladan commented May 10, 2024

codecov bot commented May 13, 2024 • edited

Codecov Report

JamieDanielson left a comment

Choose a reason for hiding this comment

JamieDanielson commented May 13, 2024

dyladan commented May 13, 2024

JamieDanielson commented May 13, 2024

dyladan commented May 13, 2024

trentm commented May 13, 2024

trentm commented May 13, 2024

trentm commented May 13, 2024 • edited

dyladan commented May 14, 2024

trentm commented May 14, 2024

trentm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dyladan commented May 15, 2024

trentm commented May 15, 2024

dyladan commented May 22, 2024 • edited

dyladan commented May 23, 2024

trentm commented May 23, 2024 • edited

dyladan commented May 24, 2024

dyladan commented May 29, 2024

MSNev commented May 29, 2024

dyladan commented May 9, 2024 •

edited

MSNev May 22, 2024 •

edited

codecov bot commented May 13, 2024 •

edited

trentm commented May 13, 2024 •

edited

dyladan commented May 22, 2024 •

edited

trentm commented May 23, 2024 •

edited