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

feat (sequel): Initial Sequel instrumentation #672

Closed

Conversation

jrgns
Copy link

@jrgns jrgns commented Sep 24, 2023

OpenTelemetry Instrumentation for the Sequel Database Toolkit.

This can be used instead of DB specific instrumentations.

@jrgns jrgns force-pushed the feat/sequel-instrumentation branch 3 times, most recently from 72c7f14 to 88afa84 Compare September 24, 2023 14:16
@jrgns jrgns changed the title feat: Initial Sequel instrumentation feat (sequel): Initial Sequel instrumentation Sep 24, 2023
@jrgns jrgns marked this pull request as ready for review September 24, 2023 14:23
@arielvalentin arielvalentin added instrumentation help wanted Extra attention is needed labels Sep 24, 2023
@arielvalentin
Copy link
Collaborator

@jrgns Thank you for your contribution!

I will try to give this a review later this week but I have a few questions for you before we begin the process:

Are you a member of the OTel GitHub Organization?

Are you willing to commit to providing on-going maintenance for this instrumentation? E.g. Review PRs, Fix Vulnerabilities, Maintain Version Compatibility, etc...

@jrgns
Copy link
Author

jrgns commented Sep 24, 2023

Hey @arielvalentin

No, I'm not part of the OTel Github Org

Yes. I'm willing to commit to maintenance etc.

@jrgns jrgns force-pushed the feat/sequel-instrumentation branch from 88afa84 to 7eecb44 Compare September 24, 2023 15:47
@arielvalentin
Copy link
Collaborator

@jrgns looks like the generator added the unreleased instrumentation gem as a dependency in all.

Please remove it from all an I'll create a follow up PR to include it once we have a release of this gem published in rubygems.

@jrgns jrgns force-pushed the feat/sequel-instrumentation branch 3 times, most recently from 702ca41 to 3f9feb2 Compare September 24, 2023 20:04
@jrgns
Copy link
Author

jrgns commented Sep 24, 2023

@arielvalentin check it now?

@arielvalentin
Copy link
Collaborator

@jrgns I will take a look tomorrow during US business hours

Copy link
Collaborator

@arielvalentin arielvalentin left a comment

Choose a reason for hiding this comment

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

I have left a few comments for you to review with some requested changes. Please be patient as I am not familiar with the Sequel gem and will need your help digging into some specifics about how extensions work.

Thanks again for this contribution!

@jrgns jrgns force-pushed the feat/sequel-instrumentation branch 3 times, most recently from cf5cee9 to 9c2fda4 Compare September 27, 2023 20:03
@kaylareopelle
Copy link
Contributor

@jrgns - My apologies, I forgot to follow up on the CI/release documents in my earlier review.

Could you add your gem to the following files?

.github/workflows/ci-instrumentation-canary.yml
.github/workflows/ci-instrumentation.yml
.toys/.data/releases.yml

This should allow your sequel suite to run as part of the CI checks and will allow the gem to eventually be released. Unfortunately, these file updates aren't included automatically in the instrumentation generator.

exporter.reset
end

describe 'tracing' do
Copy link
Collaborator

Choose a reason for hiding this comment

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

The tests do not seem very specific to me or help me understand as an end user what I should expect to see on a span when I use this.

The tests for traces dataset executes e.g. may continue to pass even though the span does not have the data we expect.

May I ask that you expand on these tests (although it may seem verbose) to include assertions around the spans that were captured?

E.g. name, kind, attributes, if any events where captured etc..

Copy link
Author

Choose a reason for hiding this comment

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

I've made some changes, but will expand it even further.

@jrgns jrgns force-pushed the feat/sequel-instrumentation branch 2 times, most recently from d2fa547 to 476a85c Compare October 12, 2023 19:39
@jrgns
Copy link
Author

jrgns commented Oct 12, 2023

@kaylareopelle I've added the gem to the CI files.

@jrgns
Copy link
Author

jrgns commented Oct 21, 2023

@arielvalentin anything else you need on this?

@jrgns jrgns force-pushed the feat/sequel-instrumentation branch from 476a85c to 88b72f3 Compare October 29, 2023 15:22
@jrgns jrgns requested a review from simi as a code owner October 29, 2023 15:22
@jrgns jrgns requested a review from a team October 29, 2023 15:22
@jrgns
Copy link
Author

jrgns commented Oct 29, 2023

@kaylareopelle @arielvalentin changes made.

@jrgns jrgns force-pushed the feat/sequel-instrumentation branch from 88b72f3 to f24d7f2 Compare October 29, 2023 15:25
@kaylareopelle
Copy link
Contributor

Thanks, @jrgns! It looks like the sequel tests are failing with JRuby. The CI skips JRuby for Active Record, so perhaps it should be skipped for Sequel too.

On Sequel's homepage, it seems like the gem should be compatible with JRuby, but I think we might to install the JBDC adapter test environment to make it work.

