Arize AI Community Icon

Home
Events

Arize AX Releases
Arize AX Support
Arize News
Arize Observe
Discussions
Introductions
Phoenix Support

Powered by Tightknit

Filtering Traces by Custom Attributes in Phoenix UI | Arize AI Community

Phoenix Support

Phoenix Support

Filtering Traces by Custom Attributes in Phoenix UI

·Feb 14, 2025 08:37 PM

hey folks, I'm trying to filter traces based on custom attributes in the phoenix UI. Can you please help? We're sending a custom attribute called org_id and was hoping something like this would work: metadata['org_id'] != 618 Feel free to point me to the docs, but didn't see anything at first glance. Thanks!

44 comments

· Sorted by Oldest

RunLLM
APP
·
Filtering traces by custom attributes like org_id directly in the Phoenix UI is not currently supported for nested JSON attributes. The UI filtering capabilities are limited to top-level attributes, and using expressions like metadata['org_id'] != '618' won't work as expected in the UI. For more information, you can refer to the Phoenix GitHub issue discussing similar limitations. Would you like more detail on possible workarounds or further assistance?Sources: - Phoenix GitHub issue
💡 Hint: Mention RunLLM in the thread for followups.
Nick C.
·
Hmm, this doesn't sound promising: https://github.com/Arize-ai/phoenix/issues/2266#issuecomment-1940339463
Nick C.
·
I'm stuck on even the most basic filters like this one:
Nick C.
·
OK, I found the hidden columns and it does appear that metadata ≠ attributes
Nick C.
·
ahh, CHAIN has to be all caps despite showing as lowercase in the UI 😭
Anthony P.
·
Ah really sorry about that, I agree that is pretty confusing
Anthony P.
·
do you find the + button with examples helpful?
Nick C.
·
I tried the examples, but struck out
Nick C.
·
span_kind == 'LLM' returns no results
Anthony P.
·
Does it work if you switch to the Span view instead of Traces view
Nick C.
·
Ah, it does! But why?
Anthony P.
·
That could use some UX improvement as well I think. In your above screenshot you can see some of the llm spans are nested within a "chain" trace
Anthony P.
·
the trace just happens to be the highest ancestor span in that unit of work
Anthony P.
·
and our filter bar is looking specifically for traces
Anthony P.
·
but that is somewhat confusing