Skip to content

Conversation

@austindrenski
Copy link

@austindrenski austindrenski commented Dec 20, 2025

No idea why the semconv committee decided to go with aws_sqs and aws.sns, but either the semconv is wrong or the instrumentation is, so figured I'd start with a PR here and see what others think. edit: see #8322 (comment) for context on this^ discrepancy, as well as plans to eventually rename aws{_ => .}sqs.

From the OTel semantic conventions docs for messaging.system:

messaging.system has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used.

Value Description Stability
activemq Apache ActiveMQ Development
aws.sns Amazon Simple Notification Service (SNS) Development
aws_sqs Amazon Simple Queue Service (SQS) Development
eventgrid Azure Event Grid Development
eventhubs Azure Event Hubs Development
gcp_pubsub Google Cloud Pub/Sub Development
jms Java Message Service Development
kafka Apache Kafka Development
pulsar Apache Pulsar Development
rabbitmq RabbitMQ Development
rocketmq Apache RocketMQ Development
servicebus Azure Service Bus Development

Related

No idea why the semconv committee decided to go with `aws_sqs` and
`aws.sns`, but either the semconv is wrong or the instrumentation
is, so figured I'd start with a PR here and see what others think.
Copilot AI review requested due to automatic review settings December 20, 2025 03:38
@austindrenski austindrenski requested a review from a team as a code owner December 20, 2025 03:38
@github-actions github-actions bot requested a review from akats7 December 20, 2025 03:39
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR corrects the messaging.system attribute value for AWS SNS to align with OpenTelemetry semantic conventions. The fix changes from using a hardcoded string "aws_sns" to using the predefined semconv constant MessagingSystemAWSSNS, which uses the correct value "aws.sns" (with a dot instead of underscore) as specified in the OTel documentation.

Key Changes:

  • Updated SNS attribute builder to use the semantic convention constant instead of hardcoded string
  • Updated all three test cases to verify the correct constant usage

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
instrumentation/github.com/aws/aws-sdk-go-v2/otelaws/snsattributes.go Updated SNSAttributeBuilder to use semconv.MessagingSystemAWSSNS constant instead of manually constructing the attribute with the "aws_sns" string
instrumentation/github.com/aws/aws-sdk-go-v2/otelaws/snsattributes_test.go Updated three test cases (TestPublishInput, TestPublishInputWithNoDestination, TestPublishBatchInput) to assert against the correct semconv constant

The code changes look correct and complete. The PR properly addresses the semantic convention mismatch by using the predefined constant from the semconv package (v1.37.0), which ensures the correct value "aws.sns" is used instead of "aws_sns". This brings the SNS instrumentation in line with the OTel specifications and is consistent with how SQS is already implemented using semconv.MessagingSystemAWSSQS. No issues found.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@thompson-tomo
Copy link

See open-telemetry/semantic-conventions#2668 for explanation on the naming.

@flc1125
Copy link
Member

flc1125 commented Dec 22, 2025

Thank you for your contribution. Currently, there are 2 issues that need attention:

  • The current changes are not backward-compatible adjustments.
  • The current properties and property values are all in the unstable version.

@open-telemetry/go-approvers I'm not quite sure if we are currently allowed to accept such changes.

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.

3 participants