-
Notifications
You must be signed in to change notification settings - Fork 293
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
[Instrumentation.EntityFrameworkCore] Update semantic conventions for stable release #2130
[Instrumentation.EntityFrameworkCore] Update semantic conventions for stable release #2130
Conversation
…with latest Semantic Conventions
src/OpenTelemetry.Instrumentation.EntityFrameworkCore/CHANGELOG.md
Outdated
Show resolved
Hide resolved
src/OpenTelemetry.Instrumentation.EntityFrameworkCore/CHANGELOG.md
Outdated
Show resolved
Hide resolved
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
@joegoldman2, if you want to proceed with this PR, please consider https://github.com/open-telemetry/semantic-conventions/blob/main/docs/non-normative/db-migration.md There were semantic convention helper for HTTP in main repository. It can be easily adjusted: https://github.com/open-telemetry/opentelemetry-dotnet/pull/5270/files#diff-c94fc23f1212ef9513764dd888ec8c98d2d59b2d51a0aabb311fa0652ec8b059 Keep in mind that network related attributes can be fixed now, the problem is only with SQL releated part. |
I tested the change manually on a test app, it is working. |
...etry.Instrumentation.EntityFrameworkCore/Implementation/EntityFrameworkDiagnosticListener.cs
Show resolved
Hide resolved
|
||
if (this.options.EmitNewAttributes) | ||
{ | ||
activity.AddTag(AttributeDbNamespace, database); |
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.
@trask @lmolkova what are your thoughts here?
Per footnote 4 in the conventions:
Semantic conventions for individual database systems SHOULD document what db.namespace means in the context of that system.
Since this instrumentation is for an ORM and supports many database systems, this would ideally respect the conventions declared for the target database system though I don't know if that will be possible.
Also not all systems this instrumentation supports have documentation for what db.namespace
means.
Thoughts on ORMs in general?
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.
we have a similar issue in Java (https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/jdbc/library/src/test/java/io/opentelemetry/instrumentation/jdbc/internal/JdbcConnectionUrlParserTest.java)
technically, I think stable JDBC instrumentation should only emit stable instrumentation by default, which means only emitting instrumentation for stable db.system
values
in practice, this would mean that we can't mark the JDBC instrumentation as stable even after we update it to emit the stable database semconv (unless we want to force lots of users to opt-in to the unstable db.system
values, which I don't think is a great experience)
I'm hoping this will motivate us to push semconv definitions for db.namespace
for all of these other databases quickly, we just haven't had the bandwidth to do it yet and didn't want to block initial database semconv stability on it
...Telemetry.Instrumentation.EntityFrameworkCore.Tests/DatabaseSemanticConventionHelperTests.cs
Outdated
Show resolved
Hide resolved
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.
This PR looks good to me. There's still things left to do, but I think this is a step forward, so approving/merging.
I will open issues, but here's a quick summary off hand for things left to do:
- Collecting additional attributes
error.type
/db.response.status_code
- Adding option to parse
db.collection.name
/db.operation.name
(this is something I'm working on in the context of the SQL instrumentation and should also be applicable here)
- Adding option to sanitize
db.query.text
(also working on this for SQL instrumentation) - Defining our requirements for declaring this instrumentation stable. It's an ORM, so it may have some unique things to think through see [Instrumentation.EntityFrameworkCore] Update semantic conventions for stable release #2130 (comment)
Changes
Add support for
OTEL_SEMCONV_STABILITY_OPT_IN
following https://github.com/open-telemetry/semantic-conventions/blob/main/docs/non-normative/db-migration.md.Merge requirement checklist
CHANGELOG.md
files updated for non-trivial changes