Pre-filing checklist
Component(s)
Rust OTAP dataflow (rust/otap-dataflow/)
Is your feature request related to a problem?
Currently, metric-level configuration is applied via policies at the node level. We have no way to select individual metric sets (or individua instruments) and raise or lower their level.
Proposed Solution
We require a way to raise the level of metric sets, which equates to a metric_set-scoped metric-level setting, to override the default policy in effect at a node.
Alternatives Considered
Metric sets are the unit of instrumentation, they are indivisible from the caller's perspective. If we want to raise or lower the level of single instruments within a metric_set, more work is required but still within reason.
Additional Context
See open-telemetry/opentelemetry-collector#15121 for a similar request.
See #2623 which proposes a way to configure metric schema at the instrumentation level; it would configure schema at the metric_set level to support migration, and I would expect the same configuration semantics with metric-level configuration.
Pre-filing checklist
Component(s)
Rust OTAP dataflow (rust/otap-dataflow/)
Is your feature request related to a problem?
Currently, metric-level configuration is applied via policies at the node level. We have no way to select individual metric sets (or individua instruments) and raise or lower their level.
Proposed Solution
We require a way to raise the level of metric sets, which equates to a metric_set-scoped metric-level setting, to override the default policy in effect at a node.
Alternatives Considered
Metric sets are the unit of instrumentation, they are indivisible from the caller's perspective. If we want to raise or lower the level of single instruments within a metric_set, more work is required but still within reason.
Additional Context
See open-telemetry/opentelemetry-collector#15121 for a similar request.
See #2623 which proposes a way to configure metric schema at the instrumentation level; it would configure schema at the metric_set level to support migration, and I would expect the same configuration semantics with metric-level configuration.