fermyon
Provide a request ID as a header when the http trigger is triggered
For logging and debugging purposes it's nice to be able to pre-fix logs with a request Id. Instead of having every component implement generating a request id, it would be nice if Spin could provide one as a header in the http request send to the component.
I don't know if other trigger types could make use of the same information, or if it already exists in the runtime!?!
I don't think it currently exists. If we did this then yes, it would be good to make it available on all triggers, but only HTTP has the header concept: for other triggers, it would involve a change to the event payload, which is a WIT change.
A possible alternative way to do this would be to provide a new event_id host API, which any guest could call regardless of trigger type. This would be additive so no change to existing signatures. But if it were HTTP only then the header would work fine.
I like the event_id idea. If the HTTP-trigger (or any trigger) could then implement it as part of a header or payload, would be up to the trigger.
One thing to consider: we should probably provide a logging interface that it's not up to each component to log things in a uniform way. This would allow the Spin runtime and thus the end user to have more control over how logs are displayed.
@calebschoepp is there any overlap with this request and current/forecasted telemetry work?
My initial impression is that there isn't a ton of overlap here with WASI Observe. In the short to medium term WASI Observe is much more focused on tracing and metrics. I'm sure long-term WASI Observe will support the OTEL logging signal but it doesn't seem like a priority right now. @endocrimes please chime in if your perception is different.
As for overlap on the Spin specific observability work I've been doing: I also think there isn't really much overlap there.
As for participating in the discussion +1 to what Ryan said for making it not the responsibility of a component to log properly. I wonder if WASI Logging has anything that could help here.
@mikkelhegn do you still feel like you have a need for this now that we have tracing?