Skip to content

Update Pulsar semantic #13578

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 18 commits into
base: main
Choose a base branch
from

Conversation

crossoverJie
Copy link
Member

@crossoverJie crossoverJie requested a review from a team as a code owner March 24, 2025 10:08
@laurit
Copy link
Contributor

laurit commented Mar 24, 2025

Reference document: https://opentelemetry.io/docs/specs/semconv/messaging/messaging-metrics/

The linked document starts with the following warning

Existing messaging instrumentations that are using v1.24.0 of this document (or prior):

SHOULD NOT change the version of the messaging conventions that they emit by default until the messaging semantic conventions are marked stable. Conventions include, but are not limited to, attributes, metric and span names, span kind and unit of measure.
SHOULD introduce an environment variable OTEL_SEMCONV_STABILITY_OPT_IN in the existing major version which is a comma-separated list of values. The list of values includes:
messaging - emit the new, stable messaging conventions, and stop emitting the old experimental messaging conventions that the instrumentation emitted previously.
messaging/dup - emit both the old and the stable messaging conventions, allowing for a seamless transition.
The default behavior (in the absence of one of these values) is to continue emitting whatever version of the old experimental messaging conventions the instrumentation was emitting previously.
Note: messaging/dup has higher precedence than messaging in case both values are present
SHOULD maintain (security patching at a minimum) the existing major version for at least six months after it starts emitting both sets of conventions.
SHOULD drop the environment variable in the next major version.
SHOULD emit the new, stable values for span name, span kind and similar “single” valued concepts when messaging/dup is present in the list.

Note that there is also #13192

@crossoverJie
Copy link
Member Author

@laurit Thank you for your reminder. I've noticed that quite a bit of time has passed since this PR was created, and there is still no stable release. Do you recommend enabling compatibility at this stage? -Dotel.semconv-stability.opt-in=messaging/dup

If we enable it, it will modify modules like Kafka/SQS, and it might take a lot of time for code review.

Alternatively, we could maintain the current situation and make changes when the stable version is released.

I look forward to your suggestions.

@laurit
Copy link
Contributor

laurit commented Mar 24, 2025

@laurit Thank you for your reminder. I've noticed that quite a bit of time has passed since this open-telemetry/semantic-conventions#1006 was created, and there is still no stable release. Do you recommend enabling compatibility at this stage? -Dotel.semconv-stability.opt-in=messaging/dup

No, you should follow the same approach as http and db semantic convention stabilization efforts. Modify the extractors so that by default nothing changes and only emit the new attributes when semconv stability flag is used. In tests have a separate suite that runs with -Dotel.semconv-stability.opt-in=messaging so that both old and new semconv would be tested. Since messaging semconv may require a lot of changes it might be best not to do everything in one PR.

@crossoverJie
Copy link
Member Author

@laurit Thank you for the suggestion. I will create a new PR to address the compatibility issues, and I will follow up on the current PR once it is merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants