Asynchronous messaging span attributes #395
Conversation
|
|
||
| | Attribute name | Notes and examples | Required? | | ||
| | :------------- | :----------------------------------------------------------- | --------- | | ||
| | `message_bus.destination` | An address at which messages can be exchanged. E.g. A Kafka record has an associated "topic name" that can be extracted by the instrumented producer or consumer and stored using this tag. | Yes | |
There was a problem hiding this comment.
I feel like message_bus could be shortened to message.
There was a problem hiding this comment.
Also, what is a message bus? In my understanding there are message queues (anycast) and topics (broadcast). A bus sounds like something used to implement a topic.
There was a problem hiding this comment.
This lingo comes over from OpenTracing: https://github.com/opentracing/specification/blob/master/semantic_conventions.md#message-bus
I'm fine with calling it message though one could argue that is too vague.
|
|
||
| | Attribute name | Notes and examples | Required? | | ||
| | :------------- | :----------------------------------------------------------- | --------- | | ||
| | `message_bus.destination` | An address at which messages can be exchanged. E.g. A Kafka record has an associated "topic name" that can be extracted by the instrumented producer or consumer and stored using this tag. | Yes | |
There was a problem hiding this comment.
This lingo comes over from OpenTracing: https://github.com/opentracing/specification/blob/master/semantic_conventions.md#message-bus
I'm fine with calling it message though one could argue that is too vague.
|
I would accept |
|
I am fine with |
|
|
||
| | Attribute name | Notes and examples | Required? | | ||
| | :------------- | :----------------------------------------------------------- | --------- | | ||
| | `message_bus.destination` | An address at which messages can be exchanged. E.g. A Kafka record has an associated "topic name" that can be extracted by the instrumented producer or consumer and stored using this tag. | Yes | |
There was a problem hiding this comment.
With the removal of the 'component' attribute, having at least one required attribute facilitates branching logic. I don't know of any use case where this value won't exist. It could be argued though that this would be used as the name of the span in most cases.
| | Attribute name | Notes and examples | Required? | | ||
| | :------------- | :----------------------------------------------------------- | --------- | | ||
| | `message_bus.destination` | An address at which messages can be exchanged. E.g. A Kafka record has an associated "topic name" that can be extracted by the instrumented producer or consumer and stored using this tag. | Yes | | ||
| | `message_bus.type` | The brand of message bus or client API library such as `"kafka"`, `"rabbitmq"` or `"jms"`. | Yes | |
There was a problem hiding this comment.
I think this should be name? Type does not sound like what the description suggests.
There was a problem hiding this comment.
I followed the same conventions as the database spec which uses db.type
There was a problem hiding this comment.
I think type in the db conventions refers more to the flavor of db like sql instead of a specific sql database. For instance mysql, postgresql, ms sql server, and sqlite may all have type = sql
| | `message_bus.destination` | An address at which messages can be exchanged. E.g. A Kafka record has an associated "topic name" that can be extracted by the instrumented producer or consumer and stored using this tag. | Yes | | ||
| | `message_bus.type` | The brand of message bus or client API library such as `"kafka"`, `"rabbitmq"` or `"jms"`. | Yes | | ||
| | `message_bus.protocol` | The transport protocol such as `"AMQP"` or `"MQTT"`. | No | | ||
| | `message_bus.user` | Username for accessing bus. E.g., `"tibuser1"` or `"consumer_user"`. | No | |
There was a problem hiding this comment.
Sorry not to much experience here, but who is the user in this case?
There was a problem hiding this comment.
This is the username the client uses to authenticate with the message bus instance. In other words, 'message_bus.user' is the equivalent of 'db.user'
There was a problem hiding this comment.
Why it is not peer.user I feel like we have too many users, and may better to standardize as peer or other category and use that everywhere.
|
Withdrawing because Dynatrace is getting ready to submit a more comprehensive specification covering this area. |
No description provided.