Skip to content
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

Fixes and options for gRPC instrumentation #13443

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

luke-sterkowicz
Copy link

  • Fix for having message IDs for SENT and RECEIVED separately, as per https://opentelemetry.io/docs/specs/semconv/attributes-registry/rpc/
  • Add new experimental properties grpc.messages.received and grpc.messages.sent for providing message counts.
  • Add configuration option otel.instrumentation.grpc.message-events for disabling span events for idividual messages.

Closes #13368

@luke-sterkowicz luke-sterkowicz requested a review from a team as a code owner March 3, 2025 14:50
Copy link

linux-foundation-easycla bot commented Mar 3, 2025

CLA Signed

The committers listed above are authorized under a signed CLA.

@luke-sterkowicz luke-sterkowicz force-pushed the grpc_count_for_messages branch from 377fe79 to 60dbca4 Compare March 4, 2025 15:19
@@ -2,6 +2,7 @@

| System property | Type | Default | Description |
|-------------------------------------------------------------|---------|---------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `otel.instrumentation.grpc.message-events` | Boolean | `true` | Determines whether to add span event for each individual message received and sent. Set this to false in case of streaming large volumes of messages. |
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd use otel.instrumentation.grpc.emit-message-events @trask should there also be experimental in the property name?
I'd change the description to use less opinionated language.

Copy link
Author

Choose a reason for hiding this comment

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

Thanks. Fixed the name and description. I think using experimental could suggest that the events are experimental maybe (which is not true)?

Copy link
Member

Choose a reason for hiding this comment

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

@trask should there also be experimental in the property name?

good question, I'm really not sure 😅, I opened #13487, but I think not having experimental in this property is probably the most consistent with the current (inconsistent) usage

Copy link
Contributor

@breedx-splk breedx-splk left a comment

Choose a reason for hiding this comment

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

Looks like a helpful expansion for gRPC users. Thanks.

@laurit laurit added this to the v2.14.0 milestone Mar 7, 2025
Comment on lines 30 to 33
private static final AttributeKey<Long> GRPC_MESSAGES_RECEIVED =
AttributeKey.longKey("grpc.messages.received");
private static final AttributeKey<Long> GRPC_MESSAGES_SENT =
AttributeKey.longKey("grpc.messages.sent");
Copy link
Member

Choose a reason for hiding this comment

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

I think this naming would be a bit consistent with existing semantic conventions:

  • grpc.received.message_count
  • grpc.sent.message_count

can you open an issue in https://github.com/open-telemetry/semantic-conventions/issues to propose these two?

the semconv folks probably won't get to it for a bit since not actively working on rpc/grpc at the moment, but will be good to get it into the backlog for when they do

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.

Switch from gRPC message-based instrumentation to transaction-based (streaming)
4 participants