Skip to content

(discussion) How to best handle instrumenting for resources and prompts #766

Description

@CakeCrusher

(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!

Activity

  1. added
    documentationImprovements or additions to documentation
    ready for workEnough information for someone to start working on
    P2Moderate issues affecting some users, edge cases, potentially valuable feature
    on Oct 7, 2025
  2. Kludex commented on Dec 4, 2025

    @Kludex
    Member

    Related to #421.

  3. jordansilly77-stack commented on Jun 20, 2026

    @jordansilly77-stack

    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.

  4. maxisbey commented on Jul 24, 2026

    @maxisbey
    Contributor

    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.

    AI Disclaimer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Moderate issues affecting some users, edge cases, potentially valuable featuredocumentationImprovements or additions to documentationready for workEnough information for someone to start working on

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions