Upper Bound Problem of _metrics_to_export

[CunjunWang]

Is your feature request related to a problem?
Yes. Currently the Python Prometheus Exporter implementation uses a double ended queue called _metrics_to_export to work as an intermediate storage. export() function in the PrometheusMetricsExporter class add metrics data entry to the queue, and collect() function pulls data from the queue. What if the controller keeps adding metric data to the queue but no one is pulling from it? It seems that there is not a mechanism to handle this case. Do we need an upper bound on the number of metrics data in the queue?

Describe the solution you'd like
Use a memory upper bound, the collection’s size is limited. When the collection is full, discard the new incoming data or replace the data at the front.

Describe alternatives you've considered
Use a time-based upper bound. Every metric data entry carries a timestamp when they are added into the collection, and set a timeout. If the entry is not pulled by the user within the timeout, it expires and it is discarded.

Additional context
Python Prometheus Exporter implementation

[Mykolaichenko]

Same question, +1

[github-actions]

This issue was marked stale due to lack of activity. It will be closed in 30 days.

[codeboten]

This seems like a good feature to have and should be part of the specification to ensure all implementations follow the same pattern.

[srikanthccv]

@CunjunWang prom exporter has been re-worked over the last couple of weeks. The current implementation collects metrics only when the scrape target is invoked. Which then are encoded and exported. This is no longer an issue with exporter but the problem of sdk on how to deal with long uncollected measurements. Closing this. Feel free to re-open if you think otherwise.