Description
Phoenix currently filters out A2A and FastAPI spans, showing only OpenInference-compatible traces. This hides valuable instrumentation that's already being captured, making it harder to debug agent execution flow and infrastructure issues.
Why this matters
A2A and FastAPI instrumentation shows:
- A2A spans: Message handling, context propagation, task lifecycle, agent execution flow
- FastAPI spans: HTTP request/response details, routing, middleware execution, authentication
Without these spans, developers debugging issues like "why didn't my agent receive the message?" or "why did authentication fail?" have no visibility into the infrastructure layer - they only see framework operations in isolation. And it could be that they are not using a framework at all (custom code) and did not instrument their code.
Current state
The OTLP collector filters spans before sending to Phoenix:
- Only OpenInference spans (matching
openinference.instrumentation.* pattern) pass through
- A2A spans (message handling, context propagation) are filtered out
- FastAPI spans (HTTP requests, routing) are filtered out
- Filter configured in
helm/templates/collector/config.yaml under processors.filter/phoenix
Changes needed
- Relax filter in OTLP collector config to allow A2A spans through
- Relax filter to allow FastAPI spans through
- Test that spans display properly in Phoenix UI alongside OpenInference traces
- Update documentation on what instrumentation is visible
Acceptance criteria
- A2A spans visible in Phoenix traces
- FastAPI spans visible in Phoenix traces
- Spans properly nest with framework-specific instrumentation when present
- Phoenix UI remains usable with mixed span types
- Documentation updated showing what's automatically instrumented
Description
Phoenix currently filters out A2A and FastAPI spans, showing only OpenInference-compatible traces. This hides valuable instrumentation that's already being captured, making it harder to debug agent execution flow and infrastructure issues.
Why this matters
A2A and FastAPI instrumentation shows:
Without these spans, developers debugging issues like "why didn't my agent receive the message?" or "why did authentication fail?" have no visibility into the infrastructure layer - they only see framework operations in isolation. And it could be that they are not using a framework at all (custom code) and did not instrument their code.
Current state
The OTLP collector filters spans before sending to Phoenix:
openinference.instrumentation.*pattern) pass throughhelm/templates/collector/config.yamlunderprocessors.filter/phoenixChanges needed
Acceptance criteria