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

[rails] Rails action_controller is part of the rack request #112

Merged
merged 10 commits into from
Apr 20, 2017

Conversation

palazzem
Copy link
Contributor

@palazzem palazzem commented Apr 14, 2017

What it does

Major change about how Rails applications are traced. Now the Rack TraceMiddleware is used and so an high overview of the whole request is available. Changes include:

  • the TraceMiddleware is added at initialization time, before the middleware stack is built
  • the rails.request now becomes rails.action_controller and is not the root span anymore
  • because the TraceMiddleware is used, rack.request is the root span for all traces and it includes all http-related tags
  • the rails.request is now part of the rails-controller service (it's user configurable)
  • when we're inside a Rails controller, the process_action.action_controller() changes the rack.request resource so that it has a meaningful name
  • if Rails is not hit, the rack.request keeps the default resource name like GET 200 or GET 404

@palazzem palazzem added integrations Involves tracing integrations do-not-merge/WIP Not ready for merge labels Apr 14, 2017
@palazzem palazzem added this to the 0.7.0 milestone Apr 14, 2017
@palazzem palazzem requested a review from ufoot April 14, 2017 10:11
@palazzem palazzem force-pushed the palazzem/rack-instrumentation branch from b8886da to 86bb860 Compare April 14, 2017 10:13
@palazzem palazzem force-pushed the palazzem/rack-instrumentation branch 2 times, most recently from ea0d4c0 to ba6686b Compare April 19, 2017 12:31
Emanuele Palazzetti and others added 8 commits April 20, 2017 17:18
Even though Integration tests are said to be 25% slower, they run
through Rake's middleware stack, which we might leverage in order to
improve the error capturing capabilities.
ActiveSupport's instrumentation doesn't provide a lot of information
about an error that might have been raised, so introducing a piece of
middleware seems to be the best way of getting full control. Other
similar gems also adopt this approach.
…re_stack and configures the Rack middleware
This reverts commit 751267346472001cc9beb310e4b0b9c3ffa49e8a.
@palazzem palazzem changed the base branch from palazzem/rack-instrumentation to master April 20, 2017 15:19
@@ -58,8 +58,9 @@ of the Datadog tracer, you can override the following defaults:
auto_instrument: false,
auto_instrument_redis: false,
default_service: 'rails-app',
default_database_service: 'postgresql',
default_controller_service: 'rails-controller',
Copy link
Member

Choose a reason for hiding this comment

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

👍

raise e
ensure
# we must close all active spans and set span fields if not already set
request_span.finish()
Copy link
Member

Choose a reason for hiding this comment

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

Don't we have a risk to flush/write this before the tags are set? I mean, today's code path might not make this possible, but generally speaking, I tend to think .finish() should be the last call.

@@ -21,12 +21,9 @@ class TracingControllerTest < ActionController::TestCase
assert_equal(spans.length, 2)

span = spans[1]
assert_equal(span.name, 'rails.request')
assert_equal(span.name, 'rails.action_controller')
assert_equal(span.span_type, 'http')
assert_equal(span.resource, 'TracingController#index')
Copy link
Member

Choose a reason for hiding this comment

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

So, as I understand it, all this http metadata has been bounced to rack, which is actually handling the protocol and should carry the now missing info in its spans, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, all http-related tags are handled in the Rack middleware. I think this is the right approach, especially because a middleware can still change the status_code when the middleware stack is executed "backward" (in the sense of code after the @app.call()).

@@ -84,9 +85,10 @@ Available settings are:
* ``auto_instrument_redis``: if set to ``true`` Redis calls will be traced as such. Calls to Redis cache may be
still instrumented but you will not have the detail of low-level Redis calls.
* ``default_service``: set the service name used when tracing application requests. Defaults to ``rails-app``
* ``default_controller_service``: set the service name used when tracing a Rails action controller. Defaults to ``rails-controller``
Copy link
Member

Choose a reason for hiding this comment

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

I might need to refer to this in the ChangeLog/release note BTW.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, that's part of our "breaking change", that basically doesn't break anything, but changes the previous behavior adding this layer in the middle

@palazzem palazzem removed the do-not-merge/WIP Not ready for merge label Apr 20, 2017
@palazzem palazzem merged commit cf71180 into master Apr 20, 2017
@palazzem palazzem deleted the palazzem/rails-rack branch April 20, 2017 19:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integrations Involves tracing integrations
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants