Defined additional semantic convention attribute names #383
Conversation
|
I recommend splitting this PR up, e.g. the messaging changes probably deserve their own PR. |
| @@ -0,0 +1,43 @@ | |||
| # Semantic conventions for events | |||
There was a problem hiding this comment.
I would put the events to the places they belong to, e.g. message events to messaging conventions, error to general conventions, etc.
We also have status, name and attributes already bundled together and grpc has events right with the other conventions too.
There was a problem hiding this comment.
Message events apply to all types of remote calls, not only gRPC.
specification/data-events.md
Outdated
|
|
||
| Event `"name"` MUST be `"error"`. | ||
|
|
||
| Error events MAY be associated with a tracing span or recorded independently. |
There was a problem hiding this comment.
How can events be recorded independently? I do not think OpenTelemetry currently has a concept of free-standing event. AFAIK this is something that is planned to be added, but does not exist yet.
The API specification currently defines Events that can be associated with Spans: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/api-tracing.md#add-events
|
|
||
| | Attribute name | Notes and examples | Required? | | ||
| | :------------- | :----------------------------------------------------------- | --------- | | ||
| | `component` | Denotes the type of the span and needs to be `"bus"`. | Yes | |
There was a problem hiding this comment.
There is a proposal to remove "component" attribute: #336
Comments on that issue are welcome.
There was a problem hiding this comment.
It's a lot of different things to put in one PR. I wonder if the message_bus conventions should go in one PR, the Events conventions in another PR, the General Identity conventions in a PR, and then everything else in a cleanup PR?
The stuff about Events conventions raised some questions for me, but I'm worried about a lengthy PR thread w/ so much else in flight.
|
I will split up this pull request into multiple requests. |
Resolves #362