docs(rivetkit): add actor tracing docs

[eersnington]

this stack is a bit chonky to review so I've scoped down a lot of things.

a rundown of what i'm shipping with this otel stack:

• changes to how ray ID gets passed on within guard service
• traces for actions, http handlers and sqlite operations
• traces for actor-to-actor calls
• linked scheduled actions and queue messages
• actor logs with ray and trace IDs (pino)
• otel sdk warnings and errors through from core to pino
• export to an OTLP backend

not within this stack

• workflows support (will be up next if this looks good cause it's another 800+ loc PR)
• rust sdk support
• websocket traces support (req another migration too to ActionRequest type)
• wasm runtime support
• native effect tracing support

and regarding this pr, i'm hosting the docs here (@NathanFlurry made a lot of changes as per our last call). lmk if you're picky about anything and want more things changed.

https://docs-otel-e2e.eers.dev/actors/docs/general/tracing/

diagrams added

notes for @MasterPtato or anyone puling this to staging.
tracing is feature flagged with the traces endpoint env var. if that's not set, it's disabled.

OTEL_SERVICE_NAME=<val>
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://collector:4318/v1/traces
OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf 
# or grpc

you can technically read the "Quickstart" within the docs and should be able to configure it within the cloud. if anything is unclear in that, lmk, I'll fix things up.

and also this #5729 bumps the internal schema version from 1 to 2 to store ray ID and tracecontext to the schedules and queues table.

[eersnington]

Stack for rivet-dev/actors

• #5734 docs(rivetkit): add actor tracing docs 👈
• #5733 feat(rivetkit): forward otel sdk warnings to the pino logger
• #5732 feat(rivetkit): trace actor to actor calls
• #5730 feat(rivetkit-core): trace queue sends and receives
• #5731 feat(rivetkit-core): trace raw http requests
• #5729 feat(rivetkit-core): trace scheduled invocations
• #5726 feat(rivetkit): send trace context from clients
• #5723 feat(rivetkit): pass trace context to js and logs
• #5727 feat(rivetkit): trace sqlite operations
• #5721 feat(rivetkit): trace actor invocations
• #5728 fix(pegboard-gateway): forward request ray id to actors
• #5724 test(rivetkit): let driver runtimes take extra environment
• #5722 fix(rivetkit): disable services in driver test runtimes
• main

Get stack: forklift get 5734
Push local edits: forklift submit
Merge when ready: forklift merge 5734

_{change mqqwnuwl}

[the-company-company]

🟠 2 medium · 🔵 1 low

_{Reviewed commit 5d35d78.}

[claude]

Code Review

This is a docs-only PR (tracing documentation, sidebar entry, and small CLAUDE.md/testing.md reference bullets). Most of the new content checks out accurately against the actual implementation — span names, span kinds, attribute names, ray-ID validation rules, and NAPI telemetry sink wiring all matched the code in rivetkit-rust/packages/rivetkit-core/src/telemetry/. Two issues found:

1. Sampling env vars are documented but not honored by the native exporter

File: docs/content/docs/general/tracing.mdx (~line 174)

The docs state that OTEL_TRACES_SAMPLER / OTEL_TRACES_SAMPLER_ARG configure sampling for RivetKit's native OTLP exporter. However, rivetkit-rust/packages/rivetkit-core/src/telemetry/export.rs only reads OTEL_EXPORTER_OTLP_TRACES_PROTOCOL/OTEL_EXPORTER_OTLP_PROTOCOL, OTEL_SDK_DISABLED, and OTEL_TRACES_EXPORTER=none — the SdkTracerProvider::builder()...build() call never invokes .with_sampler(...). A user setting these env vars to reduce sampling in production (e.g. traceidratio at 0.1) will silently get 100% sampling of RivetKit's automatic actor/SQLite/queue spans instead, which could cause unexpected trace volume/cost. Worth either wiring up sampler support or correcting the docs to note these vars only apply to a separately configured JS OTel SDK, not RivetKit's built-in exporter.

2. Ray-ID diagram caption text is mispositioned

File: docs/content/docs/general/tracing.mdx (~line 153)

In the inline SVG diagram, the two caption <text> elements ("Same ray ID across this work" / "ray ID: my-rivet-ray-id") live inside <g transform="translate(40 20)"> at local x=20 (absolute x=60), but the dashed "ONE RAY ID" box they annotate is a sibling <g> starting at absolute x=420. Rendered, the captions land ~360px to the left of the box, under the unrelated "Caller" node rather than near the highlighted region — confusing for a reader trying to follow the diagram.

---

Generated by Claude Code review.

[the-company-company]

✅ No issues found

_{Reviewed commit 6c2a881.}

[the-company-company]

🟠 1 medium-severity finding

_{Reviewed commit d18e8f9.}

[the-company-company]

✅ No issues found

_{Reviewed commit 45ae99c.}