Optimizing Trace Retrieval with Client SDK for Nested Spans

Peter K. · 2025-09-24T15:42:55.794Z

Is there a way to get all the spans for a trace using the client sdk? We often have traces where an agent spawns a sub agent which spawns a sub agent etc. Querying it with the client has been something like get all the root spans, find all the root spans under that, and so on. This is pretty inefficient and extremely slow. Seems like this would be doable via sql query on the db but hoping the sdk has a way to do it natively

Optimizing Trace Retrieval with Client SDK for Nested Spans | Arize AI Community

5 comments

· Sorted by Oldest

RunLLM
APP
·
·
Yes, you can efficiently retrieve all spans for a given trace using the Phoenix client SDK by filtering spans with the same trace_id. The recommended approach is to use the query DSL or the get_spans_dataframe method with a filter condition on trace_id, which returns all spans (including nested ones) for that trace in a single call—no need for recursive queries. This is much more efficient than iteratively fetching root and child spans. Example: ```import phoenix as px client = px.Client()
spans_df = client.get_spans_dataframe(f"trace_id == '{your_trace_id}'")```This will return a DataFrame of all spans belonging to the specified trace, including all nested sub-agents and their spans, in one operation. For more, see Phoenix: Export Data & Query Spans and GitHub: filter spans by trace_id.Would you like more detail or examples on how to use the query DSL for more advanced filtering?Sources: - GitHub: filter spans by trace_id
💡 Hint: Mention RunLLM in the thread for followups.
Peter K.
·
·
I dont think this is true
Mikyo
·
·
Hey Peter K. sorry for the delay here. Busy morning. Agree we can probably do better in terms of exposing "traces" as an entity to query in our system. A bit curious about your use-case and what your needs are for querying traces that are correlated to sub-agent execution. Would this be sorta related to grouping traces via sessions or metadata?
Peter K.
·
·
Yea pretty much for grouping. The way we run some of our evals is we load all the llm inputs/outputs and tool inputs/outputs and concat them into 1 large string for evaluation. So typically we'll find the trace and grab all the spans under that which naturally ends up grouping them. For now, I did just update our stuff to add a metadata field I can grab all the spans with and then group them by the session id. This seems to work but would be awesome to just do it off the root trace id.
Mikyo
·
·
Gotcha, I anticipate us having first-class trace / session level apis that make this easier to pull and evaluate. Don't have a magic bullet on this given it can be a lot of data and the query patterns may vary depending on your agent topology. Definitely drop a github issue or comment as I'd love to keep you informed as we tackle some of this stuff. Appreciate the feedback. Feel free to ping this channel. We're thinking about this problem heavily as we think about trace / session level evals.
🙌1

RunLLM
APP
·
·
Yes, you can efficiently retrieve all spans for a given trace using the Phoenix client SDK by filtering spans with the same trace_id. The recommended approach is to use the query DSL or the get_spans_dataframe method with a filter condition on trace_id, which returns all spans (including nested ones) for that trace in a single call—no need for recursive queries. This is much more efficient than iteratively fetching root and child spans. Example: ```import phoenix as px client = px.Client()
spans_df = client.get_spans_dataframe(f"trace_id == '{your_trace_id}'")```This will return a DataFrame of all spans belonging to the specified trace, including all nested sub-agents and their spans, in one operation. For more, see Phoenix: Export Data & Query Spans and GitHub: filter spans by trace_id.Would you like more detail or examples on how to use the query DSL for more advanced filtering?Sources: - GitHub: filter spans by trace_id
💡 Hint: Mention RunLLM in the thread for followups.
Peter K.
·
·
I dont think this is true
Mikyo
·
·
Hey Peter K. sorry for the delay here. Busy morning. Agree we can probably do better in terms of exposing "traces" as an entity to query in our system. A bit curious about your use-case and what your needs are for querying traces that are correlated to sub-agent execution. Would this be sorta related to grouping traces via sessions or metadata?
Peter K.
·
·
Yea pretty much for grouping. The way we run some of our evals is we load all the llm inputs/outputs and tool inputs/outputs and concat them into 1 large string for evaluation. So typically we'll find the trace and grab all the spans under that which naturally ends up grouping them. For now, I did just update our stuff to add a metadata field I can grab all the spans with and then group them by the session id. This seems to work but would be awesome to just do it off the root trace id.
Mikyo
·
·
Gotcha, I anticipate us having first-class trace / session level apis that make this easier to pull and evaluate. Don't have a magic bullet on this given it can be a lot of data and the query patterns may vary depending on your agent topology. Definitely drop a github issue or comment as I'd love to keep you informed as we tackle some of this stuff. Appreciate the feedback. Feel free to ping this channel. We're thinking about this problem heavily as we think about trace / session level evals.
🙌1