-
Notifications
You must be signed in to change notification settings - Fork 894
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
Revise and extend semantic conventions for databases #575
Conversation
@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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yurishkuro ping ^^^
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| `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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"`. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
|
Co-Authored-By: Christian Neumüller <[email protected]>
… of well-known identifiers
| `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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: Christian Neumüller <[email protected]>
@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. |
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. |
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.
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.
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.