You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
(discussion) How to best handle instrumenting for resources and prompts #766
(Unfortunately there is no discussion page in this repo so im posting this here)
I am looking to add instrumentation to this package in https://github.com/Arize-ai/openinference to handle resources and prompts in a way so that OpenTelemetry spans are created correctly. The purpose is to enable tracing the resources resources and prompts produced by the server.
(I have already explored the package and have added context (state of the OpenTelemtry span) propagation for the client and server with the server receiving the context at the _handle_request.)
The question is where should the spans be created for the resources and prompt?
PS: Not 100% sure if _handle_request is the best function to handle the propagation too so advice on that would be great too!
I'd like to take a small docs-only pass on this. Scope would be to explain where to instrument prompts/resources/tools today, how this relates to request-level tracing, and avoid adding any SDK hooks or OpenTelemetry dependency. I'll keep it narrow and link the PR here.
Tracing is built into the SDK on the v2 line now, so an instrumentor no longer has to choose a hook point: every server ships an OpenTelemetry middleware that opens a SERVER span for each inbound message — resources/read and prompts/get included (the latter also carries gen_ai.prompt.name) — and it stays a no-op until you install an exporter (OpenTelemetry docs). Context propagation is native too: the client injects the W3C traceparent into the request's _meta and the server extracts it, so the server span nests under the client's — that's the Traces that cross the wire section, and it's the layer your _handle_request propagation was reaching for. If you want to add your own spans or attributes on top, the extension point is the same one the built-in tracing uses: the low-level Server.middleware list, which wraps every method (middleware docs, currently marked provisional).
Closing this as part of a wider backlog cleanup around the v2 release. Feel free to reopen if this is still relevant.
Activity
Kludex commentedon Dec 4, 2025
Related to #421.
jordansilly77-stack commentedon Jun 20, 2026
I'd like to take a small docs-only pass on this. Scope would be to explain where to instrument prompts/resources/tools today, how this relates to request-level tracing, and avoid adding any SDK hooks or OpenTelemetry dependency. I'll keep it narrow and link the PR here.
maxisbey commentedon Jul 24, 2026
Tracing is built into the SDK on the v2 line now, so an instrumentor no longer has to choose a hook point: every server ships an OpenTelemetry middleware that opens a
SERVERspan for each inbound message —resources/readandprompts/getincluded (the latter also carriesgen_ai.prompt.name) — and it stays a no-op until you install an exporter (OpenTelemetry docs). Context propagation is native too: the client injects the W3Ctraceparentinto the request's_metaand the server extracts it, so the server span nests under the client's — that's the Traces that cross the wire section, and it's the layer your_handle_requestpropagation was reaching for. If you want to add your own spans or attributes on top, the extension point is the same one the built-in tracing uses: the low-levelServer.middlewarelist, which wraps every method (middleware docs, currently marked provisional).Closing this as part of a wider backlog cleanup around the v2 release. Feel free to reopen if this is still relevant.
AI Disclaimer