Improve usability of Metrics SDK

[lzchen]

The steps to setup and initialize the components needed even BEFORE recording metrics seems to be quite a lot.

metrics.set_meter_provider(MeterProvider(batcher_mode == "stateful"))
meter = metrics.get_meter(__name__)
exporter = ConsoleMetricsExporter()
controller = PushController(meter=meter, exporter=exporter, interval=5)

The division of responsibilities is also not clear. Why does the user need to define the PushController? There is not a clearly defined way of configuring (what exporter I want to use, what controller I want to use, whether it is stateful, the export interval, etc) metrics collection and export properties.

Despite there not being a well-defined metrics SDK spec, I'm creating this issue here to track discussion for the Python implementation specifically (as well as any insight received from the metrics SIG when SDK discussion resumes). As well, small PRs and adjustments to the SDK that are language specific that we feel will lead to a good implementation can be tracked here. Any suggestions are welcome.

[aabmass]

Going through the "Getting Started" doc a few days ago, I was definitely confused by the PushController.

In #751 you mentioned putting all the configuration including the collection interval into MeterProvider. I think that would prevent the user from having metrics with different collection intervals. Is there a potential use case where a user might want metrics on different collection intervals?

[lzchen]

Yes there are definitely uses cases where the user wants different collection intervals. For example, on Azure side, we have the regular custom metrics you can record and export, and we have live metrics, which export system related metrics automatically very frequently. Users would probably not want to export regular metrics with such high frequency.

With that being said, you are correct about the limitations of configuration in this way. It's quite a difficult problem, where as on one hand we want to have a "global" MeterProvider, but on the other hand be able to create instances of "something" that will allow us to configure things like export interval and stateful per pipeline. Perhaps we can have MeterProvider have a "createPipeline" which takes in configuration elements, and a meter?

[lzchen]

Also another consideration, should exporter be on the MeterProvider or Meter level? That is, would it be likely for a user to need to export to different backends depending on Meter?