-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
feat: Add tracing to load
, server actions, and handle
/resolve
#13900
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
base: elliott/init-tracing
Are you sure you want to change the base?
feat: Add tracing to load
, server actions, and handle
/resolve
#13900
Conversation
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
bf91961
to
b504608
Compare
cc0eef5
to
7f08f16
Compare
b504608
to
74ff497
Compare
74ff497
to
be6f6d2
Compare
7f08f16
to
1472161
Compare
be6f6d2
to
3d9b855
Compare
* @param {any} data | ||
* @param {string} [location_description] | ||
*/ | ||
export function validate_load_response(data, location_description) { |
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.
moved to shared to reduce duplication
* - `'server'` - Enable tracing only on the server side | ||
* - `'client'` - Enable tracing only on the client side | ||
* @default false | ||
* @since 2.22.0 |
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.
TODO
4995112
to
7a3909c
Compare
7a3909c
to
3516dd4
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.
This looks really great, thanks for adding the spans. In fact, you're including more information in the attributes than what I currently add in our build-time load
function instrumentation in the Sentry SDK 😅 Really looking forward to removing this in favour of just picking up the new spans!
I Had some suggestions for attribute names and additional spans for sequential handle hooks.
While probably out of scope for this PR: Given the future of load
functions, we should probably think about how we can collect spans for async svelte components and remote functions. Though of course this is something for later. Happy to help out!
* @default undefined | ||
* @since 2.22.0 | ||
*/ | ||
tracing?: 'server'; |
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 like it! Is the idea here that something like 'client'
or 'serverAndClient'
could become additional options when client-side tracing is tackled?
Also, I'm realizing this is far-fetched but do you see a world where we (= tracing SDK like Sentry or OTel) could enable this automatically for users? Just asking because for us, ideally, the fewer files users have to touch when setting up Sentry, the better. Also happy to chat about this as a follow-up item as this is already fine for the beginning.
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.
Yeah, ideally this becomes 'server' | 'client' | 'both'
in the future -- hopefully the OTEL folks can stabilize browser tracing enough that we can do it. (AsyncContext
pls???)
Let me discuss with the team on the enabling-for-users thing. It's possible we could provide an enableOtel
export or something that could be used in instrumentation.ts
to turn it on for users. Will think about it!
}, | ||
fn: async () => { | ||
return await with_event(event, () => | ||
options.hooks.handle({ |
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.
idea: If users use the sequence
helper for their handle
hooks, we could start spans for each handler in the sequence. This is very helpful to group child spans (e.g. db spans) to a specific handler or generally make it more apparent which of their handlers takes up the most time, etc.
Can of course be done in a follow-up :)
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.
Huh, not a bad idea... let me see how weird implementing it would be
name: 'sveltekit.handle', | ||
tracer, | ||
attributes: { | ||
'sveltekit.route.id': event.route.id || 'unknown', |
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.
This applies to all spans where the sveltekit.route.id
attribute is added. There's a standardized semantic attribute called http.route
which should be set to the parameterized route. So I'd recommend switching to this:
'sveltekit.route.id': event.route.id || 'unknown', | |
'http.route': event.route.id || 'unknown', |
(You could also keep of course both attributes but we've seen some user confusion in similar cases with "duplicated" attributes in vercel's ai
package)
btw, thanks a lot for including the route name -- this is super helpful for us!
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.
Ah see, this is why I "hired" you! 😆 I wasn't sure which attributes might have standardized counterparts I could use. Thanks!
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.
Another round:
I think for additional spans, it would be great to also capture spans for +server
routes (i.e. the GET
/POST
etc functions). Technically, the handle spans will already tell us by the route id that a +server route was accessed but I'd see a span for the specfic GET/POST/etc handler as quite valuable, similarly to how OTel express instrumentation would record spans for individual request handlers.
Also left a comment about a node_type attribute.
name: 'sveltekit.load', | ||
tracer, | ||
attributes: { | ||
'sveltekit.load.node_id': node.server_id || 'unknown', |
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 node_id already gives us insights into if this load function was in a +layout, +page (or +error) node but it contains the whole path (which is good for this attribute, don't get me wrong 😆). We could go one step further and also add something like a sveltekit.node_type
attribute.
So basically sveltekit.node_type: '+page' | '+page.server' | '+layout' | ...
No strong opinion though. The main real benefit here would be that you can query, group and aggregate on spans by a specific type easily.
Adds spans to
load
(on the server), server actions, andhandle
/resolve
.We're punting on clientside tracing for now, as we do not feel the o11y community has sufficiently converged on approaches (see https://github.com/open-telemetry/community/blob/main/projects/browser-phase-1.md). When OTEL provides a stable and truly browser-native tracing platform, we'll be all over it.
Want to play around with it?
Clone the repo: https://github.com/elliott-with-the-longest-name-on-github/test-tracing
Set up something like Jaeger (you can copy and run the Docker command at the top of this file to get it up and running with UI and ingestion ports): https://www.jaegertracing.io/docs/2.7/getting-started/
Then build and run your app:
pnpm build && node --import ./instrumentation.server.mjs build/index.js
Visit
localhost:3000/one/two/three/four
, click some buttons to see different scenarios. This will generate traces you can view in Jaeger.TODO:
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm test
and lint the project withpnpm lint
andpnpm check
Changesets
pnpm changeset
and following the prompts. Changesets that add features should beminor
and those that fix bugs should bepatch
. Please prefix changeset messages withfeat:
,fix:
, orchore:
.Edits