-
Notifications
You must be signed in to change notification settings - Fork 651
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve usability of Metrics SDK #750
Comments
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 |
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? |
Also another consideration, should |
…n-telemetry#750) * chore: rename provider in examples and getting started * chore: update examples, bench, and getting started for api * chore: update examples for latest changes * chore: lint examples
The steps to setup and initialize the components needed even BEFORE recording metrics seems to be quite a lot.
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.
The text was updated successfully, but these errors were encountered: