Alignment with gRPC conventions

[mx-psi]

Area(s)

area:rpc

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

The gRPC project has designed its own set of metrics and attributes. There is some overlap with existing gRPC attributes (compare our attributes with gRPC attributes). Users get frustrated since we are not consistent with each other, e.g. see open-telemetry/opentelemetry-go-contrib/issues/6093.

Describe the solution you'd like

Adopt gRPC conventions as the 'official' conventions for modelling gRPC. Consider contributing upstream anything that is missing.

Describe alternatives you've considered

Some other sort of collaboration with gRPC that leads to alignment

Additional context

No response

[pellared]

CC @dfawley @aranjans

[lmolkova]

thanks for raising it!

This is a perfect use-case for multi-registry. If we supported it, the grpc metrics could be defined and owned by grpc community and OTel could reference them.

As of recently, we don't recommend hosting external conventions in this repo

semantic-conventions/CONTRIBUTING.md

Lines 74 to 77 in e2f8527

	- Instrumentations that follow external schema not fully compatible with OpenTelemetry such as
	[Kafka client JMX metrics](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/v2.10.0/instrumentation/kafka/kafka-clients/kafka-clients-2.6/library/README.md)
	or [RabbitMQ Collector Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.116.0/receiver/rabbitmqreceiver)
	SHOULD document such conventions in their own repository.

and I think grpc ones fall into this bucket - they don't extend otel conventions and, even though they look great, they are not consistent with how we'd define them. E.g. we use server.address|port and other network attributes and grpc ones only use grpc.target which looks like the biggest and a major inconsistency to me.

We don't have anyone actively working on grpc semantic conventions at the moment, but this issue should definitely be a blocker for grpc stabilization and we'll need to decide what to do here. We should figure out how to have one set of conventions.