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

Support for Sinatra modular apps #1015

Merged
merged 3 commits into from
Apr 24, 2020
Merged

Support for Sinatra modular apps #1015

merged 3 commits into from
Apr 24, 2020

Conversation

marcotc
Copy link
Member

@marcotc marcotc commented Apr 23, 2020

Fixes #486 and #913
Closes #491 (thank you @jpaulgs!)

This PR adds improved support for Sinatra modular applications.

We already had support for classic applications, but it did not translate correctly to modular apps.

We now support nested modular Sinatra apps, and added a new span measuring the specific application route that was matched for a request (sinatra.route).

To help support modular apps, a new tag (sinatra.app.name) was added to the existing sinatra.request span, to identify which modular app handled to the request.

Action shots

The existing sinatra.request span, which measures the total Sinatra middleware time. Now including the application name:
Screen Shot 2020-04-23 at 4 00 14 PM

The new sinatra.route span, which measures only the user application time of a matched route:
Screen Shot 2020-04-23 at 4 00 00 PM

@marcotc marcotc added bug Involves a bug integrations Involves tracing integrations feature Involves a product feature labels Apr 23, 2020
@marcotc marcotc requested a review from a team April 23, 2020 22:23
@marcotc marcotc self-assigned this Apr 23, 2020
@delner delner added this to In review in Active work Apr 24, 2020
Copy link
Contributor

@delner delner left a comment

Choose a reason for hiding this comment

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

Overall looks pretty good; just some questions around the implementation of fetch for the middleware span. Once I have a better understanding of that, I think I should have no problem signing off on this.

@@ -1511,7 +1513,40 @@ get '/' do
end
```

Where `options` is an optional `Hash` that accepts the following parameters:
#### Modular application
Copy link
Contributor

Choose a reason for hiding this comment

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

Improved documentation is nice!

@@ -32,53 +36,115 @@ def route(verb, action, *)
end

def self.registered(app)
::Sinatra::Base.module_eval do
Copy link
Contributor

Choose a reason for hiding this comment

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

👍 to getting rid of monkey patches.

lib/ddtrace/contrib/sinatra/tracer.rb Outdated Show resolved Hide resolved
lib/ddtrace/contrib/sinatra/tracer_middleware.rb Outdated Show resolved Hide resolved
lib/ddtrace/contrib/sinatra/tracer.rb Outdated Show resolved Hide resolved
return span if span

tracer = configuration[:tracer]
span = tracer.trace(
Copy link
Contributor

Choose a reason for hiding this comment

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

Out of curiosity, why auto-create the span on fetch?

Is this somehow related to if the stack short-circuits before reaching route_eval?

Copy link
Member Author

@marcotc marcotc Apr 24, 2020

Choose a reason for hiding this comment

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

Yes, this is the part that create the span when we are sure this is the correct middleware layer to instrument.
It can only happen in two cases:

  • When a route matches: we create it right before we instrument the route itself. This happens right before route_eval.
  • When not route matches: we create it on the app.after callback, before we return from the current middleware.

@marcotc marcotc requested a review from delner April 24, 2020 18:21
Copy link
Contributor

@delner delner left a comment

Choose a reason for hiding this comment

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

Okay, seems good. Thanks @marcotc !

@marcotc marcotc added this to the 0.35.0 milestone Apr 24, 2020
@marcotc marcotc merged commit 0ac468c into master Apr 24, 2020
Active work automation moved this from In review to Merged & awaiting release Apr 24, 2020
@marcotc marcotc deleted the fix/sinatra-subapp branch April 24, 2020 21:07
@marcotc marcotc linked an issue Apr 24, 2020 that may be closed by this pull request
@marcotc marcotc moved this from Merged & awaiting release to Released in Active work May 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Involves a bug feature Involves a product feature integrations Involves tracing integrations
Projects
Active work
  
Released
Development

Successfully merging this pull request may close these issues.

Modular Sinatra not handling resource names correctly Sinatra integration not setting rack.request
2 participants