-
Notifications
You must be signed in to change notification settings - Fork 72
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
frontend: refactor subscription metrics #1272
Conversation
Please rebase pull request. |
0b03196
to
d8e71bf
Compare
Please rebase pull request. |
d8e71bf
to
195c66b
Compare
195c66b
to
40d29db
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggested a simplification that would avoid another wait group.
40d29db
to
acc859e
Compare
This change implements a custom collector for the subscription lifecycle metrics. In practice, the collector maintains a local cache of subscriptions which is refreshed periodically from the database. The benefits are: * The metrics are persisted upon restart of the process (previously a subscription would only exist as a metric if it was accessed by some HTTP operation). * All frontend replicas report the same metrics. * Only the latest state of a subscription is reported (in the previous implementation, the old state would still be reported after an update). The cache is refreshed every 30 seconds which should be good enough assuming that the metrics are scraped at a similar (or greater) interval. Signed-off-by: Simon Pasquier <spasquie@redhat.com>
acc859e
to
3c9fbb1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice!
This will introduce a small conflict with changes I have staged in #1215 - database: Merge Cosmos DB containers but I'll adapt it rather than hold this PR up any longer.
What this PR does
This change implements a custom collector for the subscription lifecycle metrics. In practice, the collector maintains a local cache of subscriptions which is refreshed periodically from the database.
The benefits are:
The cache is refreshed every 30 seconds which should be good enough assuming that the metrics are scraped at a similar (or greater) interval.
Jira:
Link to demo recording:
Special notes for your reviewer