-
Notifications
You must be signed in to change notification settings - Fork 959
Added instrumentation for transaction commit/rollback in jdbc #13709
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
Added instrumentation for transaction commit/rollback in jdbc #13709
Conversation
To enable trace when transaction commit or rollback in jdbc under experimental flag.
…nstrumentation into feat/jdbc-txn-instrumentation
…nstrumentation into feat/jdbc-txn-instrumentation
public Stream<? extends Arguments> provideArguments(ExtensionContext context) { | ||
return Stream.of( | ||
Arguments.of("COMMIT", expect("COMMIT", null)), | ||
Arguments.of("commit", expect("COMMIT", null)), |
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.
might as well test some of
xa commit
https://dev.mysql.com/doc/refman/8.4/en/xa-statements.html
commit work
https://www.ibm.com/docs/en/informix-servers/14.10.0?topic=statements-commit-work-statement
commit tran
https://learn.microsoft.com/en-us/sql/t-sql/language-elements/commit-transaction-transact-sql?view=sql-server-ver16
commit prepared
https://www.postgresql.org/docs/current/sql-commit-prepared.html
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 dropped it - commit/rollback isn't part of the SQL statement parsing anymore.
instrumentation/jdbc/README.md
Outdated
| System property | Type | Default | Description | | ||
|---------------------------------------------------------|---------|---------|-------------------------------------------------------| | ||
| `otel.instrumentation.jdbc.statement-sanitizer.enabled` | Boolean | `true` | Enables the DB statement sanitization. | | ||
| `otel.instrumentation.jdbc.experimental.txn.enabled` | Boolean | `false` | Enables the experimental transaction 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.
Replace txn
with transaction
. I think the description could be changed to indicate that this option enables creation of spans for COMMIT
and ROLLBACK
operations. The current description doesn't really reveal what this instrumentation does.
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.
Fixed.
...src/main/java/io/opentelemetry/javaagent/instrumentation/jdbc/ConnectionInstrumentation.java
Outdated
Show resolved
Hide resolved
equalTo(DB_STATEMENT, emitStableDatabaseSemconv() ? null : "COMMIT"), | ||
equalTo(DB_QUERY_TEXT, emitStableDatabaseSemconv() ? "COMMIT" : null), |
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.
imo you shouldn't fill the query, you don't really know what the jdbc driver executes for commit
operation
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 considered it but there's an issue: the span name extractor uses the query text to compute the span name. I see three possible solutions:
- Add a new separate field to the request struct for the operation name.
- Add a special check in the JDBC attributes getter to specifically handle commit and rollback operations.
- Do nothing. Commit semantics differ across drivers, but since we add an attribute with the system information and consumers know which driver they’re using, this might be acceptable.
WDYT?
P.S. Also we could create new instrumenter but it's too much I think
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.
The description for db.query.text only mentions The database query being executed
and some things about sanitization. As far as I can tell it does not allow for substituting the original query with another one.
Also we could create new instrumenter but it's too much I think
We sometimes do this for instrumentations that are not enabled by default. Then we can use setEnabled
on the instrumenter to control whether it is enabled or not.
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.
Added a new transaction instrumenter. A bit more code, but it's consistent with the docs now. WDYT?
private static final boolean TXN_ENABLED = | ||
ConfigPropertiesUtil.getBoolean("otel.instrumentation.jdbc.experimental.txn.enabled", false); |
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.
should be configured in JdbcTelemetryBuilder
using a setter and also in OpenTelemetryDriver
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.
Fixed.
…nstrumentation into feat/jdbc-txn-instrumentation
- fix review comments - add seperate transaction instrumenter
ad17c0e
to
fb22764
Compare
…nstrumentation into feat/jdbc-txn-instrumentation
...ary/src/main/java/io/opentelemetry/instrumentation/jdbc/datasource/JdbcTelemetryBuilder.java
Outdated
Show resolved
Hide resolved
...src/main/java/io/opentelemetry/javaagent/instrumentation/jdbc/ConnectionInstrumentation.java
Outdated
Show resolved
Hide resolved
.../test/java/io/opentelemetry/javaagent/instrumentation/jdbc/test/JdbcInstrumentationTest.java
Outdated
Show resolved
Hide resolved
Statement selectStatement = connection.createStatement(); | ||
cleanup.deferCleanup(selectStatement); | ||
ResultSet resultSet = selectStatement.executeQuery("SELECT COUNT(*) FROM " + tableName); | ||
resultSet.next(); | ||
assertThat(resultSet.getInt(1)).isEqualTo(0); |
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 suspect that this could cause test flakiness. executeQuery
creates a span but since it is not asserted there is a possibility that the span arrives after the test has completed and exported data is reset before the next test. If that happens the next test will fail because there is an unexpected span. You could work around this by calling testing.clearData();
before this code (to clear the existing trace) and testing.waitForTraces(1);
after this code to ensure that trace data gets cleared before the next test.
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 dropped these asserts since they're irrelevant to the test (we don't check rollback functionality).
PeerServiceAttributesExtractor.create( | ||
transactionNetAttributesGetter, | ||
AgentCommonConfig.get().getPeerServiceResolver())) | ||
.addOperationMetrics(DbClientMetrics.get()) |
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.
addOperationMetrics(DbClientMetrics.get())
is responsible for creating metrics, you probably should not add it to the transaction isntrumenter
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.
Fixed.
.addOperationMetrics(DbClientMetrics.get()) | ||
.buildInstrumenter(SpanKindExtractor.alwaysClient()); | ||
|
||
TRANSACTION_INSTRUMENTER = | ||
Instrumenter.<TransactionRequest, Void>builder( |
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.
could try to reuse the code in JdbcInstrumenterFactory
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 so, because we use PeerServiceAttributesExtractor
, which is agent-specific.
Hello @laurit, |
Contribute for #10381
To enable trace when transaction commit or rollback in jdbc under experimental flag.