bloom
bloom copied to clipboard
valeriansaliou
Metrics & Plugin Interface
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
- Instance RPS (total, per request type)
- Success/error ratio
- Request/response latency per Bloom-Status (MISS, HIT, DIRECT)
- Cache hit/miss ratio (probably per-route?)
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 :)
