Supersedes #13776

What comes built in:

• Context propagation via headers (so if you're calling SvelteKit from a third-party service that is also traced, your spans will connect!)
• Server-side traces for:
  • handle
  • sequence (sequenceed handle functions will show up as children of each other and the root handle hook)
  • load (includes universal loads when they're run on the server)
  • Actions
  • Remote Functions, assuming you've activated their experimental flag
• A new file, instrumentation.server.{js|ts}
  • This file is guaranteed to be run prior to importing your application code*, meaning it's a safe place to set up your instrumentation and exporters
  • *It is guaranteed to run prior to importing your application code in ESM-compatible environments (Node, Vercel (non-edge), Netlify (non-edge), etc -- anything that supports top-level await. It must be supported by your adapter. What this means practically is that, for "partially" supported platforms, your tracing code will still run, but auto-instrumentations may or may not work. All Svelte-owned adapters are launching with at least partial support, but we'd like to receive input from platform experts on whether we can improve this before this feature's experimental flag is removed.

If you want to try it, you need to do two things: Enable SvelteKit traces, and set up an exporter to send those traces somewhere. To enable SvelteKit Traces, add experimental: { tracing: { server: true, serverFile: true } } to your SvelteKit config. To set up an exporter, consult OpenTelemetry documentation for your provider. For example, your src/instrumentation.server.ts file would look like this for Node:

import { NodeSDK } from '@opentelemetry/sdk-node';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-proto';
import { createAddHookMessageChannel } from 'import-in-the-middle';
import { register } from 'module';

const { registerOptions } = createAddHookMessageChannel();
register('import-in-the-middle/hook.mjs', import.meta.url, registerOptions);

const sdk = new NodeSDK({
	serviceName: 'test-sveltekit-tracing',
	traceExporter: new OTLPTraceExporter(),
	instrumentations: [getNodeAutoInstrumentations()]
});

sdk.start();

...and like this for Vercel:

import { registerOTel } from '@vercel/otel';
registerOTel({
	serviceName: 'test-sveltekit-tracing'
});

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. That being said, if you can get a clientside tracing setup working, it will interface with the SvelteKit backend correctly, assuming you send the correct context headers.

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.