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

Revise and extend semantic conventions for databases #575

Merged
merged 18 commits into from
Jul 1, 2020

Conversation

arminru
Copy link
Member

@arminru arminru commented Apr 23, 2020

We revised and extended the semantic conventions for database client calls that were initially copied over from OpenTracing by making definitions more precise and adding technology-specific attributes.
This should lead to improved data quality and allow better identification of databases and analysis of calls made to them.

Resolves #245.

@arminru
Copy link
Member Author

arminru commented May 26, 2020

@carlosalberto Thanks for the review!

@open-telemetry/specs-approvers Anyone else willing to have a look? 🙂

| `net.peer.port` | Defined in the general [network attributes][]. | See below |
| `net.transport` | Defined in the general [network attributes][]. | See below |

At least one of `net.peer.name` or `net.peer.ip` from the [network attributes][] is required and `net.peer.port` is recommended.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think any of these can be required. Instrumentation may not know any of that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

- Additionally at least one of `net.peer.name` or `net.peer.ip` from the [network attributes][] is required and `net.peer.port` is recommended.
+ At least one of `net.peer.name` or `net.peer.ip` from the [network attributes][] is required and `net.peer.port` is recommended.

This requirement was already there before, I just added the attributes to the table so they're not overlooked that easily.
An instrumentation should be able to capture it, otherwise there will only be little value if the database is unknown. In which cases would it not know about that, given that we expect instrumentation to be built-in into the database client library?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yurishkuro ping ^^^

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After #653, maybe this can be updated in a follow-up (or as part of #653). As of now, it seems there is not much point in bikeshedding over required vs recommended.

| `net.transport` | Defined in the general [network attributes][]. | See below |

At least one of `net.peer.name` or `net.peer.ip` from the [network attributes][] is required and `net.peer.port` is recommended.
If using a port other than the default port for this DBMS, `net.peer.port` is required.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instrumentation may not know anything about ports.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yurishkuro see the response to your comment above #575 (comment)

At least one of `net.peer.name` or `net.peer.ip` from the [network attributes][] is required and `net.peer.port` is recommended.
If using a port other than the default port for this DBMS, `net.peer.port` is required.
Furthermore, it is strongly recommended to add the [`net.transport`][] attribute and follow its guidelines.
For in-process databases, `net.transport` MUST be set to `"inproc"`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

knowledge of in-process vs. external DB my be abstracted away from instrumentation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yurishkuro see the response to your comment above #575 (comment)

@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Jun 8, 2020

CLA Check
The committers are authorized under a signed CLA.

@arminru arminru added the area:semantic-conventions Related to semantic conventions label Jun 8, 2020
@arminru arminru added the spec:trace Related to the specification/trace directory label Jun 15, 2020
specification/trace/semantic_conventions/database.md Outdated Show resolved Hide resolved
specification/trace/semantic_conventions/database.md Outdated Show resolved Hide resolved
specification/trace/semantic_conventions/database.md Outdated Show resolved Hide resolved
specification/trace/semantic_conventions/database.md Outdated Show resolved Hide resolved
| `net.peer.port` | Defined in the general [network attributes][]. | See below |
| `net.transport` | Defined in the general [network attributes][]. | See below |

At least one of `net.peer.name` or `net.peer.ip` from the [network attributes][] is required and `net.peer.port` is recommended.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After #653, maybe this can be updated in a follow-up (or as part of #653). As of now, it seems there is not much point in bikeshedding over required vs recommended.

specification/trace/semantic_conventions/database.md Outdated Show resolved Hide resolved
specification/trace/semantic_conventions/database.md Outdated Show resolved Hide resolved
specification/trace/semantic_conventions/database.md Outdated Show resolved Hide resolved
@arminru arminru requested a review from a team June 29, 2020 17:04
@arminru
Copy link
Member Author

arminru commented Jun 29, 2020

@open-telemetry/specs-approvers @open-telemetry/specs-trace-approvers Any more reviews or are we good to merge this? People have had the chance to take a look for more than two months now.

@carlosalberto
Copy link
Contributor

I think we are ready to merge this PR (we can always iterate on it later on, if we find we indeed need any refinement). I suggest waiting one day for @bogdandrutu and @yurishkuro to comment on this (as they had issues with this PR). And by EOD Tuesday merge otherwise.

@carlosalberto carlosalberto merged commit 6c86748 into open-telemetry:master Jul 1, 2020
codeboten pushed a commit to codeboten/opentelemetry-specification that referenced this pull request Jul 20, 2020
johnchildren added a commit to johnchildren/opentelemetry-application-insights that referenced this pull request Aug 6, 2020
Release v0.6.0 of the opentelemetry spec included some changes to the
database semantic conventions, among them being changes to some of the
fields used to convert to Azure Dependency Targets etc.

open-telemetry/opentelemetry-specification#575

This commit updates the exporter to handle the new names for these
fields, however as the new equivalent to `db.instance` is `db.name`,
which can change when the database is changed inside a connection.
johnchildren added a commit to johnchildren/opentelemetry-application-insights that referenced this pull request Aug 7, 2020
Release v0.6.0 of the opentelemetry spec included some changes to the
database semantic conventions, among them being changes to some of the
fields used to convert to Azure Dependency Targets etc.

open-telemetry/opentelemetry-specification#575

This commit updates the exporter to handle the new names for these
fields, however as the new equivalent to `db.instance` is `db.name`,
which can change when the database is changed inside a connection.
@arminru arminru deleted the semconv-db branch September 17, 2020 12:44
carlosalberto pushed a commit to carlosalberto/opentelemetry-specification that referenced this pull request Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:semantic-conventions Related to semantic conventions spec:trace Related to the specification/trace directory
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Semantic convention for database driver name needed
7 participants