@arielvalentin, I'm not aware of the OTel Ruby policy that drives JRuby testing for instrumentation. Can you provide some guidance here?

@arielvalentin
Copy link
Collaborator

It's mostly a capacity limitation.

I think we really want to support the JRuby test but none of the existing maintainers use it, so trying to maintain the integration test suite is quite difficult.

If you are up to the challenge of enabling JRuby integration tests then I would welcome your contribution! #4

@simi
Copy link
Contributor

simi commented Nov 6, 2023

tests can be started when sqlite3 is removed from gemspec and added to gemfile

gem 'sqlite3', '~> 1.6.4', platform: :ruby
gem 'jdbc-sqlite3', '< 3.42', platform: :jruby

But tests are still failing due to some difference. I'm looking into.

def trace_execute(super_method, sequel_method, sql, options, &block)
response = nil
attributes = {
::OpenTelemetry::SemanticConventions::Trace::DB_NAME => opts[:database],
Copy link
Contributor

Choose a reason for hiding this comment

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

opts[:database] is nil for jdbc connection like jdbc:sqlite::memory:. @jeremyevans is there any better way in here to get database name? I have checked https://sequel.jeremyevans.net/rdoc/classes/Sequel/Database.html and I wasn't able to find out.

Choose a reason for hiding this comment

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

Sequel treats JDBC connection string URIs as opaque, it does not try to parse them. You could try parsing the JDBC URI yourself if you want to find the database name. Note that it isn't unusual to not have a database name even in the non-JDBC case. postgres:///?user=foo will use the default database for user foo on PostgreSQL, but opts[:database] will still be nil in that case.

Copy link
Contributor

@simi simi Nov 6, 2023

Choose a reason for hiding this comment

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

Than it would make sense to use at least DB_CONNECTION_STRING and fill in jdbc connection string.

https://github.com/open-telemetry/opentelemetry-ruby/blob/d365dfeb3982f09cd62a17c6e67eb3792f56e460/semantic_conventions/lib/opentelemetry/semantic_conventions/trace.rb#L36-L37C7

But it will potentially leak credentials. 🤔

Choose a reason for hiding this comment

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

I think the most robust way to handle this is to use Database#database_type to determine the type of database in use, then run database-specific code to get the database name using a query. However, Sequel does not have built-in code to do that, and trying to handle it for all databases that Sequel supports seems challenging.

Considering that approach isn't really feasible, parsing the JDBC URI and returning the path part as the database name is probably the best you can do. At least that gets you behavior similar to other adapters.

Copy link
Contributor

Choose a reason for hiding this comment

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

I did some experiments, but it is not simple to extract the DB name from JDBC URI in unified way and also it is not possible to redact password in JDBC URI. Considering all this together, would it be acceptable to make this one optional @arielvalentin @kaylareopelle and call compact on attributes?

PS: It would be possible to add DB_JDBC_DRIVER_CLASSNAME, I can open additional PRO to enhance.

Copy link
Collaborator

Choose a reason for hiding this comment

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

It's a bit slower than checking if values are nil before adding them to the hash but using compact! is fine by me.

Copy link
Contributor

Choose a reason for hiding this comment

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

@arielvalentin no need to call compact, I mean is it ok to continue without DB_NAME if not easily reachable at this point?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yes that's fine. Instrumentations should do their best to include attributes.

@jrgns
Copy link
Author

jrgns commented Dec 2, 2023

What's the next steps here?

@arielvalentin
Copy link
Collaborator

  1. Please update your branch and address any merge conflicts.
  2. Fix any failing tests/builds
  3. Re-request a review from folks whose comments you've addressed

Copy link
Contributor

github-actions bot commented Jan 2, 2024

👋 This pull request has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the keep label to hold stale off permanently, or do nothing. If you do nothing this pull request will be closed eventually by the stale bot

@github-actions github-actions bot added the stale Marks an issue/PR stale label Jan 2, 2024
@jrgns jrgns requested a review from a team January 5, 2024 05:44
@github-actions github-actions bot removed the stale Marks an issue/PR stale label Jan 6, 2024
Copy link
Contributor

github-actions bot commented Feb 6, 2024

👋 This pull request has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the keep label to hold stale off permanently, or do nothing. If you do nothing this pull request will be closed eventually by the stale bot

@github-actions github-actions bot added the stale Marks an issue/PR stale label Feb 6, 2024
@github-actions github-actions bot closed this Feb 21, 2024
@solutus
Copy link

solutus commented Oct 4, 2024

Hello, is there any plans to maintain Sequel now?

@arielvalentin
Copy link
Collaborator

Hello, is there any plans to maintain Sequel now?

Not at the moment.

We don't have anyone who is willing to be a long term maintainer of the instrumentation.

Is that something you'd be interested in helping with?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed instrumentation stale Marks an issue/PR stale
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants