Add span for filter

[gyliu513]

Sub task for #1483

[chinmaychahar]

Hello, are these sub-issues open for contribution?

[sudoalok]

/assign

[gyliu513]

@sudoalok in case you have some question for this issue, here are some info for you as #1694

For span name, use a short snake_case verb name for the span, not the dotted llm_d.epp.filter style.

#1565 standardized our tracing: span names became short snake_case verb phrases (pick_pd_profile, score_prefix_cache, prepare_disaggregation), and the dotted llm_d.epp.* prefix was removed from span names — the namespacing moved into the OTel instrumentation scope instead. So name the span after the operation, e.g. filter_endpoints (or per-filter like filter_session_affinity if you want one span per filter implementation), and start it with tracing.Tracer(schedplugins.TracerScope) and trace.WithSpanKind(trace.SpanKindInternal), matching the scorer span.

The scope constant lives in pkg/epp/framework/plugins/scheduling/constants.go (schedplugins.TracerScope). The filters are subpackages under that tree (filter/prefixcacheaffinity, filter/sessionaffinity, filter/bylabel, filter/sloheadroomtier), so import the parent package and reference schedplugins.TracerScope — exactly like score_prefix_cache does in scorer/preciseprefixcache/precise_prefix_cache.go.

For attributes, the dotted namespace stays on the keys. For a filter the natural ones are the input and output endpoint counts:

• llm_d.epp.filter.candidate_endpoints (Int) and llm_d.epp.filter.filtered_endpoints (Int)
• reuse the shared gen_ai.request.model and gen_ai.request.id keys, the same way the scorer span does

You don't need separate type/name attributes — the scorer reference span doesn't set them and the span name already identifies the operation. If you do want them, the values are available via p.TypedName().Type / .Name. Use score_prefix_cache as the closest reference to copy.

[sudoalok]

@gyliu513 Quick check before I open the PR, following the #1565 convention you outlined: single step span filter_endpoints over the whole chain (attrs llm_d.epp.filter.candidate_endpoints in / filtered_endpoints out), or one span per filter named filter_ inside each subpackage like score_prefix_cache? The per-filter shape fits "the name identifies the operation," but it's the same code across prefixcacheaffinity/sessionaffinity/bylabel/sloheadroomtier — so a shared TracedFilter decorator (à la #1531's TracedScorer) may be the cleaner way to get per-filter spans. Which do you prefer?

(@chethanuk already has a TracedFilter/TracedPicker decorator in their fork covering #1693/#1694 — happy to coordinate so we're not duplicating.)

[gyliu513]

@sudoalok

• span name is single step span
• span attribute llm_d.epp.xx.xx
• span scope is whole package