-
Notifications
You must be signed in to change notification settings - Fork 373
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
Migrate rails
configuration to new API
#224
Conversation
8da0e36
to
35b13b2
Compare
082dd2d
to
ba7a27a
Compare
a97420c
to
b4a67e4
Compare
ba7a27a
to
6e629a6
Compare
b4a67e4
to
66bb372
Compare
6e629a6
to
9454601
Compare
66bb372
to
19c2020
Compare
9454601
to
7182451
Compare
3485012
to
bf5a998
Compare
3783f45
to
996453e
Compare
rails
configuration to new API
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.
minor nitpicks and questions otherwise it's good in the overall. The only stopper here is that I remember we decided to switch from c.use
to c.instrument
. I'm fine with both, though I prefer a c.instrument :rails
.
If you agree, we can just work on top of c.use
, and then write a last PR that updates this everywhere (just to avoid writing a PR and rebasing all of them on top of the new one).
lib/ddtrace.rb
Outdated
@@ -46,41 +46,3 @@ def configure | |||
end | |||
|
|||
require 'ddtrace/monkey' | |||
|
|||
# Datadog auto instrumentation for frameworks |
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!
|
||
option :tracer, default: Datadog.tracer | ||
option :default_service, default: 'rack' | ||
option :distributed_tracing_enabled, default: false | ||
|
||
def initialize(app, options = {}) | ||
# update options with our configuration, unless it's already available | ||
[:tracer, :default_service, :distributed_tracing_enabled].each do |k| |
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 we remove this? I think we can simply merge
them no?
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 agree, but I wonder if we shouldn't do these improvements on another PR. My idea was to migrate everything to the new API and then do a thorough cleanup in the configuration code. Let me know if you prefer to do this in this PR.
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.
👍
option :trace_agent_port, default: Datadog::Writer::PORT | ||
option :env, default: nil | ||
option :tags, default: {} | ||
option :sidekiq_service, default: 'sidekiq' |
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.
shouldn't be in the sidekiq patcher?
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.
absolutely. this is only here for now to maintain backward compatibility!
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.
👍
include Base | ||
register_as :rails, auto_patch: true | ||
|
||
option :enabled, default: true |
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've a different logic here: https://github.com/DataDog/dd-trace-rb/pull/226/files#diff-acecea54cdb8458166cefacb04d7a9baR26
Should we do the same? Because in Rails we're disabling / enabling the tracer when the Railtie is executed, but not when the initializer is called.
It means that you set the Tracer.enabled <- False
but the tracer can still send traces until Rails isn't fully initialized. Am I missing something?
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.
For the future, it would be great accessing directly to the tracer so that tracer specific configurations aren't part of integrations. That way as we've discussed before, you configure the Tracer AND Rails.
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 agree with everything you pointed out, but I'd keep things as they're now to avoid changing too many things at once. Right now we're maintaining exactly the same behavior as before. The next step would be getting rid of the Framework.configure
method entirely, by using the pattern you described (using the custom setters provided in the new API)
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.
👍
@palazzem about the Datadog.configure do |c|
c.use :tracer, logger: Logger.new(STDOUT)
c.instrument :rails
end What do you think? Actually it could be anything else. I just think that one name work well for the integrations AND the tracer. Let me know if you have any thoughts on that. |
40529c5
to
b64075e
Compare
|
||
option :tracer, default: Datadog.tracer | ||
option :default_service, default: 'rack' | ||
option :distributed_tracing_enabled, default: false | ||
|
||
def initialize(app, options = {}) | ||
# update options with our configuration, unless it's already available | ||
[:tracer, :default_service, :distributed_tracing_enabled].each do |k| |
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.
👍
option :trace_agent_port, default: Datadog::Writer::PORT | ||
option :env, default: nil | ||
option :tags, default: {} | ||
option :sidekiq_service, default: 'sidekiq' |
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.
👍
b64075e
to
bd457a9
Compare
include Base | ||
register_as :rails, auto_patch: true | ||
|
||
option :enabled, default: true |
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.
👍
bd457a9
to
65693b8
Compare
65693b8
to
cac9773
Compare
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.
All good to me after the rebase!
This PR migrates the
rails
integration to the new configuration API, so we don't rely on theRails.configuration
object anymore.The motivation for this is to provide a common, standardized way of configuring all integrations.
Currently
rails
integration is configured through:From now on the configuration should be done through:
Notice that we're currently supporting both configuration modes for now (this change is backwards-compatible) but support for for the
Rails.configuration
object should be dropped soon.