How to capture DB.USER - Githubissues

open-telemetry / semantic-conventions

Defines standards for generating consistent, accessible telemetry across a variety of domains

Apache License 2.0

224 stars 141 forks source link

How to capture DB.USER #1142

Open jerry-shao opened 1 month ago

jerry-shao commented 1 month ago

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 commented 1 month ago

cc @open-telemetry/semconv-db-approvers

lmolkova commented 1 month ago

@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 commented 3 weeks ago

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 commented 3 weeks ago

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.