Replacement for messaging.kafka.source.partition?

[trask]

Messaging "source" attributes were removed in #100.

#156 introduced replacements for all of the attributes removed in #100, except for messaging.kafka.source.partition.

Ran into this while migrating Java Kafka instrumentation to semconv 1.21.0, and wondering if we should bring this attribute back also, e.g. as messaging.kafka.destination_publish.partition?

[lmolkova]

It should be messaging.kafka.destination.partition - both consumers and producers should report partition on destination namespace (which used to be split to source and destination depending on where it's reported).

destination_publish.partition might be used if consumer knowns not just the original destination message was published to, but also a partition. I guess it's quite a rare case.

[trask]

thx @lmolkova, this makes sense!

[joaopgrassi]

Should we leave it open, so we can track and re-add the attribute for Kafka? I see @pyohannes added to our v1 messaging project.

[trask]

Should we leave it open, so we can track and re-add the attribute for Kafka? I see @pyohannes added to our v1 messaging project.

we don't have any Java instrumentation that is able to report both destination and destination_publish. if there had been a destination_publish.partition we might have used it not realizing we shouldn't. maybe better to wait until a use case emerges for it?

[joaopgrassi]

But was it recording the old attribute before? Because if so, then we should I guess re-introduce the attribute under messaging.kafka.destination.partition. The other case I feel we don't know so fine leaving it out. (destination_publish.partition)

[trask]

messaging.kafka.destination.partition already exists: https://github.com/open-telemetry/semantic-conventions/blob/main/docs/messaging/kafka.md#span-attributes

[joaopgrassi]

Ah, great then. We could still re-open it and move it out of our V1 Stable semantics board, so we at least have a place holder to discuss it in case the need arrives. What do you think @pyohannes ?

[pyohannes]

I'd suggest to leave it as is for now.

Once a use case arises for it, we can open an issue and discuss. I don't think it's urgent for now, as it can be added later as a non-breaking addition.