Expand MetricSelector to support scope_attribute view selectors

[drewrelmas]

Pre-filing checklist

• I searched existing issues and didn't find a duplicate

Component(s)

Rust OTAP dataflow (rust/otap-dataflow/)

Is your feature request related to a problem?

Follow-up to #2500

The OpenTelemetry Rust SDK exposes 7 selector dimensions on &Instrument for view matching:

Dimension	SDK accessor	Supported in otel-arrow
Instrument name	instrument.name()	Yes
Scope name	instrument.scope().name()	Yes
Instrument kind	instrument.kind()	No
Instrument unit	instrument.unit()	No
Scope version	instrument.scope().version()	No
Scope schema URL	instrument.scope().schema_url()	No
Scope attributes	instrument.scope().attributes()	No

Our MetricSelector struct currently only supports instrument_name and scope_name. This limits the expressiveness of declarative view configuration.

otel-arrow/rust/otap-dataflow/crates/config/src/pipeline/telemetry/metrics/views.rs

Lines 19 to 27 in 446e251

	/// OpenTelemetry Metric Selector configuration.
	#[derive(Debug, Clone, Serialize, Deserialize, JsonSchema, PartialEq)]
	pub struct MetricSelector {
	/// The name of the instrument to match.
	pub instrument_name: Option<String>,
	/// The instrumentation scope (meter) name to match.
	/// When set, the view only applies to instruments created under this scope.
	pub scope_name: Option<String>,
	}

Similarly, MetricStream only supports name and description, while the SDK's Stream::builder() also supports unit, aggregation, allowed_attribute_keys, and cardinality_limit.

Use Case

• scope_attributes: Filter by deployment environment or other scope-level metadata, e.g., only apply a view to instruments from scopes tagged with env=production.

Immediate work (high priority)

Add scope_attributes to MetricSelector:

pub struct MetricSelector {
    pub instrument_name: Option<String>,
    pub scope_name: Option<String>,
    pub scope_attributes: Option<HashMap<String, String>>,  // new
}

And add corresponding filter clauses in DeclarativeView::to_view_funtion() in views_provider.rs.

Example YAML config:

views:
  - selector:
      scope_name: "my.library"
      scope_attributes:
        env: "production"
    stream:
      description: "Production histograms"

Low priority work

Warning

The support for OpenTelemetry Rust SDK views is not planned long-term in otap-dataflow, see #2623, which proposes eventually replacing views with equivalent ability in the internal telemetry system. Therefore, it is not super critical to implement the lower priority pieces of the issue unless there is an immediate use case.

Stream (lower priority, follow-up)

Expand MetricStream to support unit, aggregation, allowed_attribute_keys, and cardinality_limit.

Other Selectors (lower priority, follow-up)

instrument_unit, scope_version, and scope_schema_url could be added later if use cases arise. These are rarely needed in practice.

instrument_kind was originally considered a high priority item / easy win, but feedback from @cijothomas on this issue raised a good point that we may not want to support it, at least for now.

Alternatives Considered

N/A

Additional Context

• Reference to opentelemetry-rust instrument.rs

[cijothomas]

instrument_kind: Apply a view to all histograms (e.g., set custom bucket boundaries) without listing every instrument by name.

While it sound useful, it often causes more trouble than gains, as views has additive behavior - so if a view matches all Histograms to set custom buckets, and another view matches a histogram to set diff name - they don't get merged - instead we produce duplicate histogram streams, one with custom buckets and another with custom name.

Not a problem caused by us but just sharing it here, and I propose to not support "Kind" selection for now. The rest looks good!

[drewrelmas]

Thanks for the insight! It makes sense to be cautious about Kind based on your explanation. I will revise the issue to put kind in the low priority section.

For immediate future, simply adding scope_attributes satisfies the use case I have.

[pritishnahar95]

I would like to take up this issue once triaged. @drewrelmas can you please assign this to me?

[drewrelmas]

I've marked it as accepted and assigned it to you. I feel this is a very non-controversial thing and doesn't need to wait until next SIG meeting.