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
Improve tracing #580
Improve tracing #580
Conversation
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 main reason for this change is to properly support the use case where the Laravel SDK is head of trace, setting the baggage
in the meta tag. Having the transaction name figured out before the view is rendered is something we have to do.
Setting unified transaction names based on the route version sounds like a good idea.
Worth checking what happens in getsentry/sentry-python#1661 (comment). This will go out as a new major version anyway, but maybe we get some insights onto how many dashboards could be affected.
As mentioned in #562, I would wait for changes to how we instrument HEAD/OPTIONS
requests for now.
A way to enable instrumentation on 404s sounds good to me.
# Conflicts: # CHANGELOG.md # README.md # src/Sentry/Laravel/Tracing/EventHandler.php # src/Sentry/Laravel/Tracing/Middleware.php # test/Sentry/IntegrationTest.php
* Remove extracting route name or controller for transaction names * CS * Add changelog entry
We used to set the transaction name as late as possible to make sure the routing information is available to us. However this doesn't work well with generating the new
baggage
so we now do it as early as Laravel allows us instead.Few things I like to improve here still:
RouteMatched
event for setting the transaction nameHEAD
requestsDiscussion points:
some.route
) and controller class (SomeController@someAction
) as options for transaction names and only keep the "route" version of the URL (some/{route}
)?HEAD
request and hard-404 tracing?