Invoke agent server span#3473
Conversation
Add support for OpenAI Responses API operation type in the gen_ai.operation.name attribute.
…t enum - Rename gen_ai.api.type to openai.api.type (OpenAI-specific attribute) - Remove 'version' from brief description - Change from free-form string to strict enum (chat_completions, responses) - Remove stale 'responses' operation value from gen_ai.operation.name docs - Update OpenAI registry docs with new attribute
1f6695c to
0d83b95
Compare
…nd inherited opt_in attrs
| This span is the server counterpart of the [invoke agent client span](/docs/gen-ai/gen-ai-agent-spans.md#invoke-agent-client-span). | ||
| It's reported by the GenAI agent server when it receives and processes | ||
| an agent invocation request from a client. | ||
| extends: attributes.gen_ai.inference.client |
There was a problem hiding this comment.
we may want to extract a common attribute group for client/server
at the same time, I'm a bit unsure if the existing invoke_agent client span is correct in extending the inference client attributes, and so unsure if we should create .inference.common or .invoke_agent.common
cc @lmolkova
There was a problem hiding this comment.
unsure if the existing invoke_agent client span is correct in extending the inference client attributes
yep, it's not right and we should fix it - #2632
we may want to extract a common attribute group for client/server
👍
There was a problem hiding this comment.
Splitting invoke_agent from inference in: #3514
I'll follow-up after this PR to split out "common" invoke_agent for client/server.
There was a problem hiding this comment.
I think we can make progress here right now - we should not extend client invoke_agent here anyway
There was a problem hiding this comment.
I think @lmolkova's suggesting to go ahead and extend attributes.gen_ai.common.client here. That way you don't need to inherit the few inferences attributes we are removing from invoke_agent in #3514, and then we can follow-up later (after both PRs land) with adding attributes.gen_ai.invoke_agent.common, at which point it should be a pure yaml refactoring (and shouldn't affect any markdown files).
| - ref: client.address | ||
| requirement_level: | ||
| recommended: If applicable | ||
| - ref: client.port | ||
| requirement_level: | ||
| recommended: When `client.address` is set. |
There was a problem hiding this comment.
it this actually helpful on GenAI spans? If users want HTTP/transport details, they should enable corresponding spans. I can see it could become useful, but do we need it right now?
There was a problem hiding this comment.
perhaps opt-in, in case HTTP is not instrumented.
it's important for security, but it still privacy concern
There was a problem hiding this comment.
Make client.address and client.port as opt-in
|
|
||
| **Span kind** MUST be `SERVER`. | ||
|
|
||
| This span is the server counterpart of the [invoke agent client span](/docs/gen-ai/gen-ai-agent-spans.md#invoke-agent-client-span). |
There was a problem hiding this comment.
what does this mean? does it explain anything to server instrumentation authors or consumers of telemetry?
There was a problem hiding this comment.
Thanks have update the description and updated it to It represents processing of agent invocation requested by a client.
| It's reported by the GenAI agent server when it receives and processes | ||
| an agent invocation request from a client. |
There was a problem hiding this comment.
maybe
| It's reported by the GenAI agent server when it receives and processes | |
| an agent invocation request from a client. | |
| It represents processing of agent invocation requested by a client. |
?
I think 'receives' is covered by protocol spans and depends on how the request is received. This one represents something that happens after receive - processing
| This span is the server counterpart of the [invoke agent client span](/docs/gen-ai/gen-ai-agent-spans.md#invoke-agent-client-span). | ||
| It's reported by the GenAI agent server when it receives and processes | ||
| an agent invocation request from a client. | ||
| extends: attributes.gen_ai.inference.client |
There was a problem hiding this comment.
I think we can make progress here right now - we should not extend client invoke_agent here anyway
Replace 'server counterpart' reference with a concise description of what the span represents, consistent with how other server spans (MCP, HTTP, RPC) describe themselves in the codebase.
Per review feedback, the server span should not inherit inference-specific attributes. Extend attributes.gen_ai.common.client instead.
Add all attributes from the invoke_agent client span (per PR open-telemetry#3514) to the server span, including token usage with aggregation notes, inference request parameters, conversation id, content attributes, and tool definitions.
|
This PR has been labeled as stale due to lack of activity. It will be automatically closed if there is no further activity over the next 7 days. |
|
Hello @singankit! With the merging of Move GenAI semantic conventions to its own dedicated repository, the Our ask is that you move this PR to the new repo here: https://github.com/open-telemetry/semantic-conventions-genai The contribution guide for the new repo can be found here: https://github.com/open-telemetry/semantic-conventions-genai/blob/main/CONTRIBUTING.md. A major difference is making sure there's a representative scenario and reference outlined in:
You may also find that you need to additional updates to you proposal as the new repo use the V2 Schema. If you would like to discuss or have questions you can reply here, post in slack here, or add an agenda item for the Gen AI SIG. Thank you so much! |
Fixes #3334
Changes
Add
invoke agentspan for server as counterpart to existing client invoke agent span. This helps capture server perspective of agent invocation.Important
Pull requests acceptance are subject to the triage process as described in Issue and PR Triage Management.
PRs that do not follow the guidance above, may be automatically rejected and closed.
Merge requirement checklist
[chore]