open-telemetry
Exposing public APIs to for implementing new MeasurementConsumer classes
Is your feature request related to a problem?
We need to re-configure opentelemetry processors at run-time to control where telemetry signals are exported to, but the SDK does not allow resetting of MeterProvider, TracerProvider or LoggerProvider. We have worked around this limitation by using SynchronousMulti<Span/LogRecord>Processors and adding / removing other processors to them (removing processors is not supported in the current SDK but is easy to implement by following existing conventions and extending public APIs), however there doesn't seem to be any equivalent for metrics, so we have no way of re-configuring which metric readers are used during run-time.
Describe the solution you'd like
The main thing preventing us from implementing a SynchronousMultiMeasurementConsumer is that there is only one MeasurementConsumer (SynchronousMeasurementConsumer) which is defined in _internal packages with no public API available. MeterProvider also takes no arguments about which MeasurementConsumer it should use and assumes there is only ever one implementation so it creates an instance of SynchronousMeasurementConsumer in a private property (self._measurement_consumer). Would it be possible to expose these options externally? We have proof of concept code which works by using these private APIs but we thought it'd be best if contribute this back to the project because it helps make the SDK more extensible.
Describe alternatives you've considered
No response
Additional Context
No response
Would you like to implement a fix?
Yes
Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.
@JP-MY Would it be acceptable to have a single MetricReader that has multiple dynamic exporters, or do you truly want to add/remove MetricReaders potentially with their own temporality, default aggregation, views, etc.?
Hi, sorry I forgot to update the issue, but after discussing this on the SIG call last week, it was decided to add 2 functions to the meter provider API to add and remove metric readers. Unfortunately your suggestion of using the same reader with multiple exporters is not feasible as the readers have many aspects (retry on failure, periodic vs in memory (on demand pull), etc. which can't be shared. I'll update the original request to reflect this shortly and will be a raising a PR for the same in the next few days.