Adding context parameter to span functions

[chrisdickinson]

The Dylibso Observe-SDK implementation relies on the host and guest sharing the same thread & thus, having access to the same thread locals. This allows the host to maintain implicit span state information about the guest.

However, the wasi-threads proposal is progressing and runtimes are beginning to add support. This means guests will need to explicitly communicate a context with which to associate span function invocations.

Opening an issue to discuss:

1. How do we want to represent a context in WIT?
2. Whose responsibility is it to create a context, and how does the guest obtain access to one in order to provide it in span-{enter,exit,tags} calls?
3. What implications are there for auto-instrumentation of components?

[chrisdickinson]

I started to write out a question in the bytecodealliance zulip and felt like I was answering my own questions. Scratch this with a nickel, please:

• Assumption: o11y vendors may have their own o11y WIT interfaces over time, offering wasi-observe adapter modules.
  • Given this, I began to fret that a string context parameter would involve too many copies when transitioning between components. However, it's being sent alongside multiple other strings, so it's not really that much more overhead.
• Assumption: a component starts a context -- e.g., a hypothetical node.js server creates a context to service a request. This might be nested under its own continuation ID that the o11y vendor auto-instrumentation is required to maintain. It may also spawn sub-contexts (imagine that the request context causes a redis pool to allocate another connection) that outlive the parent continuation.
  • Given that child resources cannot outlive parent resources, I think this rules out using a WIT resource to represent the context?

It strikes me that a free-form string works just fine as a "continuation" or "thread" id for a consuming component. Does anyone have any strong feelings pro- or contra- this?

[jcchavezs]

My 2p here:

Back in the days I was maintaining a PHP tracing library (zipkin-php) and it is single thread in a way but when reactPHP came in, we needed to keep state of the span and not use global states. A context parameters makes lot of sense. Only keeping the IDs in the context is a good idea.

How do we want to represent a context in WIT?

I think the healthiest thing is to use the two ids, probably conflated in a string to represent traceID and spanID.

Whose responsibility is it to create a context, and how does the guest obtain access to one in order to provide it in span-{enter,exit,tags} calls?

Host process can create a span (e.g. go middleware) and when we enter into the guest, the span functions should allow users to mutate the spans and or create new spans. The host created spans will hold a context that we can use to create child spans. If no context is provided we can create a new one in the guest and report it to the host.

What implications are there for auto-instrumentation of components?

I think it is very related on how auto-instrumentation gives you access to the context e.g. in Go, some autoinstrumentation work even if you don't propagate the context so if you create a context in wasm and pull the right function to do manual instrumentation in host it should work e.g. https://skywalking.apache.org/docs/skywalking-go/latest/en/advanced-features/manual-apis/toolkit-trace/