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

Metrics & Plugin Interface #4

Open
valeriansaliou opened this issue Oct 27, 2017 · 3 comments
Open

Metrics & Plugin Interface #4

valeriansaliou opened this issue Oct 27, 2017 · 3 comments
Labels
Milestone

Comments

@valeriansaliou
Copy link
Owner

valeriansaliou commented Oct 27, 2017

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

  1. Instance RPS (total, per request type)
  2. Success/error ratio
  3. Request/response latency per Bloom-Status (MISS, HIT, DIRECT)
  4. Cache hit/miss ratio (probably per-route?)
@valeriansaliou valeriansaliou self-assigned this Oct 27, 2017
@valeriansaliou valeriansaliou added this to the v2.0 milestone Oct 27, 2017
@valeriansaliou
Copy link
Owner Author

See #3

@valeriansaliou valeriansaliou removed their assignment Oct 27, 2017
@valeriansaliou valeriansaliou changed the title Metrics / Plugin Interface Metrics & Plugin Interface Oct 27, 2017
@abbudao
Copy link
Contributor

abbudao commented Mar 30, 2023

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.

@hendrikkiedrowski
Copy link

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants