Add RabbitMQ `message.header` attributes to semantic conventions

[samimusallam]

What are you trying to achieve?

I want to add RabbitMQ message header attributes in consumer spans to the semantic conventions. The value of adding the message headers is to help users get more information from the traces which could allow for easier troubleshooting. Since headers may contain sensitive data, we should require an explicit configuration of which headers are to be captured.

I propose the following naming for the attributes:

messaging.rabbitmq.message.header.<key>

[arminru]

It's worth mentioning that having individual attributes ending with they respective name of the key as proposed would also be consistent to how it's already done for HTTP and gRPC: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/http.md#http-request-and-response-headers https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/rpc.md#grpc-request-and-response-metadata

[carlosalberto]

Wondering whether this attributes would be something that could be shared with other messaging systems (or even some top level component). We need expertise at least in the messaging section, in case we indeed can share headers semantic conventions.

[samimusallam]

Wondering whether this attributes would be something that could be shared with other messaging systems (or even some top level component). We need expertise at least in the messaging section, in case we indeed can share headers semantic conventions.

I agree! but I'm not very familiar with other messaging systems, so maybe someone with more experience can weigh in?

[joaopgrassi]

Hey @samimusallam

There is a group working on messaging semantic convention and one of the focus is on attributes. The group has a meeting that happens every Every Thursday at 8:00 PT. It would be great if you could join and present this use case to the group so we have a better understanding of what you want to achieve. There we could also try to answer the question @carlosalberto raised if this could be re-used for other systems.

You could also start a discussion on the messaging slack channel https://cloud-native.slack.com/archives/C01QZFGMLQ7. The agenda and meeting notes can be found here: https://github.com/open-telemetry/community#specification-sigs (Instrumentation: Messaging)

[pyohannes]

We discussed this in today's messaging workgroup meeting.

We see value in adding messaging system specific headers as proposed in this issue (e. g. messaging.rabbitmq.message.header.<key>).

However, we'd like to avoid a generic messaging.message.header.<key> approach for two main reasons.

1. To avoid duplication and ambiguity in the top-level message namespace. We prefer to capture attributes common to several messaging systems in well-defined generic attributes in the top-level namespace, which at the same time should stay as lean as possible (without requirements regarding configuration and security).
2. The concept of "headers" is not unambiguously applicable to messaging systems, neither as term nor as concept. Some call it "metadata", "properties", or "annotations". The meaning of those is specific to each system (some come from the broker, some from the application layer, some from the transport layer ...). So it makes more sense to give individual messaging systems the means to define this in a way reflects the proper semantics, instead of forcing it all into a "header" namespace.

[samimusallam]

We discussed this in today's messaging workgroup meeting.

We see value in adding messaging system specific headers as proposed in this issue (e. g. messaging.rabbitmq.message.header.<key>).

However, we'd like to avoid a generic messaging.message.header.<key> approach for two main reasons.

1. To avoid duplication and ambiguity in the top-level message namespace. We prefer to capture attributes common to several messaging systems in well-defined generic attributes in the top-level namespace, which at the same time should stay as lean as possible (without requirements regarding configuration and security).
2. The concept of "headers" is not unambiguously applicable to messaging systems, neither as term nor as concept. Some call it "metadata", "properties", or "annotations". The meaning of those is specific to each system (some come from the broker, some from the application layer, some from the transport layer ...). So it makes more sense to give individual messaging systems the means to define this in a way reflects the proper semantics, instead of forcing it all into a "header" namespace.

Thank you for the update! If messaging.rabbitmq.message.header.<key> satisfies (for RabbitMQ only), there is no need from my side to add it to other messaging systems.