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.

Sign up for GitHub

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

Jump to bottom

Should db.system be db.system.name? #1581

Open
jack-berg opened this issue Nov 14, 2024 · 7 comments · May be fixed by #1613
Open

Should db.system be db.system.name? #1581

jack-berg opened this issue Nov 14, 2024 · 7 comments · May be fixed by #1613
Labels
area:db enhancement New feature or request triage:needs-triage

Comments

@jack-berg
Copy link
Member

Area(s)

area:db

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

As we approach stability, I wanted to throw out a question of whether we should rename db.system to db.system.name in order to preserve the ability to use db.system as a namespace.

I don't see any need to include other db.system.* attributes on metrics / spans. But supposing semantic conventions expand to database servers (e.g. resource conventions to represent a database server), its possible we might want to include other attributes along the lines of db.system.version.

Describe the solution you'd like

Consider renaming db.system to db.system.name.

Describe alternatives you've considered

No response

Additional context

No response
@jack-berg jack-berg added enhancement New feature or request triage:needs-triage labels Nov 14, 2024
@lmolkova
Copy link
Contributor

I have an arbitrary (and optional) rule of thumb for attribute names to follow {domain}.{thing}.{a property of the thing} pattern.

The db.system.name follows this pattern and if we defined it from the scratch, I'd prefer to add .name.

@maryliag
Copy link
Contributor

Agree that adding .name is a better option

@jack-berg
Copy link
Member Author

I can open a PR. Can a maintainer assign it to me?

@trask
Copy link
Member

trask commented Nov 22, 2024 •
edited
Loading

@lmolkova and I added this to Monday's semconv meeting to get more feedback since it would affect several semantic conventions

  • db.system
  • messaging.system
  • rpc.system
  • gen_ai.system
  • feature_flag.system

@dyladan
Copy link
Member

dyladan commented Nov 25, 2024

Discussed (very) briefly with feature flag sig and nobody had an objection

@dyladan
Copy link
Member

dyladan commented Nov 25, 2024

I think this change might be a good way to future proof against entities in the future. Assuming we will want to use the same dictionary of attributes for entities, we might have things like system version, region, etc for entities in the future.

@lmolkova lmolkova linked a pull request Nov 26, 2024 that will close this issue
Open
3 tasks
@dyladan dyladan mentioned this issue Nov 26, 2024
Merged
3 tasks
@SylvainJuge SylvainJuge mentioned this issue Dec 2, 2024
Open
@trask
Copy link
Member

trask commented Dec 7, 2024

I have an arbitrary (and optional) rule of thumb for attribute names to follow {domain}.{thing}.{a property of the thing} pattern.

an interesting exception to this rule appears to be db.namespace and code.namespace (not any problem, just wanted to drop a note about it)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area:db enhancement New feature or request triage:needs-triage
Projects
Database Client Semantic Conventions
Status: No status
Milestone
No milestone
5 participants
@trask @maryliag @dyladan @lmolkova @jack-berg