Skip to content
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

Stabilize the Monitoring class #14

Open
daniil-berg opened this issue Sep 13, 2024 · 0 comments
Open

Stabilize the Monitoring class #14

daniil-berg opened this issue Sep 13, 2024 · 0 comments
Assignees
Labels
breaking change Changes to public functions that are not backwards compatible consistency An inconsistency that should be (re-)aligned documentation Improvements or additions to documentation refactoring Non-breaking changes that improve maintainability or readability

Comments

@daniil-berg
Copy link
Contributor

The Monitoring class is currently poorly documented, not particularly clear, nor type safe, and needlessly exposes some of its internal attributes.

It also currently stores simple "attribute-metrics" (that map to status attributes) and as well as "calculated metrics" (that require a function call in each update cycle) in the same metrics dictionary.

It would also benefit from the new Singleton metaclass to get rid of the get_instance class method.

Instead of referring to the global settings object throughout the class, it would make more sense to have the Prometheus text file path as a constructor argument that defaults to the corresponding setting. Referring to the storage base URL is probably fine as is.

@daniil-berg daniil-berg self-assigned this Sep 13, 2024
@daniil-berg daniil-berg added documentation Improvements or additions to documentation breaking change Changes to public functions that are not backwards compatible consistency An inconsistency that should be (re-)aligned refactoring Non-breaking changes that improve maintainability or readability labels Sep 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change Changes to public functions that are not backwards compatible consistency An inconsistency that should be (re-)aligned documentation Improvements or additions to documentation refactoring Non-breaking changes that improve maintainability or readability
Projects
None yet
Development

No branches or pull requests

1 participant