-
Notifications
You must be signed in to change notification settings - Fork 179
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
feat (sequel): Initial Sequel instrumentation #672
Conversation
72c7f14
to
88afa84
Compare
@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... |
Hey @arielvalentin No, I'm not part of the OTel Github Org Yes. I'm willing to commit to maintenance etc. |
88afa84
to
7eecb44
Compare
@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. |
702ca41
to
3f9feb2
Compare
@arielvalentin check it now? |
@jrgns I will take a look tomorrow during US business hours |
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 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!
instrumentation/sequel/lib/opentelemetry/instrumentation/sequel/instrumentation.rb
Show resolved
Hide resolved
cf5cee9
to
9c2fda4
Compare
@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?
This should allow your |
exporter.reset | ||
end | ||
|
||
describe 'tracing' do |
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 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..
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've made some changes, but will expand it even further.
d2fa547
to
476a85c
Compare
@kaylareopelle I've added the gem to the CI files. |
@arielvalentin anything else you need on this? |
instrumentation/sequel/test/opentelemetry/instrumentation/sequel_test.rb
Outdated
Show resolved
Hide resolved
instrumentation/sequel/test/opentelemetry/instrumentation/sequel_test.rb
Outdated
Show resolved
Hide resolved
instrumentation/sequel/test/opentelemetry/instrumentation/sequel_test.rb
Outdated
Show resolved
Hide resolved
476a85c
to
88b72f3
Compare
@kaylareopelle @arielvalentin changes made. |
88b72f3
to
f24d7f2
Compare
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? |
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 |
tests can be started when sqlite3 is removed from gemspec and added to gemfile
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], |
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.
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.
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.
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.
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.
Than it would make sense to use at least DB_CONNECTION_STRING
and fill in jdbc connection string.
But it will potentially leak credentials. 🤔
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 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.
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 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.
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.
It's a bit slower than checking if values are nil before adding them to the hash but using compact!
is fine by me.
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.
@arielvalentin no need to call compact, I mean is it ok to continue without DB_NAME
if not easily reachable at this point?
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.
Yes that's fine. Instrumentations should do their best to include attributes.
What's the next steps here? |
|
👋 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 |
👋 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 |
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? |
OpenTelemetry Instrumentation for the Sequel Database Toolkit.
This can be used instead of DB specific instrumentations.