Avoid using gRPC when generic RPC systems have same properties

[bogdandrutu]

The concept of "streaming" is supported by multiple protocols including gRPC, but also others.

Signed-off-by: Bogdan Drutu bogdandrutu@gmail.com

[jsuereth]

Think this may need a telemetry schema update cc @tigrannajaryan

[bogdandrutu]

@jsuereth no idea since the JSON was added after the last release, only change is that the event applies to all RPC systems :D which I have no idea how to define in schema url change :D

[tigrannajaryan]

Think this may need a telemetry schema update cc @tigrannajaryan

I do no think this needs a schema update. If I understand correctly this change says that a source that previously was not emitting the event should now do so (i.e. all RPCs, not just gRPC).

There are no changes in the attribute names or values so the schema does not change in any way.

[bogdandrutu]

@open-telemetry/specs-approvers @open-telemetry/specs-trace-approvers @open-telemetry/technical-committee all comments are addressed, if no more comments in the next 24h we will merge this.

[Oberon00]

Actually, I have one more question about this: The message.id attribute has a very specific definition. Does that make sense for RPC generally? Did it even make sense for gRPC? Should we (temporarily) mark it as deprecated until we decide if it makes sense?

[jsuereth]

@Oberon00 The message.id thing is for streaming RPCs and is the current status quo for gRPC instrumentation See: https://github.com/census-instrumentation/opencensus-specs/blob/master/trace/gRPC.md#message-events

[Oberon00]

Then maybe that property should be kept as rpc.grpc.message.id?

[jsuereth]

I'd be ok with keeping things grpc specific when we're not sure if it applies to non gRPC systems.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[carlosalberto]

I'd be ok with keeping things grpc specific when we're not sure if it applies to non gRPC systems.

@bogdandrutu ^ ?

[bogdandrutu]

@Oberon00 @jsuereth without the ID you cannot map sent with received messages in a streaming RPC, which is one of the critical property to be able to determine network delays, etc. I think it should be a very generic property for any streaming implementation not just gRPC.

[Oberon00]

without the ID you cannot map sent with received messages

Well we need some ID, but maybe not one generated in exactly that way. Some RPC systems may already have an ID.