-
-
Notifications
You must be signed in to change notification settings - Fork 48
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
Metrics & Plugin Interface #4
Comments
See #3 |
Although I understand the ultimate goal of building a generic plugin system on Bloom to integrate different features easily, I wonder if we might be prematurely optimizing. Given the current requirements and the Bloom architecture, it would be reasonable to implement the metrics system directly without a generic plugin interface. However, if we eventually have many lateral features that make it difficult to reason about the Bloom core or hurt its performance, we could refactor them into a plugin system. Before adding any new features, spending some time maintaining the codebase is essential. My concerns are updating outdated dependencies, upgrading the Rust version, and migrating to async/await. We can ease new development by keeping Bloom up-to-date and dealing with this technical debt. What do you think about this approach? I'm open to feedback and would love to collaborate with the refactoring and adding this new feature. |
As an Operator of several Plattforms I just have my 2ct to add to the metrics idea. My general thought would be if possible to add an simple openMetrics endpoint for that. So in the end people are not bound to one way of getting those metrics :) |
Goal: build a generic plugin system on Bloom to be able to extract data and inject live configuration changes (an I/O interface).
On which, we may integrate a wide range of stuff without needing to touch the Bloom core. For instance, a metrics system (which is relevant for the Bloom use case).
Early requirements
Metrics
The text was updated successfully, but these errors were encountered: