Skip to content

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

Merged
merged 15 commits into from
May 14, 2025

Conversation

stillya
Copy link
Contributor

@stillya stillya commented Apr 14, 2025

Contribute for #10381

To enable trace when transaction commit or rollback in jdbc under experimental flag.

To enable trace when transaction commit or rollback in jdbc under experimental flag.
@stillya stillya requested a review from a team as a code owner April 14, 2025 11:40
Copy link

linux-foundation-easycla bot commented Apr 14, 2025

CLA Signed

The committers listed above are authorized under a signed CLA.

@github-actions github-actions bot added the test native This label can be applied to PRs to trigger them to run native tests label Apr 14, 2025
public Stream<? extends Arguments> provideArguments(ExtensionContext context) {
return Stream.of(
Arguments.of("COMMIT", expect("COMMIT", null)),
Arguments.of("commit", expect("COMMIT", null)),
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

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.

| 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. |
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

Comment on lines 1691 to 1692
equalTo(DB_STATEMENT, emitStableDatabaseSemconv() ? null : "COMMIT"),
equalTo(DB_QUERY_TEXT, emitStableDatabaseSemconv() ? "COMMIT" : null),
Copy link
Contributor

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

Copy link
Contributor Author

@stillya stillya Apr 16, 2025

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:

  1. Add a new separate field to the request struct for the operation name.
  2. Add a special check in the JDBC attributes getter to specifically handle commit and rollback operations.
  3. 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

Copy link
Contributor

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.

Copy link
Contributor Author

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?

Comment on lines 54 to 55
private static final boolean TXN_ENABLED =
ConfigPropertiesUtil.getBoolean("otel.instrumentation.jdbc.experimental.txn.enabled", false);
Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

stillya added 2 commits April 23, 2025 01:37
- fix review comments
- add seperate transaction instrumenter
@stillya stillya force-pushed the feat/jdbc-txn-instrumentation branch from ad17c0e to fb22764 Compare April 27, 2025 18:49
@stillya stillya requested a review from laurit April 27, 2025 20:04
Comment on lines 1756 to 1760
Statement selectStatement = connection.createStatement();
cleanup.deferCleanup(selectStatement);
ResultSet resultSet = selectStatement.executeQuery("SELECT COUNT(*) FROM " + tableName);
resultSet.next();
assertThat(resultSet.getInt(1)).isEqualTo(0);
Copy link
Contributor

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.

Copy link
Contributor Author

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())
Copy link
Contributor

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

Copy link
Contributor Author

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(
Copy link
Contributor

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

Copy link
Contributor Author

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.

@stillya stillya requested a review from laurit April 28, 2025 15:20
@stillya
Copy link
Contributor Author

stillya commented May 5, 2025

Hello @laurit,
Mind taking another look? I think I’ve fixed all the comments above.

@laurit laurit added this to the v2.16.0 milestone May 9, 2025
@laurit laurit merged commit 97e5260 into open-telemetry:main May 14, 2025
87 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test native This label can be applied to PRs to trigger them to run native tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants