Questions About Langflow Trace Types and Latency Metrics in Arize

Nauel I. · 2026-03-27T05:41:50.067Z

Hi everyone, hope you’re all doing well 👋 I have a question about Langflow’s execution behavior and how it generates traces in Arize. From what I’ve observed, every time a flow runs, it produces two traces: • An AgentExecutor trace (OpenAI agent in my case) • A UUID trace (Langflow component trace) At first this seemed fine, but when I started looking at latency metrics (p50 & p99), I noticed that the AgentExecutor trace is also included in the calculations. My expectation was to track only the UUID traces, since they better represent the latency of each request to the Langflow service. A couple of questions: • Is it expected that AgentExecutor and UUID traces are mixed in latency calculations? • How can I track latency using only UUID traces? Thanks in advance — really appreciate any clarification!

5 comments

· Sorted by Oldest

RunLLM
APP
·
·
Yes, it is expected that both AgentExecutor and UUID traces are included in Phoenix’s latency metrics by default, since Phoenix aggregates all traces ingested for a project unless you apply a filter. This can lead to mixed latency statistics if both trace types are present in your data. According to <https://arize.com/docs/phoenix/integrations/platforms/langflow/langflow-tracing|Phoenix documentation>, the AgentExecutor trace comes from Phoenix’s LangChain instrumentation, while the UUID trace is native to Langflow. To track latency using only UUID traces, you should apply a filter in the Phoenix UI or API that selects only the UUID traces (e.g., by trace name, span kind, or a unique attribute present in UUID traces). This will ensure that latency metrics (p50, p99, etc.) are calculated only for the traces that represent Langflow service requests, excluding AgentExecutor traces from the aggregation. Filtering by trace type or attribute is the recommended approach for targeted metrics in Phoenix (<https://arize.com/docs/phoenix/tracing/concepts-tracing/faqs-tracing|source>). Would you like more detail on how to set up such a filter in the Phoenix UI or via API? Sources: - <https://arize.com/docs/phoenix/integrations/platforms/langflow/langflow-tracing|LangFlow Tracing - Phoenix> - <https://arize.com/docs/phoenix/tracing/concepts-tracing/faqs-tracing|https://arize.com/docs/phoenix/tracing/concepts-tracing/faqs-tracing>
💡 Hint: Mention RunLLM in the thread for followups.
Nauel I.
·
·
RunLLM does applying a filter affect latency metrics at the project level? I tried using span_kind == "CHAIN", but it doesn’t seem to change the metrics at all. Is this expected behavior, or am I missing something?
RunLLM
APP
·
·
Yes, this is expected behavior: applying a filter in the Phoenix UI currently does not affect the project-level latency metrics (such as p50/p99) shown in the header; these metrics are calculated over all traces in the project, regardless of filters. Filters only affect the data shown in tables and charts, not the summary metrics at the top (<https://github.com/Arize-ai/phoenix/issues/5973|source>, <https://github.com/Arize-ai/phoenix/issues/9008|source>, <https://arize-ai.slack.com/archives/C04R3GXC8HK/p1745696860.492159|source>). If you need latency metrics for a filtered subset, you must export the filtered data and compute the metrics externally, or use the GraphQL API, which may reflect filters more accurately than the UI header. Would you like more detail or a code example for exporting and calculating filtered latency? Sources: - <https://github.com/Arize-ai/phoenix/issues/5973|https://github.com/Arize-ai/phoenix/issues/5973> - <https://github.com/Arize-ai/phoenix/issues/9008|https://github.com/Arize-ai/phoenix/issues/9008> - <https://arize-ai.slack.com/archives/C04R3GXC8HK/p1745696860.492159|https://arize-ai.slack.com/archives/C04R3GXC8HK/p1745696860.492159>
💡 Hint: Mention RunLLM in the thread for followups.
Nauel I.
·
·
RunLLM Is there an explanation for why AgentExecutor traces are included in the project metrics? From what I can see, their inclusion can be misleading. Could you provide some intuition behind this behavior?
RunLLM
APP
·
·
AgentExecutor traces are included in project metrics because Phoenix aggregates all ingested traces for a project by default, regardless of their origin or type. This design ensures that every trace—whether from LangChain’s AgentExecutor or Langflow’s native UUID trace—contributes to overall project statistics, providing a comprehensive view of all activity unless specifically filtered (<https://arize.com/docs/phoenix/integrations/platforms/langflow/langflow-tracing|source>, <https://arize.com/docs/phoenix/tracing/concepts-tracing#traces|source>). However, this can be misleading if different trace types represent different logical units or latencies, as their metrics may not be directly comparable. The rationale is to maximize observability and flexibility, but it requires users to apply filters or post-process data to focus on the most relevant trace types for their use case. There is ongoing discussion in the community about making project metrics filter-aware to address this confusion (<https://github.com/Arize-ai/phoenix/issues/5973|source>). Would you like more detail on best practices for handling mixed trace types in Phoenix? Sources: - <https://arize.com/docs/phoenix/integrations/platforms/langflow/langflow-tracing|LangFlow Tracing - Phoenix> - <https://arize.com/docs/phoenix/tracing/concepts-tracing#traces|https://arize.com/docs/phoenix/tracing/concepts-tracing#traces> - <https://github.com/Arize-ai/phoenix/issues/5973|https://github.com/Arize-ai/phoenix/issues/5973>
💡 Hint: Mention RunLLM in the thread for followups.

Questions About Langflow Trace Types and Latency Metrics in Arize | Arize AI Community

RunLLM
APP
·
·
Yes, it is expected that both AgentExecutor and UUID traces are included in Phoenix’s latency metrics by default, since Phoenix aggregates all traces ingested for a project unless you apply a filter. This can lead to mixed latency statistics if both trace types are present in your data. According to <https://arize.com/docs/phoenix/integrations/platforms/langflow/langflow-tracing|Phoenix documentation>, the AgentExecutor trace comes from Phoenix’s LangChain instrumentation, while the UUID trace is native to Langflow. To track latency using only UUID traces, you should apply a filter in the Phoenix UI or API that selects only the UUID traces (e.g., by trace name, span kind, or a unique attribute present in UUID traces). This will ensure that latency metrics (p50, p99, etc.) are calculated only for the traces that represent Langflow service requests, excluding AgentExecutor traces from the aggregation. Filtering by trace type or attribute is the recommended approach for targeted metrics in Phoenix (<https://arize.com/docs/phoenix/tracing/concepts-tracing/faqs-tracing|source>). Would you like more detail on how to set up such a filter in the Phoenix UI or via API? Sources: - <https://arize.com/docs/phoenix/integrations/platforms/langflow/langflow-tracing|LangFlow Tracing - Phoenix> - <https://arize.com/docs/phoenix/tracing/concepts-tracing/faqs-tracing|https://arize.com/docs/phoenix/tracing/concepts-tracing/faqs-tracing>
💡 Hint: Mention RunLLM in the thread for followups.
Nauel I.
·
·
RunLLM does applying a filter affect latency metrics at the project level? I tried using span_kind == "CHAIN", but it doesn’t seem to change the metrics at all. Is this expected behavior, or am I missing something?
RunLLM
APP
·
·
Yes, this is expected behavior: applying a filter in the Phoenix UI currently does not affect the project-level latency metrics (such as p50/p99) shown in the header; these metrics are calculated over all traces in the project, regardless of filters. Filters only affect the data shown in tables and charts, not the summary metrics at the top (<https://github.com/Arize-ai/phoenix/issues/5973|source>, <https://github.com/Arize-ai/phoenix/issues/9008|source>, <https://arize-ai.slack.com/archives/C04R3GXC8HK/p1745696860.492159|source>). If you need latency metrics for a filtered subset, you must export the filtered data and compute the metrics externally, or use the GraphQL API, which may reflect filters more accurately than the UI header. Would you like more detail or a code example for exporting and calculating filtered latency? Sources: - <https://github.com/Arize-ai/phoenix/issues/5973|https://github.com/Arize-ai/phoenix/issues/5973> - <https://github.com/Arize-ai/phoenix/issues/9008|https://github.com/Arize-ai/phoenix/issues/9008> - <https://arize-ai.slack.com/archives/C04R3GXC8HK/p1745696860.492159|https://arize-ai.slack.com/archives/C04R3GXC8HK/p1745696860.492159>
💡 Hint: Mention RunLLM in the thread for followups.
Nauel I.
·
·
RunLLM Is there an explanation for why AgentExecutor traces are included in the project metrics? From what I can see, their inclusion can be misleading. Could you provide some intuition behind this behavior?
RunLLM
APP
·
·
AgentExecutor traces are included in project metrics because Phoenix aggregates all ingested traces for a project by default, regardless of their origin or type. This design ensures that every trace—whether from LangChain’s AgentExecutor or Langflow’s native UUID trace—contributes to overall project statistics, providing a comprehensive view of all activity unless specifically filtered (<https://arize.com/docs/phoenix/integrations/platforms/langflow/langflow-tracing|source>, <https://arize.com/docs/phoenix/tracing/concepts-tracing#traces|source>). However, this can be misleading if different trace types represent different logical units or latencies, as their metrics may not be directly comparable. The rationale is to maximize observability and flexibility, but it requires users to apply filters or post-process data to focus on the most relevant trace types for their use case. There is ongoing discussion in the community about making project metrics filter-aware to address this confusion (<https://github.com/Arize-ai/phoenix/issues/5973|source>). Would you like more detail on best practices for handling mixed trace types in Phoenix? Sources: - <https://arize.com/docs/phoenix/integrations/platforms/langflow/langflow-tracing|LangFlow Tracing - Phoenix> - <https://arize.com/docs/phoenix/tracing/concepts-tracing#traces|https://arize.com/docs/phoenix/tracing/concepts-tracing#traces> - <https://github.com/Arize-ai/phoenix/issues/5973|https://github.com/Arize-ai/phoenix/issues/5973>
💡 Hint: Mention RunLLM in the thread for followups.