Pubsub client instrumentation

[samwright]

Is your feature request related to a problem? Please describe.

At my company we use Google Cloud PubSub a lot, and would like to create spans from sending and receiving messages.

Describe the solution you'd like

I have done this https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/10546

Describe alternatives you've considered

The pubsub client comes with OpenCensus support built-in, but without all the lovely otel attributes and features.

Additional context

A few things to note:

• I added a few attributes in PubsubAttributes, ideally these become part of semantic-conventions soon (I've linked to PRs in that class)
• The subscriber's receive span uses the publisher's create span as its parent. I don't mind changing that, or making it configurable to instead pointing to it using a SpanLink
• I made some choices about how to name topic/subscription, which should be discussed. What we get given are: projects/{{NAME_OF_GCP_PROJECT}}/topics/{{NAME_OF_TOPIC}} and projects/{{NAME_OF_GCP_PROJECT}}/subscriptions/{{NAME_OF_SUBSCRIPTION}}, which are good for uniqueness but IMO a bit too long for a span name, but also isn't quite the right format for cloud.resource_id.

Here are the spans created when publishing and receiving a message:

Field or Attribute	Span Batch	Span Create	Span Receive
Span name	my-topic publish	my-topic create	my-subscriber receive
Parent			my-topic create
Links	my-topic create
SpanKind	CLIENT	PRODUCER	CONSUMER
cloud.resource_id	"//pubsub.googleapis.com/projects/my-project/topics/my-topic"	"//pubsub.googleapis.com/projects/my-project/topics/my-topic"	"//pubsub.googleapis.com/projects/my-project/subscriptions/my-subscription"
messaging.system	"gcp_pubsub"	"gcp_pubsub"	"gcp_pubsub"
messaging.operation	"publish"	"create"	"receive"
messaging.destination.name	"my-topic"	"my-topic"
messaging.client_id			"my-subscription"
messaging.batch.message_count	1
messaging.gcp_pubsub.message.ordering_key		"my-key" [1]	"my-key" [1]
messaging.message.body.size		1024	1024
messaging.message.envelope.size			1234
messaging.message.id			"abc123"
messaging.gcp_pubsub.message.ack_result			"ack" [2]

[1] Attribute is not present if there is no ordering key

[2] The message receiver can either:

1. choose to acknowledge the message (attribute is "ack"),
2. choose to not acknowledge the message (attribute is "nack"),
3. not do either (attribute is not set)

[trask]

@samwright does it make sense to close this based on your https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/10546#issuecomment-1949907812?

The python and java clients will get native support for otel (see comment), so no need to carry on with this PR

[samwright]

Yes, sorry I meant to close this ticket but forgot about it. I'm looking forward to official otel support in the pubsub clients!