feat(rivetkit): actor tracing, invocation metrics, and log correlation with otel

[eersnington]

People of Rivet, this change adds built-in support for OpenTelemetry to Rivetkit for making it easy for users to observe every actor action, scheduled actor action, actor to actor calls, and SQLite operations with relevant trace context and ray identifier.

More in depth:

• Added enriched trace context like rayId, trace_id, and span_id to c.log
• Added opentelemetry, opentelemetry_sdk, opentelemetry-otlp, tracing-opentelemetry to rivetkit-napi
• Added support for OTEL_* environment configurations (separate from RIVET_OTEL_* engine configs) to control trace endpoints, Batch Span Processor (its queue size, export batch size, and delay between exports), and sampling methods
• Added native export to support OTLP over http/protobuf, http/json, and grpc
• Added telemetry metrics such as Invocation counts and durations. They follow standard Prometheus format (https://prometheus.io/docs/instrumenting/exposition_formats/)
• Rivetkit Otel SDK warnings passes down into pino logs for cases like when the BSP overflows and drops spans.

(To maintain the sanctity of this codebase's contribution guidelines)

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

• Passes 345 rivetkit-core tests
• Added e2e NAPI integration tests for action spans and scheduled trace origins
• Added an e2e test for concurrent actions on the same actor to ensure each keeps its own trace context and not see each other's context.
• Added e2e test for failure paths like OTel collector being unreachable, or accepts requests but never responds. In both cases, action still succeeds as normal.
• Overhead measured with tracing off and on, with Rust and JS profiles too (shared in Discord).
• These changes have been tested on a self hosted GKE cluster with an OTLP collector and Jaeger configured.
• Changes have been independently reviewed by me, and with the help of Fable 5.1

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[eersnington]

at the behest of the living tribunal of code reviews, a codiff walkthrough has been bestowed upon you

https://codiff.eers.dev/w/JRyyW8zaCbTaFzZuW2l2lHu_

edit: outdated

[eersnington]

A few things now with 4f5b976

Caller action
└── CLIENT span (ms)— NEW: measures the entire call
    └── SERVER span (ms) — (receiving action)

• Added spans to show how long an outgoing call takes (actor calling another actor's action)
• ^ This now appears within the application spans if one is active, or else under the calling action's span
• The receiving actor's action span now is shown in this new call span
• Client retries, including retryOnLifecycleBoundary() are now shown in the same call span and not as a separate retry
• Rivet error code now shows up in error.type attribute for when actor-to-actor calls fail
• Records unfinished tracking as actor.operation_abandoned within the error.type attribute

[eersnington]

Changes with 7e876b7

• Previously, sqlite spans would be parented under the invocation. Now it accurately nests under the application span.
• Rust clients now send trace context and rays
• External TS clients now carry the ray in OTel baggage header as per W3C Baggage specification
• One shared helper now sends JS trace context into core operations
• Traces, status, and invocation metrics for raw HTTP onRequest()
• waitUntil() now keeps the invocation span open until the work is complete within the invocation trace
• Queue traces now link the action that consumed the message, to the work that sent it

[the-company-company]

🟠 1 medium-severity finding

_{Reviewed commit ca15083.}

[eersnington]

Changes with ca15083

• .fetch() method on an actor handle now automatically carry the caller’s tracecontext and ray.
• Receiving queue message now creates a span linked to its sender, including queues in run handlers.
• Consistent usage of x-rivet-ray-idwithin headers and W3C Baggage key.

[the-company-company]

✅ No issues found

_{Reviewed commit 1035242.}

[eersnington]

added this to mark spans where an sqlite query or actor call started, but no result was recorded. this will now stand out in user's traces too.

it doesn’t mean the operation failed. this error is used only in tracing and isn’t returned to callers

[eersnington]

upcoming, public docs

[eersnington]

• The server-side actor client adds spans around actor-to-actor action calls
• TypeScript and Rust clients propagate ray and W3C trace context
• NAPI carries active JavaScript span context into Core SQLite operations
• Scheduled actions and queue receives start linked traces from stored origins
• Unknown action and queue labels gets set to _OTHER