ExportingMetricsReader for explicit metrics reading/exporting

[howardyoo]

Is your feature request related to a problem?

Yes. The problem that I wish to address is to have Metric Reader that does not rely on intervals like PeriodicExportingMetricReader, but the reader that can export the collected metric controlled by triggering it explicitly, via outside timer or scheduler. Another problem with the PeriodicExportingMetricReader is that we cannot start or stop its execution once the thread starts, and therefore one must either shut the current one down and re-start it.

Describe the solution you'd like

I would like to introduce a new MetricReader called ExportingMetricReader. Basically, it will have all the identical functionality as the PeriodicExportingMetricReader, except for the intervals that will periodically export the metric data automatically. Instead, it will have a method called 'export' which when invoked, will trigger the same behavior that the periodic exporter do: collect and export the metric. It is expected that this export function will be invoked by an external entity.

Describe alternatives you've considered

I have considered using the PeriodicExportingMetricReader with the time interval of a very large period (e.g. 100 years), and call force_flush() to collect and export at will. This method may work with existing PeriodicExportingMetricReader. However, it will have an unnecessary thread waiting inside it, and calling force_flush() does feel like a hack.

Additional context

The existing PeriodicExportingMetricReader can inherit this class and add additional logic to trigger the collection and export in tervals.

[aabmass]

I have considered using the PeriodicExportingMetricReader with the time interval of a very large period (e.g. 100 years), and call force_flush() to collect and export at will. This method may work with existing PeriodicExportingMetricReader. However, it will have an unnecessary thread waiting inside it, and calling force_flush() does feel like a hack.

Quick note, the intention of the metrics specification is that MetricReader.collect() can be called on demand to trigger "normal" collection, while force flush is more urgent and can have a performance hit e.g. flushing buffers. another possible implementation is to update PeriodicExportingMetricReader so that

• if math.isinf(export_interval_millis) does not create any background thread
• call PeriodicExportingMetricReader.collect() on demand

I think your solution is cleaner, we just need to be careful when expanding the public API. It could also be accomplished in "user space" instead of adding it the actual OTel SDK. If there's enough demand for this, I think we should add it.

Thoughts @lzchen ?

[howardyoo]

Hi @aabmass , thanks for the note.
Just a question here. When one calls MetricReader.collect(), does it collect metrics, as well as emit (export) them, or simply just collect() and not export?

[rodrigodiez]

Just a question here. When one calls MetricReader.collect(), does it collect metrics, as well as emit (export) them, or simply just collect() and not export?

As far as I can understand reading the code, PeriodicMetricsReader will do both. It will collect the metrics and call export on every registered exporter.

I am personally struggling with this at the moment. I am working on instrumenting a performance-sensitive codebase for which I need metric collection to happen on demand (we need every single produced measurement for later analysis), but exporting these measurements at different time, either on demand or periodically at greater intervals. I need to avoid blocking the main thread while exporting.

[howardyoo]

I see.. I too would like to see some changes in the way we could collect and export metrics. The SDK should definitely support exposing collect, and export separately, so that users can invoke them as needed, without being triggered by the PeriodicMetricReader! (and why do we have ONLY one viable reader?)

[aabmass]

The spec basically says that collect() triggers a collection and not much else.. I had previous discussion in open-telemetry/opentelemetry-specification#2140 about this because I agree it's confusing but collect() isn't intended to return metrics to the caller. The goal of the spec was to support both push and pull based exporters through this single MetricReader interface.

Just a question here. When one calls MetricReader.collect(), does it collect metrics, as well as emit (export) them, or simply just collect() and not export?

As far as I can understand reading the code, PeriodicMetricsReader will do both. It will collect the metrics and call export on every registered exporter.

It's up to the individual implementation of MetricReader. The base MetricReader class doesn't know anything about MetricExporter at all. E.g. pull exporters like Prometheus just implement metric reader directly and don't use the MetricExporter interface.

The SDK should definitely support exposing collect, and export separately, so that users can invoke them as needed, without being triggered by the PeriodicMetricReader! (and why do we have ONLY one viable reader?)

If it wasn't clear from the API docs, you can implement custom MetricReaders. I think what you brought up is a good use case for including in the core SDK but @rodrigodiez's example is a little more complicated. Like in general, would ExportingMetricReader run in the calling thread or a background thread and return a future?

[lzchen]

@aabmass

Thoughts on this?

[srikanthccv]

This is done