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

How to capture DB.USER #1142

Open
jerry-shao opened this issue Jun 11, 2024 · 6 comments
Open

How to capture DB.USER #1142

jerry-shao opened this issue Jun 11, 2024 · 6 comments
Labels
area:db enhancement New feature or request

Comments

@jerry-shao
Copy link

Area(s)

area:db

Is your change request related to a problem? Please describe.

Today, there is a db.user field under db namespace. However, a recent change proposed to mark the db.user as deprecated and add it back later once nested namespace is supported.

Describe the solution you'd like

Given db.user is currently being used by customers/venders, we would like to use this issue for tracking purpose to make sure db.user won't be removed without a replacement.

Describe alternatives you've considered

No response

Additional context

No response

@arminru
Copy link
Member

arminru commented Jun 11, 2024

cc @open-telemetry/semconv-db-approvers

@lmolkova
Copy link
Contributor

lmolkova commented Jun 11, 2024

@jerry-shao thank you for reporting this!

Could you please share some details:

  • what would be the use-case for db.user?
  • what information you'd want to see there?
  • is it related to a certain database or multiple database systems?

Thanks!

@trask
Copy link
Member

trask commented Jun 19, 2024

Discussed in June 19 SIG meeting.

Initially I thought we might use user.name, but this seems like it could lead to confusion about which user it's referring to when you see it on a database span (the end user or the database user).

We are thinking it likely makes sense to embed the user.name attribute under the db.* namespace in order to be able to support both on the same span.

I've added the topic to the next general semantic convention SIG meeting.

Note: if we do bring it back as db.user.name, we probably will keep it experimental in the initial stability since user.* namespace itself is still experimental.

@lmolkova
Copy link
Contributor

Related: #818

@lmolkova
Copy link
Contributor

lmolkova commented Jun 20, 2024

Also: #1172

It's common to access databases (in the cloud, in k8s with identity providers, etc) using non-human identities which can be called groups, roles, etc. Or with named/unnamed tokens.

It'd be difficult to describe all possible kinds of identities using user namespace:

  • e.g. MongoDB role name would match user.name? It'd be confusing to have user.roles[] as well.
  • would we need to define how all possible AWS IAM or Azure identities map to user for DynamoDB or ComsosDB?

It seems a new version of db.user should capture the identity used to authenticate on the database we need semantic conventions for identity in order to achieve it.

@trask
Copy link
Member

trask commented Jul 12, 2024

Discussed in DB semconv meeting this week. We are postponing until post-stabillity because we will likely want to align with user/identity namespace once that is stable.

We think that in most cases it is the db.namespace that users want to see (and often that will map 1-1 with database user in practice).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:db enhancement New feature or request
Projects
Status: Post Stability
Development

No branches or pull requests

5 participants