-
-
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
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
74ff497
to
be6f6d2
Compare
7f08f16
to
1472161
Compare
be6f6d2
to
3d9b855
Compare
packages/kit/types/index.d.ts
Outdated
* - `'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
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!
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.
3516dd4
to
68af856
Compare
1472161
to
5abdec8
Compare
68af856
to
2991158
Compare
5abdec8
to
c8c11f9
Compare
3f295a0
to
311906d
Compare
c8c11f9
to
eca0d11
Compare
311906d
to
4ce4ff1
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.
Could we put this behind an experimental flag like we've been doing with the other larger features recently? It seems like it'd be a nice way to gather feedback about the spans that we're providing
It'd also probably be helpful to add a docs page for this
12e313d
to
124687d
Compare
9ecd13d
to
17898be
Compare
17898be
to
4af22aa
Compare
eca0d11
to
0c3aad6
Compare
14b4034
to
ae224e2
Compare
ae224e2
to
904a4cc
Compare
packages/kit/src/exports/public.d.ts
Outdated
/** | ||
* Whether to enable serverside OpenTelemetry tracing for SvelteKit operations including handle hooks, load functions, and form actions. | ||
* @default undefined | ||
* @since 2.22.0 // TODO: update this before publishing |
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, need to update this directly prior to merging
@@ -49,6 +50,13 @@ export const handleError = ({ event, error: e, status, message }) => { | |||
}; | |||
|
|||
export const handle = sequence( | |||
({ event, resolve }) => { |
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.
Some things we want to test, like navigation, actually involve two requests, so the traces will have two separate trace IDs. This allows us to set a stable ID across all of the traces for a given test so that we can pull them out of the file we write to the disk. We put them on the root span (rather than the span associated with this specific handle function) so that we can easily find the root span, then rebuild the span tree from there.
import fs from 'node:fs'; | ||
|
||
/** @implements {SpanExporter} */ | ||
class FilesystemSpanExporter { |
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 am reasonably sure this can replace our error serialization stuff, because the OTEL integration captures error spans. Will do it in a followup PR sometime in the future, or never, depending on how motivated I am and how much more-important work there is to do 😆
return JSON.stringify(span_data); | ||
}); | ||
|
||
fs.appendFileSync(this.#path, serialized_spans.join('\n') + '\n'); |
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.
using jsonl
conventions so that we can just spam the lines into the file without having to parse/reserialize it all the time
read_traces: async ({}, use) => { | ||
/** @param {string} test_id */ | ||
function read_traces(test_id) { | ||
const raw = fs.readFileSync('test/spans.jsonl', 'utf8').split('\n').filter(Boolean); |
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 could see this becoming inefficient / slowing down tests if we start using it more widely -- it may need optimization in the future
if (root_traces.length === 0) { | ||
return []; | ||
} | ||
return root_traces.map((root_trace) => { |
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 should significantly increase the efficiency of building the tree as the number of spans associated with a given trace is quite small compared to the total number of spans
Adds spans to
load
(on the server), server actions, andhandle
/resolve
. It also adds atracing
object withrootSpan
andcurrentSpan
to theRequestEvent
,ServerLoadEvent
, andLoadEvent
types. This means you can get access to a span to annotate it pretty much anywhere -- including usinggetRequestEvent
(this could be quite nice for library integrations!).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 page 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 ./instrument.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