Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Messaging: do we need messaging.destination.temporary and/or messaging.destination.anonymous attributes? #1126

Open
lmolkova opened this issue Jun 5, 2024 · 1 comment

Comments

@lmolkova
Copy link
Contributor

lmolkova commented Jun 5, 2024

messaging.destination.temporary - A boolean that is true if the message destination is temporary and might not exist anymore after messages are processed.

messaging.destination.anonymous - A boolean that is true if the message destination is anonymous (could be unnamed or have auto-generated name).

  • do we need both attributes? what's the difference? Can we merge them into one?
  • do we need any of these attributes? The only information they convey is that destination name could have high cardinality. Do we need to record it as attributes?
  • do we have a reliable way to detect temporary/anonymous destinations in auto-instrumentations?

I think we should start with excluding them from the stability scope.

@github-project-automation github-project-automation bot moved this to V1 - Stable Semantics in Spec: Messaging Semantics Jun 5, 2024
@lmolkova lmolkova moved this from V1 - Stable Semantics to In Triage in Spec: Messaging Semantics Jun 5, 2024
@pyohannes
Copy link
Contributor

  • do we need both attributes? what's the difference? Can we merge them into one?

I'd be against merging them. The two attributes have a clearly defined meaning, I don't think we gain much by replacing them with a single attribute that has a vague meaning.

  • do we need any of these attributes? The only information they convey is that destination name could have high cardinality. Do we need to record it as attributes?

If I remember correctly, @dpauls was a proponent of these attributes. Maybe he can give some use cases?

  • do we have a reliable way to detect temporary/anonymous destinations in auto-instrumentations?

I don't think there's a 100% reliable way to detect this across libraries and systems. However, we assume in the conventions that instrumentation authors can know whether a destination name is of high or low cardinality (because depending on this the destination name is used on metrics and in the span name), and we also assume that names of temporary or anonymous destinations are of high cardinality.

So, I don't think there's a reliable way, but it will be a best-effort approach.

I think we should start with excluding them from the stability scope.

I'm fine with that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Post-stability
Development

No branches or pull requests

3 participants