feat: Add tracing to load, server actions, and handle/resolve

[elliott-with-the-longest-name-on-github]

Adds spans to load (on the server), server actions, and handle/resolve. It also adds a tracing object with rootSpan and currentSpan to the RequestEvent, ServerLoadEvent, and LoadEvent types. This means you can get access to a span to annotate it pretty much anywhere -- including using getRequestEvent (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:

• Configuration to enable globally enabling or disabling telemetry
• Tests
• Ask for comments from community -- esp. around what data we're capturing in our attributes and how it's structured, whether we need any additional API surface for annotating spans
• Test on serverless platforms

---

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

• Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 904a4cc

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[elliott-with-the-longest-name-on-github]

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.
Learn more

• feat: Add tracing to load, server actions, and handle/resolve #13900 👈 (View in Graphite)
• feat: Initial tracing setup (peer deps + utils) #13899
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[elliott-with-the-longest-name-on-github]

moved to shared to reduce duplication

[elliott-with-the-longest-name-on-github]

TODO

[Lms24]

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!

[Lms24]

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 :)

[elliott-with-the-longest-name-on-github]

Huh, not a bad idea... let me see how weird implementing it would be

[elliott-with-the-longest-name-on-github]

Going to punt on this as a followup -- it's pretty annoying to get ahold of the tracing configuration in sequence to know whether we can get an active tracer

[Lms24]

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.

[benmccann]

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